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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
Agenda
Motivation Architektur eines SLA-fähigen RMS Operationsphasen SLA-Scheduling Cross-border Migration Zusammenfassung
Matthias Hovestadt: 20. DFN Arbeitstagung 3
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
Matthias Hovestadt: 20. DFN Arbeitstagung 5
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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!
Matthias Hovestadt: 20. DFN Arbeitstagung 6
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
Agenda
Motivation Architektur eines SLA-fähigen RMS Operationsphasen SLA-Scheduling Cross-border Migration Zusammenfassung
Matthias Hovestadt: 20. DFN Arbeitstagung 8
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
Matthias Hovestadt: 20. DFN Arbeitstagung 9
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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!”
Matthias Hovestadt: 20. DFN Arbeitstagung 13
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
Agenda
Motivation Architektur eines SLA-fähigen RMS Operationsphasen SLA-Scheduling Cross-border Migration Zusammenfassung
Matthias Hovestadt: 20. DFN Arbeitstagung 15
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
Matthias Hovestadt: 20. DFN Arbeitstagung 16
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
Negotiation Pre-Runtime
Runtime Post-Runtime
time
Compu-tation
StageOut
Matthias Hovestadt: 20. DFN Arbeitstagung 17
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
Phase 2: Pre-RuntimeStage
In
Negotiation Pre-Runtime
Runtime Post-Runtime
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
Matthias Hovestadt: 20. DFN Arbeitstagung 18
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
Negotiation Pre-Runtime
Runtime Post-Runtime
time
Compu-tation
StageOut
Matthias Hovestadt: 20. DFN Arbeitstagung 19
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
Negotiation Pre-Runtime
Runtime Post-Runtime
time
Compu-tation
StageOut
Matthias Hovestadt: 20. DFN Arbeitstagung 20
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
Agenda
Motivation Architektur eines SLA-fähigen RMS Operationsphasen SLA-Scheduling Cross-border Migration Zusammenfassung
Matthias Hovestadt: 20. DFN Arbeitstagung 21
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
Matthias Hovestadt: 20. DFN Arbeitstagung 25
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
Agenda
Motivation Architektur eines SLA-fähigen RMS Operationsphasen SLA-Scheduling Cross-border Migration Zusammenfassung
Matthias Hovestadt: 20. DFN Arbeitstagung 28
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
Matthias Hovestadt: 20. DFN Arbeitstagung 29
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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
UNIVERSITÄT PADERBORN Die Universität der Informationsgesellschaft
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