Sicherung von Dienstgüten in Grid Systemen

Präsentation zum Thema: "Sicherung von Dienstgüten in Grid Systemen"—  Präsentation transkript:

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

2 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

3 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

4 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

5 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

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 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

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 kompatible freie 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 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

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 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

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 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

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
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 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

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

19 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

20 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

21 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

22 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

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 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

25 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

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 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

28 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

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