Sicherung von Dienstgüten in Grid Systemen

1. Sicherung von Dienstgütenin Grid Systemen Matthias Hovestadt Odej Kao 20. DFN Arbeitstagung 6.-9. Juni 2006 Heilbronn

2. Agenda • Motivation • Architektur eines SLA-fähigen RMS • Operationsphasen • SLA-Scheduling • Cross-border Migration • Zusammenfassung Matthias Hovestadt: 20. DFN Arbeitstagung

3. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

4. Name ID or Description of SLA Context Contract Parties, Responsible Persons 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 Service Level Agreement Service Level Agreement 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 Matthias Hovestadt: 20. DFN Arbeitstagung

5. Guaranteed! user request grid middleware Reliability? Quality of Service? SLA RMS RMS RMS Best Effort! M1 M2 M3 Die Lücke zwischen Grid und RMS • 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 Matthias Hovestadt: 20. DFN Arbeitstagung

6. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

7. Agenda • Motivation • Architektur eines SLA-fähigen RMS • Operationsphasen • SLA-Scheduling • Cross-border Migration • Zusammenfassung Matthias Hovestadt: 20. DFN Arbeitstagung

8. 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 kompatiblefreie Ressourcen • Offene Schnittstellen • Integration in standardkonforme Grid-Middleware Systeme • Austausch der Subsysteme gegen andere Lösungen Matthias Hovestadt: 20. DFN Arbeitstagung

9. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

10. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

11. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

12. 3. Return: “Checkpoint completed!” 1. CP job+halt 6. Resume job Erzeugung eines neuen Checkpoints 8. Migration from last checkpoint 7. Job runningagain RMS 5. Link to Snapshot 4. Snap-shot ! CP Network Storage 2. In- Transit Packets Matthias Hovestadt: 20. DFN Arbeitstagung

13. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

14. Agenda • Motivation • Architektur eines SLA-fähigen RMS • Operationsphasen • SLA-Scheduling • Cross-border Migration • Zusammenfassung Matthias Hovestadt: 20. DFN Arbeitstagung

15. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

16. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

17. Phase 2: Pre-Runtime • 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 Matthias Hovestadt: 20. DFN Arbeitstagung

18. 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 derCompute Ressource zum Grid-User Matthias Hovestadt: 20. DFN Arbeitstagung

19. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

20. Agenda • Motivation • Architektur eines SLA-fähigen RMS • Operationsphasen • SLA-Scheduling • Cross-border Migration • Zusammenfassung Matthias Hovestadt: 20. DFN Arbeitstagung

21. 12am 6pm 12pm 6am 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 Matthias Hovestadt: 20. DFN Arbeitstagung

22. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

23. 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“ Matthias Hovestadt: 20. DFN Arbeitstagung

24. 12am 6pm 12pm 6am Runtime of SLA job • Pre-runtime phase • configuration of network, storage, and nodes • Runtime phase • Monitoring of system • Regular checkpointing • Post-runtime phase Matthias Hovestadt: 20. DFN Arbeitstagung

25. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

26. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

27. Agenda • Motivation • Architektur eines SLA-fähigen RMS • Operationsphasen • SLA-Scheduling • Cross-border Migration • Zusammenfassung Matthias Hovestadt: 20. DFN Arbeitstagung

28. RMS RMS 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 Matthias Hovestadt: 20. DFN Arbeitstagung

29. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

30. 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 Matthias Hovestadt: 20. DFN Arbeitstagung

31. 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 Matthias Hovestadt: 20. DFN Arbeitstagung