1 / 31

Sicherung von Dienstgüten in Grid Systemen

Sicherung von Dienstgüten in Grid Systemen . Matthias Hovestadt Odej Kao 20. DFN Arbeitstagung 6.-9. Juni 2006 Heilbronn. Agenda. Motivation Architektur eines SLA-fähigen RMS Operationsphasen SLA-Scheduling Cross-border Migration Zusammenfassung. Grid Computing Today. Grid Computing

sidone
Download Presentation

Sicherung von Dienstgüten in Grid Systemen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related