UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft Sicherung von Dienstgüten in...

UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft

Sicherung von Dienstgütenin Grid Systemen

Matthias HovestadtOdej Kao

20. DFN Arbeitstagung6.-9. Juni 2006Heilbronn

Matthias Hovestadt: 20. DFN Arbeitstagung 2


Agenda

Motivation Architektur eines SLA-fähigen RMS Operationsphasen SLA-Scheduling Cross-border Migration Zusammenfassung



Grid Computing Today

Grid Computing Grids werden genutzt, aber…

… kaum kommerzielle Nutzung von Grids Einsatz nur für kleine isolierte Anwendungsfelder

… Haupteinsatz im akademischen Umfeld Testbeds von Forschungsprojekten

Zentrale Probleme Ressource-Provider: Eingriff in lokale Autonomie

Nutzer: Keine vertraglich gesicherten Dienstgüten Sicherung von Deadlines bei geschäftskritischen Jobs



Was ist ein Service Level Agreement?

Service Level Agreement (SLA) Vertrag zwischen Kunde und Provider

Beschreibt alle Erwartungen und Verpflichtungen Flexible Formulierung für jeden Anwendungsfall

SLA bereits im Fokus von Grid Middleware

Se

rvic

e L

ev

el A

gre

eme

nt

Terms R-Type: HW, OS, Compiler, Software Packages, …R-Quantity: Number CPUs, main memory, …R-Quality: CPU>2GHz, Network Bandwidth, … Deadline: Date, Time,…Policies: Demands on Security and Privacy, …

Price for Resource Consumtion (fulfilled SLA)Penalty Fee in case of SLA violation

Contract Parties, Responsible Persons

ID or Description of SLAName

Context

Se

rvice

Le

vel A

gre

eme

nt



Die Lücke zwischen Grid und RMS

SLA

RMS RMS RMS

M1 M2 M3

grid middleware

user request

Reliability? Quality of Service?

Best Effort!

User fragt nach einemService Level Agreement

Grid Middleware nutzt lokale RMS zur Job-Abarbeitung

ABER: Lokale RMS bieten nur Best Effort Dienste!

Ziel: SLA-fähiges RMS Laufzeitüberwachung Zuverlässigkeit

Fehlertoleranz

Guaranteed!



Anforderungen an ein SLA-fähiges RMS

Aushandlung SLA-Negotiation mit Grid Middleware Neuen Job nur akzeptieren, wenn SLA erfüllt werden kann

System Management Beachtung der Anforderungen geschlossener SLAs Zuweisung von System-Ressourcen gemäß SLA

Fehlertoleranz SLAs müssen auch im Fehlerfall erfüllt werden Notwendig: Mechanismen zur Fehlerbehandlung



Agenda




SLA-fähiges Resource Management System

Zentrale Komponente des Systems Schnittstelle zu Grid-Middleware: SLA-Aushandlung Schnittstellen zu Subsystemen: Realisierung der Fehlertoleranz

Aufgaben Aushandlung neuer SLAs Durchsetzung von Policies

Sicherheit, Zugriff, … Systemüberwachung Fehlertoleranz

Erstellung v. Checkpoints Migration auf kompatible

freie Ressourcen

Offene Schnittstellen Integration in standardkonforme Grid-Middleware Systeme Austausch der Subsysteme gegen andere Lösungen

Alternative Solution Alternative SolutionAlternative Solution

HPC4U Grid-enabled, SLA-aware Resource Management System:

SLA Negotiation Multi-Site SLA-aware Scheduling Monitoring Support of Checkpointing and Migration Security

Interface toStorage

StorageSolution

Interface toCheckpointing

CheckpointingSolution

Interface toNetwork

NetworkingSolution

Outcome 1(Open Source)

Outcome 2(Commercial)

Interface toGrid Middleware

Open Source

Commercial

Not part of theProject



Process Subsystem

Konzept: “Virtuelle Blase” Virtualisierung von Ressourcen

Virtuelles Netzwerk, Virt. Prozess-IDs, … Applikation läuft in virtueller Umgebung kaum Auswirkung auf Geschwindigkeit

Checkpoint der gesamten “virtuellen Blase” Keine re-compilierung oder re-linking notwendig

Checkpoint kommerzieller Applikationen (ohne Source)

Im Fehlerfall: Fortführung einer “virtuellen Blase” Hauptproblem: Kompatibilität der Ressourcen Applikation bemerkt nicht den Restart



Network Subsystem

HPC4U zielt auf parallele Applikationen Kommunikation zwischen Knoten Checkpoint des Netzwerk-Zustands notwendig

Sicherung der Konsistenz zwischen Netzwerk undApplikation beim Fortführen eines Checkpoints

Netzwerk-Checkpointing Checkpoint der Netzwerk-Protokoll-Queues Checkpoint der „In-Transit“ Pakete

Cooperative Checkpoint Protocol (CCP) direkte Abstimmung zwischen Checkpoint- und Netzwerk-Ss. notwendig, da Netzwerk-Checkpoint sehr zeitkritisch



Storage Subsystem

Aufgabe Erbringung der Dienstgüte bzgl. Storage-Speicher Checkpointing von Partitionen des Storage-Speichers

Konsistentes Umfeld des Prozesses im Checkpoint Wiederherstellung des kompletten Umfelds beim Re-Start Checkpoint = Prozeß + Netzwerk + Storage

Storage Checkpoint kann sehr groß werden Problem: Verzögerung beim Start auf entfernter Ressource

Grid-Migration über “langsame” WAN-Verbindungen Lösung: Daten-Replikation mittels COW (copy on write)

Vorsorglicher Datentransfer zur entfernten Ressource



Erzeugung eines neuen Checkpoints

RMS

Network StorageCP

1. CP job+halt

2. In-

Transit

Packets

4. Snap-shot !

5. Link to Snapshot

6. Resume job

7. Job runningagain

8. Migration from last checkpoint

3. Return:

“Checkpoint completed!”



Checkpointing

Erzeugung eines konsistenten Job-Abbildes laufender Prozeß Zustand des Netzwerks (parallele Jobs) Storage-Speicher

Checkpointing führt zu Verzögerung der Job-Fertigstellung abhängig von Anzahl Knoten, Netzwerk, Speichernutzung, …

Verzögerung muß bei Scheduling beachtet werden Länge = Geschätze Laufzeit + Checkpointing Overhead



Agenda




Laufzeitphasen

Aushandlung einer neuen SLA Pre-Runtime: Konfiguration und Initialisierung der Ressourcen

z.B. Clusterknoten, Netzwerk, Storage, … Runtime: Stage-In, Ausführung, Stage-Out Post-Runtime: Re-konfiguration

StageIn

Negotiation Pre-Runtime

Runtime

Lifetimeof SLA

Allocationof systemresources

Post-Runtime

time

Acceptance(or rejection)

of SLA Compu-tation

StageOut



Phase 1: SLA-Aushandlung

SLA-Aushandlung Ressource-Anbieter und Kunde versuchen sich auf en

Service Level Agreement zu einigen Welche Ressourcen müssen bereitgestellt werden? Wird eine besondere Dienstgüte gefordert?

Spezifikation einer Deadline, …

RMS in zentraler Position Steuerung des Aushandlungsprozesses Beachtung statischer und dynamischer Daten

StageIn


Runtime Post-Runtime

time

Compu-tation

StageOut



Phase 2: Pre-RuntimeStage

In



time

Compu-tation

StageOut

Aufgabe Konfiguration aller genutzten Ressourcen Ziel: Erfüllung der Anforderungen der SLA

Konfiguration betrifft alle Komponenten Resource Management System

z.B. Konfiguration von Rechenknoten

Storage Subsystem z.B. Initialisierung neuer Partitionen z.B. Vorbereitung der Datenreplikation

Network Subsystem z.B. Konfiguration des Netzwerks



Phase 3: Laufzeit der Applikation

Runtime Phase Lebenszeit des Jobs im System Inhalte der SLA erfüllen Nutzung der FT-Mechanismen

Drei aufeinanderfolgende Schritte Stage-In

Übertragung von Eingabedaten von Grid-User auf Compute Ressource

Berechnung Ausführung der Applikation

Stage-Out Transfer der Ausgabedaten von der

Compute Ressource zum Grid-User

StageIn



time

Compu-tation

StageOut



Phase 4: Post-Runtime

Aufgabe Re-konfiguration aller Ressourcen

z.B. Rekonfiguration des Netzwerks z.B. Löschung von Checkpoint-Daten z.B. Löschung temporärer Daten

Gegenstück zu Pre-Runtime Phase

Belegung der Ressourcen endet Schedules im System können aktualisiert werden Ressourcen sind für neue Jobs verfügbar

StageIn



time

Compu-tation

StageOut



Agenda




Aushandlung neuer SLAs

Eingehender SLA-Request 3 Knoten, 7h Laufzeit, Frühester Start: 20:00, Deadline 6:00 Request kann akzeptiert werden, Buffer 2h

Reguläres Checkpointing Neuen Checkpoint alle 60 Minutes erzeugen Checkpointing verursacht Verzögerung der Job-Fertigstellung

Ausmaß der Verzögerung von vielen Faktoren abhängig

12am 6pm 12pm 6am



Aussetzung der Jobausführung

Blockierung von Ressourcen durch Nicht-SLA Jobs 23:00: SLA-Request: 3 Knoten, 7 Stunden, Deadline 6:00

Fehlende Ressourcen: Ablehnung des neuen SLA-Requests

Checkpoint+Suspend des Nicht-SLA Jobs (best effort only) Annahme und Ausführung des SLA-Requests Fortführung des ausgesetzten Jobs

Fertigstellung v. Best-Effort Job, Erfüllung der SLA

12am 6pm 12pm 6am



Erhöhung der Systemauslastung

Jobs belegen System-Ressourcen User richten Requests nicht nach freien Kapazitäten aus

Reservierungen müssen erfüllt werden Lücken zu klein zur Ausführung anderer Jobs

Partielle Job-Ausführung in Lücken mittels Job-Suspend Realisierung von „Hintergrund-Jobs“



Runtime of SLA job

Pre-runtime phase configuration of network, storage, and nodes

Runtime phase Monitoring of system Regular checkpointing

Post-runtime phase

12am 6pm 12pm 6am



Behandlung von Ressource-Ausfällen Ausfall einer Ressource innerhalb einer Job-Partition

Job bricht üblicherweise sofort ab Letzter Checkpoint nach 4h Laufzeit

Berechnung seit letztem Checkpoint ist verloren

Belegung einer Partition mit 3h Laufzeit Aufsetzen auf letztem Checkpoint Scheduling der Checkpoint-Erzeugung Fortführung der Berechnung

12am 6pm 12pm 6am



Verfügbarkeit von Ausweich-Ressourcen

Migration setzt Verfügbarkeit anderer Ressourcen voraus aber: Ressourcen können durch andere Jobs belegt sein

Lösung: Aussetzung anderer Jobs Problem: Alle Ressourcen können durch SLAs belegt sein

SLA-Job können nur ausgesetzt werden, wenn Buffer vorh. Buffer Knoten: Ausschließlich Ausführung von Nicht-SLAs

12am 6pm 12pm 6am



Agenda




Cross-Border Migration

Ziel: Erfolgreiche Ausführung von SLA-Jobs Behandlung von Ausfällen hängt von lokaler Last ab Ziel des Providers: Auslastung seiner Ressourcen Hohe Last + Ausfall → Keine Migration → SLA Verletzung

Ansatz: Cross-Border Migration Nutzung von Ressourcen auf anderen Clustern

lokal meist mehrere Cluster verfügbar Transfer des Checkpoints zum externen Cluster Fortführung der Job-Ausführung von letzten Checkpoint

RMS RMS



Grid Migration

Cross-Border Migration Schritt in richtige Richtung zusätzliche Alternativen für den Migrations-Prozeß Erhöhung der Fehlertoleranz

Grid Migration = Nutzung von Grid Ressourcen f. Migration Aushandlung von SLAs mit Grid Ressourcen

Migrationsprozeß Anfrage an Grid nach Ausweich-Ressourcen Transfer des Checkpoints Fortführung von letztem Checkpoint auf Grid Ressource

Transparent für den User Benutzer nur an Erfüllung seiner SLA interessiert

Problem: Kompatibilität von Ressourcen und Checkpoints



Kompatibilitätsprofile

Kompatibilität zwischen Checkpoint und Ressourcen Prozessor Architektur Haupt- und Festplattenspeicher Interconnect Bibliotheken

Exakte Übereinstimmung für bereits geladene Bibliotheken Kompatible Bibliotheken für noch nicht geladene Bib.

Pfade

Profil mit Kompatibilitätsaspekten Beschreibung der Anforderungen des Jobs für Restart

Anfrage nach Grid-Ressourcen, gemäß dieses Profils



Zusammenfassung

Neue Anforderungen durch Next Generation Grids Transparenz, Fehlertoleranz, SLA Aushandlung

SLA-fähige Resource Management Systeme koordinierte Nutzung der Subsysteme für

Process, Storage, and Network Integration von SLA Scheduling in RMS

Cross-border Migration erhöht FT Level

Stand der Dinge Unterstützung nicht-paralleler Anwendungen Unterstützung paralleler Anwendungen aktuell: Cross-border Migration

UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft Sicherung von Dienstgüten in...

Documents

Transcript of UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft Sicherung von Dienstgüten in...