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

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

Grid Computing Today Grid Computing Zentrale Probleme 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

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 Service Level Agreement 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 SLA Name Context SLA bereits im Fokus von Grid Middleware Matthias Hovestadt: 20. DFN Arbeitstagung

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

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

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

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

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

Network Subsystem HPC4U zielt auf parallele Applikationen Kommunikation zwischen Knoten Checkpoint des Netzwerk-Zustands notwendig Sicherung der Konsistenz zwischen Netzwerk und Applikation 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

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

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

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

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

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

Phase 1: 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

Konfiguration betrifft alle Komponenten 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

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

Belegung der Ressourcen endet 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

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

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

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

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

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

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

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

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

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

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

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

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