Verteilte Systeme Kapitel 7: Synchronisation Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer
Inhaltsüberblick der Vorlesung 1. Einführung und Motivation 2. Protokolle und Schichtenmodelle 3. Nachrichtenrepräsentation 4. Realisierung von Netzwerkdiensten 5. Kommunikationsmechanismen 6. Adressen, Namen und Verzeichnisdienste 7. Synchronisation 8. Replikation und Konsistenz 9. Fehlertoleranz 10.Verteilte Transaktionen 11.Sicherheit 1-2
Überblick Zeit in verteilten Systemen Verfahren zum gegenseitigen Ausschluss Globale Zustände Wahlalgorithmen 3
Zeit in verteilten Systemen
Zeit in verteilten Systemen: Überblick Uhrensynchronisation Das Phänomen der Zeit in Computersystemen Algorithmen zur Uhrzeitsynchronisation Logische Uhren Lamports Logische Uhren Anwendung 5
Motivation Wie koordinieren und synchronisieren sich Prozesse? Zugriff auf gemeinsam verwendete Ressourcen Feststellung, welcher Prozess ein Ereignis zuerst ausgelöst hat (z.b. verteilte Online-Auktionen) Viele Algorithmen benötigen gemeinsames Zeitverständnis Kein Problem in zentralisierten Systemen (nur eine Zeitquelle) In VS hat jeder Knoten eine eigene Zeitquelle Problematisch, wenn diese verschiedene Zeiten anzeigen 6
Gemeinsames Zeitverständnis Flug- und Bahnverkehr (Positionsmeldungen zu einer bestimmten Zeit) Synchronisation von Multimediaströmen (Telekonferenzen) Börsentransaktionen Verteiltes Logging Videorekorder Netzwerk-Monitoring 7
Zeit Gegen Mittag erreicht Sonne höchsten Punkt am Himmel Zeitspanne zwischen zwei aufeinanderfolgenden Ereignissen dieses Typs heißt... Tag! ;-) (genauer: Sonnentag) Sonnensekunde: 1/86400 dieser Spanne Zeitmessung mit Atomuhren 1 Sekunde: Zeit, die ein Cäsium133-Atom benötigt, um 9.192.631.770 mal zu schwingen Am 1.1.1958 entsprach 1 Atomsekunde genau 1 Sonnensekunde Wegen der Erdreibung wird Sonnensekunde immer länger Stimmt deshalb nicht 100% mit der Sonnenzeit überein 8
TAI und UTC Internationale Atomuhrzeit (Temps Atomique International, TAI) Atomzeit Sonnenzeit: etwas tricksen Liegen beide mehr als 800ms auseinander, wird eine Schaltsekunde ( leap second ) eingeführt bzw. gelöscht Diese Zeit heißt Universal Coordinated Time (UTC) Weltweit Reihe von UTC-Sendern; preisgünstige Empfänger erhältlich Weitere Informationen http://www.ptb.de/cms/de/presseaktuelles/ uhrzeitapplikation/fragenzurzeit0.html 9
Zeit in verteilten Systemen Computer haben eine lokale Uhr Löst h mal pro Sekunde einen Interrupt aus Interrupts werden gezählt und messen die Zeit Problem Uhren von Computern zeigen verschiedene Zeiten an Besitzen unterschiedliche Startzeiten Besitzen unterschiedliche Laufzeiten / Geschwindigkeiten / Ganggenauigkeiten (z.b. 20ppm, 200ppm,...) 10
Genauigkeit von Uhren Wert der Uhr von Maschine p zum UTC-Zeitpunkt t ist Cp(t) Chips haben eine Genauigkeit von ca. 10-5 (10ppm) Uhr arbeitet korrekt, wenn sie die angegebene maximale Driftrate ρ einhält Auch wenn sie dann zu langsam oder zu schnell ist Uhrzeit C Beispiel h=60 216.000 Ticks pro Stunde Realistisch: Werte von 215.998 bis 216.002 UTC, t 11
Beispiel: Verteilte SW-Entwicklung Quelldatei ist augenscheinlich älter als die Zieldatei. Ergebnis: Wird bei einem erneuten make nicht neu übersetzt 12
Uhrensynchronisation t nach der Synchronisation zweier Uhren Beide Uhren können maximal 2ρ t auseinander liegen Zwei Uhren liegen niemals mehr als δ auseinander Uhren mindestens alle δ/2ρ Sekunden synchronisieren Nicht jeder Rechner hat UTC-Empfänger Keine vollständige externe Synchronisation durchführbar Reihe von Algorithmen verfügbar, die auf der Verwendung weniger Time-Server beruhen 13
Algorithmus von Cristian (1989) Annahme Existenz eines UTC-Empfängers, der als Time-Server fungiert Andere Systeme senden mind. alle δ/2ρ Sekunden Time Request Server antwortet so schnell wie möglich mit der aktuellen UTC t req t res A t 1 t 4 B t 2 t 3 Zeit 14
Algorithmus von Cristian Uhr könnte auf die erhaltene UTC-Zeit gesetzt werden Probleme Zeit darf nicht rückwärts laufen (sonst tauchen Zeitpunkte zweimal auf) Bei einer schnellen Uhr kann UTC u.u. stark hinterher laufen Ein Setzen auf den UTC-Wert wäre dann falsch Lösung Uhren werden nicht auf einmal angepasst Anpassung der Uhrzeitbestimmung (ein Clock-Tick wäre nicht mehr z.b. 10ms, sondern nur noch 9ms) sog. Clock Discipline 15
Algorithmus von Cristian Signallaufzeit für die Nachrichten > 0 (Antwort bei Ankunft veraltet) Lösung von Christian Versuche die Laufzeit zu messen/schätzen (Annahme: Laufzeit in beide Richtungen identisch) Neue Zeit: t neu = t serv + (t 4 -t 1 )/2 t req t res A t 1 t 4 B t 2 t 3 Zeit 16
Der Berkeley-Algorithmus Entwickelt für Netzwerke mit Berkeley-UNIX- Rechnern Sinnvoll, wenn kein UTC-Empfänger zur Verfügung steht Sog. interne Synchronisation (keine externe Zeitquelle) Ein Rechner ist der Koordinator (=Time-Server) Im Gegensatz zu dem Server von Christian aktiv Client passen Uhrengeschwindigkeiten an Ziel: Übereinstimmung aller Uhren mit dem Durchschnittswert 17
Der Berkeley-Algorithmus 03:00 Server 02:50 03:25 Client Client Ausgangslage: Rechner mit unterschiedlichen Uhrzeiten 18
Der Berkeley-Algorithmus 03:00 03:00 Server 03:00 03:00 02:50 03:25 Client Client Koordinator (Server) sendet seine Uhrzeit an alle anderen Systeme 19
Der Berkeley-Algorithmus 03:00 0 Server -0:10 +0:25 02:50 03:25 Client Client Diese antworten mit der Differenz zu Ihrer Zeit Server bildet Mittelwert: (-10+0+25)/3 5 20
Der Berkeley-Algorithmus 03:00 +0:05 Server +0:15-0:20 02:50 03:25 Client Client Server teilt Clients mit, wie stark die jeweilige Uhr angepasst werden muss 21
Der Berkeley-Algorithmus 03:05 Server 03:05 03:05 Client Client 22
Network Time Protocol (NTP) Bisherige Algorithmen skalieren nicht internetweit Daher: Entwicklung von NTP in den 80er Jahren Inzwischen ein Internet RFC (diverse Verbesserungen) Ziele Clients möglichst genau mit UTC synchronisieren Ausgleich stark schwankender Übertragungsverzögerungen Zuverlässiger Dienst mittels Redundanz Skalierbarkeit: Häufige Synchronisation vieler Clients 23
Funktionsweise von NTP NTP-Dienst wird von einem Netzwerk von Servern erbracht Abhängig von deren Entfernung zu einer geeichten Zeitquelle werden sie in Strata eingeteilt Stratum 0 Primary Server (direkt mit einer UTC-Quelle verbunden) Stratum n+1 Synchronisieren sich mit Strata-n Servern Stratum 0 Atomuhren, GPS Uhren,... Stratum 1 Server 1 Server 5 Server 7 Stratum 2 Server 2 Server 4 Server 3 Server 10 Stratum 3 Server 8 Server 9 Server 11 Server 12 24
Funktionsweise von NTP NTP-Netzwerk ist rekonfigurierbar (zur Reaktion auf Fehler) NTP-Server tauschen häufig Nachrichten aus Messung von Netzwerkverzögerungen und Uhrungenauigkeiten Schätzung der Netzwerkverzögerung ( T2 T1 ) + ( T4 T3 ) δ = 2 Damit lässt sich die Qualität eines Servers abschätzen Clients können den besten Server wählen 25
Funktionsweise von NTP NTP-Client empfängt Zeit von mehreren Servern (Redundanz, Diversität, Stabilität) Filter wählen bestes Sample aus 8 aus Auswahl und Aggregation fasst Ergebnisse zusammen Clock-Discipline-Algorithmus Liefert Zeitstempel zur Uhrzeitkorrektur und Ganganpassung Feedback zu den Filtern zur Minimierung von Jitter NTP-Client NTP Server NTP Nachrichten Filter NTP Server... NTP Nachrichten Filter Auswahl & Aggregatio n Clock Discipline Algorithm NTP Server NTP Nachrichten Filter 26
Network Time Protocol (NTP) Erreichbare Genauigkeiten ~10 ms in WANS < 1 ms in LANs < 1 Microsekunde mit GPS receiver Skalierbarkeit Jeder moderne Windows-PC ist ein NTP-Client 27
Grenzen der Zeitsynchronisation Es ist generell unmöglich, physikalische Uhren in einem verteilten System perfekt zu synchronisieren Damit ist es unmöglich die Reihenfolge zweier beliebiger Ereignisse zu bestimmen Für einige Anwendungen benötigt man jedoch genau diese Information, dafür aber keinen Bezug zur realen Zeit Beispiele Berkeley-Algorithmus ohne externe Zeitquelle Verteiltes make nur wichtig, dass eine Datei vor der anderen verändert wurde 28
Lösung: Logische Zeit (logical time) Wichtige Beobachtung Synchronisation zwischen Rechnern nicht erforderlich wenn sie nicht interagieren (fehlende Synchronisation ist nicht beobachtbar) Logische Zeit Zwei Ereignisse in einem Prozess Fanden in der Reihenfolge ihrer Beobachtung statt Nachricht zwischen zwei Prozessen Sendereignis immer vor dem Empfangsereignis 29
Die Happened-Before-Beziehung Lamports Happened-Before-Relation Wenn in einem Prozess p i a i b gilt, gilt für das System a b Für jede Nachricht m gilt: send(m) receive(m) send(m): Sendeereignis im sendenden Prozess receive(m): Empfangsereignis im empfangenden Prozess Wenn a b und b c gilt, dann gilt auch a c Ereignisse, die nicht in dieser Beziehung stehen, werden als nebenläufig bezeichnet Happened-Before-Beziehung: Schwaches Konsistenzkriterium 30
Beispiel Es gilt a b, b c, c d, d f Und also a f Aber nicht a e Wenn a f gilt, wird eine kausale oder möglicherweise kausale Beziehung angenommen p 1 a b m 1 p 2 c d m 2 p 3 e f Zeit 31
Praktische Umsetzung Jeder Prozess p i hat eine logische Uhr Wird beim Auftreten eines Ereignisses a abgelesen Liefert dann den Wert C i (a) Dieser Wert muss so angepasst werden, dass er als C(a) eindeutig im ganzen verteilten System ist Wichtige Eigenschaft: Konsistenz 32
Konsistenzkriterium für Uhren Bedeutung der Symbole e: Ereignis e 1 e 2 : e 2 ist Folge von e 1 (e 1 ist Ursache von e 2 ) C(e) Uhrzeit von C zum Zeitpunkt von e Schwaches Konsistenzkriterium e 1 e 2 C(e 1 ) < C(e 2 ) Starkes Konsistenzkriterium (Umkehrung gilt) C(e 1 ) < C(e 2 ) e 1 e 2 33
Umsetzung von Happened-Before C i wird vor jedem neuen Ereignis in p i um eins erhöht C i := C i + 1 Der neue Wert ist der Timestamp des Ereignisses Beim Senden von Nachrichten Erzeuge neues Ereignis Sende <nachricht, C i > Beim Erhalt von Nachrichten Erhalt von <nachricht, timestamp> bei p j Modifiziere Uhr: C j := max(c j, t) + 1 34
Pseudocode 35
Beispiel 36
Beispiel 37
Beispiel 38
Beispiel 39
Beispiel 40
Beispiel 41
Beispiel 42
Beispiel 43
Beispiel 44
Beispiel 45
Anwendung: Replizierte Datenbank Über zwei Standorte verteilte Datenbank Zur Performancesteigerung Anforderung: Kopien müssen konsistent sein Lesezugriff auf lokale Kopie Schreibzugriffe parallel auf alle Replikate Lübeck Heidelberg 46
Anwendung: Replizierte Datenbank Benutzer 1: Erhöhe Kontostand um 100 Auftrag: Erhöhe Kontostand um 100 Lübeck 1000 1000 Heidelberg 1100 1100 47
Anwendung: Replizierte Datenbank Benutzer 2: Schreibe 2% Zins gut Auftrag: Schreibe 2% Zins gut Lübeck Heidelberg 1100 1100 1122 1122 48
Anwendung: Replizierte Datenbank Problem Gleichzeitige Aufträge und verschiedene Latenz Mögliche Ankunft in umgekehrter Reihenfolge Inkonsistente Daten Lübeck 1000 Heidelberg 1000 1100 1020 1122 1120 49
Lösung: Totally-Ordered Multicast Alle Nachrichten werden bei allen Empfängern in derselben Reihenfolge ausgeliefert Annahmen Reihenfolgeerhaltung Nachrichten gehen nicht verloren Implementierung? 50
Implementierung: Totally-Ordered Multicast Ziele Konsistenz der Datenbestände durch Reihenfolgenerhaltung der Nachrichten vor Verarbeitung Implementierung Prozesse haben 2 lokale Warteschlangen für 1. eingehende Nachrichten (Hold-Back-Queue) 2. zur Verarbeitung freigegebene Nachrichten (Delivery-Queue) Sortierung nach Lamport-Zeitstempeln 51
Implementierung: Totally-Ordered Multicast Empfang eines Auftrags Einsortieren nach Zeitstempel in Hold-Back-Queue Empfangsbestätigung per Multicast senden Verarbeitung eines Auftrags Warten auf Bestätigungen dieses Auftrags von allen anderen Systemen Auftrag (und Bestätigungen) aus Hold-Back-Queue entnehmen In Delivery-Queue übergeben Auslieferung aus Delivery-Queue an Applikation 52
Vektoruhren Erweiterung der Lamport-Uhr Erfüllt das starke Konsistenzkriterium für Uhren (C(e 1 ) < C(e 2 ) e 1 e 2 ) Erlaubt Feststellung von Nebenläufigkeit Anstelle eines Zählers: Uhrenvektor Prozesse speichern Zählerstand aller anderen Prozesse (soweit bekannt, sonst null) Uhrenvektor wird mit jeder gesendeten Nachricht übertragen Jeder Prozess hat eine eindeutige ID (z.b. IP:Port) 53
Vektoruhren: Algorithmus V A [] = Vektor von Prozess A (p A ) mit Timestamps aller Uhren V A [B] = letzter dem Prozess A bekannter Timestamp von Prozess B V A [A] wird vor jedem neuen Ereignis in p A um eins erhöht V A [A] := V A [A] + 1 (Initialisierung mit 0) Der neue Wert V A [A] ist der Timestamp des Ereignisses Beim Senden von Nachrichten Erzeuge neues Ereignis Sende <Nachricht, V A [] > Beim Erhalt einer Nachricht von p B p A erhält <Nachricht, V B []> von p B Neues Ereignis für p A ( V A [A] := V A [A] + 1 ) Für alle x in V A []: V A [x] := max(v A [x], V B [x]) 54
Feststellen kausaler Abhängigkeit 55
Zusammenfassung Perfekt gleiche Zeit in allen Rechnern eines Systems nicht erreichbar Hardware-Synchronisation ist möglich, jedoch haben nicht viele Rechner einen UTC-Empfänger Synchronisationsalgorithmen für die physikalische Zeit funktionieren recht gut (NTP) Oft genügt Wissen über die Ordnung von Ereignissen Keine quantitative Zeitangabe Verwendung logischer Zeit (Lamportuhr, Vektoruhr) 56
Gegenseitiger Ausschluss
Gegenseitiger Ausschluss: Übersicht Begriff des gegenseitigen Ausschlusses Algorithmen in VS zum Erreichen des gegenseitigen Ausschlusses Zentraler Algorithmus Verteilter Algorithmus Token-Ring-Algorithmus Vergleich 58
Gegenseitiger Ausschluss Mehrere Prozesse greifen auf gemeinsame Daten zu Müssen sich koordinieren um Konsistenz zu gewährleisten Am einfachsten über Konzept der kritischen Region realisierbar Nur je ein Prozess darf in einer kritischen Region sein Gegenseitiger Ausschluss (mutual exclusion) In Ein-Prozessor-Systemen werden Semaphore oder Monitore verwendet (siehe Vorlesung Betriebssysteme und Netze) Wie funktioniert das in verteilten Systemen? 59
Ein zentralisierter Algorithmus Ein Prozess wird zum Koordinator für kritische Region bestimmt Prozesse müssen sich zunächst an Koordinator wenden, bevor sie die kritische Region betreten Ist die kritische Region belegt, werden Prozesse in eine Warteschlange aufgenommen Sobald die kritische Region frei ist, erhält ein Prozess das Zugriffs-Token vom Server Nach Abarbeitung gibt der Prozess dieses Token zurück 60
Beispiel für den zentralen Algorithmus Queue 1.) Request Coord inator Client #1 2.) Token Client #3 Client #2 61
Beispiel für den zentralen Algorithmus Coord inator #2 Queue 1.) Request Client #1 2.) Token 3.) Request Client #3 Client #2 62
Beispiel für den zentralen Algorithmus Queue Coord inator Client #1 4.) Release Token 5.) Token Client #3 Client #2 63
Eigenschaften des Algorithmus Mutual Exclusion wird erreicht Immer nur ein Prozess im kritischen Bereich Möglich, da der Server immer nur ein Token vergibt Vorteile Fair: Tokens werden in der Reihenfolge der Anfrage vergeben Einfach zu implementieren Nur 3 Nachrichten pro Zugang zur kritischen Region Nachteile Koordinator ist single point of failure Unterscheidung zwischen totem Koordinator oder langer Warteschlange nicht möglich Performance Bottleneck in großen Systemen 64
Ein verteilter Algorithmus Beispiel: Algorithmus (Ricart and Agrawala, 1981) ohne Koordinator Alle Prozesse verständigen sich über Multicast-Nachrichten Jeder Prozess besitzt eine logische Uhr Wenn ein Prozess eine kritische Region betreten will, sendet er ein Request an alle anderen Prozesse Erst wenn alle Prozesse ihr OK gegeben haben, kann der Prozess die kritische Region betreten 65
Algorithmus (Ricart and Agrawala, 1981) Senden eines Requests Sende <id i, C i > Empfang eines Requests bei id x : <id remote, C remote > Kein Interesse an kritischer Region oder C remote < C x Sende Antort-Nachricht Ansonsten: Verzögere Antwort bis die kritische Region verlassen wurde 66
Beispiel: Timestamp = 8 p 1 8 8 12 p 2 p 3 12 Timestamp = 12 Prozess p 1 und p 3 wollen gleichzeitig in den kritischen Bereich Prozess p 1 hat den niedrigeren Timestamp und gewinnt 67
Beispiel: p 1 betritt kritischen Bereich p 1 OK OK p 2 p 3 OK Prozess p 1 hat den niedrigeren Timestamp und gewinnt. 68
Beispiel: p 1 verlässt kritischen Bereich p 1 OK p 2 p 3 p 3 betritt kritischen Bereich Wenn Prozess p 1 fertig ist, gibt er den kritischen Bereich frei und sendet ebenfalls ein OK an p 3. 69
Eigenschaften des Algorithmus Single-point-of-failure wurde durch n points-of-failure ersetzt Wenn nur ein Prozess nicht funktioniert, funktioniert das System nicht mehr Könnte durch Verwendung von Bestätigungen behoben werden Keine Bestätigung zu einer Nachricht Prozess nicht mehr aktiv Jeder Prozess muss bei der Entscheidung mitwirken Obwohl er evtl. gar kein Interesse an der kritischen Region hat Verbesserung: eine einfache Mehrheit genügt Zusammenfassung Insgesamt langsamer, komplizierter, teurer und weniger robust Aber, wie Tanenbaum sagt: Finally, like eating spinach and learning Latin in high school, some things are said to be good for you in some abstract way. 70
Ein Token-Ring-Algorithmus Prozesse in logischer Ringstruktur organisieren z.b. anhand einer eindeutigen ID (IP:Port) oder einer Anwendungs-ID Ein Token kreist Wer das Token besitzt, darf in den kritischen Bereich, allerdings nur einmal Beispiel: Nicht sortierte Gruppen von Prozessen #1 #5 #9 #11 #7 #2 71
Ein Token-Ring-Algorithmus #2 #5 #1 #7 #9 #11 72
Eigenschaften des Algorithmus Korrektheit leicht zu sehen (max. 1 Prozess hat Token) Fair: Reihenfolge durch den Ring bestimmt Maximale Wartezeit: Bis alle anderen einmal im kritischen Bereich waren Verlorene Token erfordern Neugenerierung durch Koordinator Verlust eines Tokens ist schwer zu erkennen Es kann sich auch um einen sehr langen Aufenthalt in einem kritischen Bereich handeln Tote Prozesse müssen erkannt werden 73
Vergleich Algorithmus Nachrichten pro Ein-/Austritt Verzögerung bis Eintritt (Zeit/Nachricht) Probleme Zentralisiert 3 2 Coordinator crash Verteilt (Multicast) 2 ( n 1 ) 2 ( n 1 ) Crash of any process Token Ring 1 to 0 to n 1 Lost token Process crash 74
Zusammenfassung Gegenseitiger Ausschluss im verteilten System ist schwieriger zu erreichen als in einem Ein- Prozessor-System Es existieren verschiedene Algorithmen mit unterschiedlicher Bedeutung für die Praxis Vollkommene Verteilung bringt hier viele Nachteile mit sich 75
Global State
Global State: Überblick Globale Zustände und deren Anwendung Distributed Snapshot Der Begriff des Cut Der Algorithmus von Lamport und Chandy Beispiel Zusammenfassung 77
Globale Systemzustände Häufig notwendig: Gesamtzustand eines verteilten Systems Gesamtzustand eines VS besteht aus Lokalen Zuständen der Einzelkomponenten (der Prozesse) Allen Nachrichten, die sich zur Zeit in der Übertragung befinden Diesen exakt zur selben Zeit bestimmen zu können ist so unmöglich wie die exakte Synchronisation von Uhren Es lässt sich kein globaler Zeitpunkt festlegen, an dem alle Prozesse ihre Zustände festhalten sollen 78
Anwendungen des globalen Zustands p 1 p 2 a. Garbage collection object reference message garbage object p 1 wait-for p 2 b. Deadlock wait-for p 1 p 2 c. Termination passive activate passive 79
Distributed Snapshot Wie den globalen Zustand eines VS ermitteln? Distributed Snapshot (Chandy und Lamport,1985) Ermittle einen Zustand, in dem das System möglicherweise war Der aber auf jeden Fall konsistent ist Konsistenz bedeutet insbesondere Wenn P eine Nachricht m von Q empfangen hat, muss auch Q diese Nachricht geschickt haben Sonst kann das System nicht in diesem Zustand gewesen sein 80
Consistent und Inconsistent Cut Definition der Konsistenz über den sog. cut Gibt für jeden Prozess das letzte aufgezeichnete Ereignis an p 1 m 1 m 3 m 1 m 3 p 2 m 2 m 2 p 3 Ok, da m 3 in Transit Zeit Sender von m 2 nicht identifizierbar 81
Formale Definition des Cut Gegeben System von N Prozessen p i (i=1,...,n) Globaler Zustand S=(s 1,...,s N ) des Systems In jedem Prozess: Serie von Ereignissen Charakterisierung über Geschichte der Ereignisse: history(p i ) = h i = <e i0, e i1, e i2,...> Endlicher Präfix einer Prozesshistorie h ik = <e i0, e i1, e i2,..., e ik > 82
Formale Definition des Cut Cut: C c 1 Der Zustand s i aus dem globalen Zustand ist dann genau derjenige von p i, c 2 = h 1 h 2... der durch das Ausführen des letzten Ereignisses im Cut c erreicht wird, also von i e i h c N N Die Menge Cuts bezeichnet. { e ci : i 1,2,... N} i = wird als Frontier des 83
Beispiel 0 e 1 1 e 1 2 e 1 3 e 1 p 1 m 1 m 2 p 2 0 e 2 1 e 2 2 e 2 Zeit 2 2 Frontier: < > < e 0,e 0 1 2 > e 1,e 2 84
Definition des konsistenten Cut Ein Cut ist dann konsistent, wenn er für jedes Ereignis, das er enthält, auch alle Ereignisse enthält, die zu diesem Ereignis in der Happened- Before-Relation (s. Zeit in verteilten Systemen) stehen: e C, f e f C Ein globaler Zustand ist konsistent, wenn er mit einem konsistenten Cut korrespondiert 85
Lamport/Chandy-Algorithmus Prozesse sind mittels Punkt-zu-Punkt-Kanälen verbunden Ein oder mehrere Prozesse starten den Algorithmus Es können gleichzeitig immer mehrere Snapshots erstellt werden Das System läuft unterdessen ungehindert weiter Prozesse senden Markierungsnachrichten für Snapshots Geben an, dass ein Systemzustands gespeichert werden soll 86
Prozessmodell für den Algorithmus Marker Prozess Zustand P Eingehende Nachrichten Speicher Ausgehende Nachrichten 87
Der Algorithmus Prozess empfängt einen Marker auf Kanal c Zustand noch nicht gespeichert Zustand speichern Zustand von c als leere Menge speichern Nachrichtenspeicherung auf allen anderen Kanälen aktivieren Zustand bereits gespeichert Zustand von c speichern (= Menge der empfangenen Nachrichten seit Beginn der Zustandsspeicherung) Regel zum Versand von Markern Nach Speichern des Zustands auf jedem Kanal eine Markernachricht versenden (vor allen anderen Nachrichten) 88
Ablauf des Algorithmus Prozess P erhält zum ersten Mal einen Marker und hält seinen lokalen Zustand fest a b c P Speicher Zustand 89
Ablauf des Algorithmus b) P hält alle ankommenden Nachrichten fest d P Speicher Zustand a b c 90
Ablauf des Algorithmus P erhält einen Marker auf seinem Eingangskanal und stoppt die Aufzeichnung für diesen Kanal P Speicher Zustand a b c d 91
Ende des Algorithmus Algorithmus endet wenn P einen Marker auf allen Eingangskanälen erhalten und verarbeitet hat Danach sendet P seinen lokalen Zustand sowie die aufgezeichneten Nachrichten für alle Eingangskanäle an den initiierenden Prozess Dieser wertet schließlich das Ergebnis entsprechend aus, analysiert also z.b. bestimmte Zustandsprädikate Man kann beweisen, dass dieser Algorithmus immer einen konsistenten Cut erzeugt 92
Beispiel P 1 State1 P 2 P 3 State2 State3! 93
Beispiel P 1 M M C 21 ={ State1 C 31 ={ P 2 P 3 State2 State3 94
Beispiel P 1 State1 State1 C 21 ={ C 31 ={ } M M C 12 ={} C 32 ={ P 2 M P 3 M State2 State3 95
Beispiel P 1 State1 State1 C 21 ={ C 31 ={ } } M State2 C 12 ={} C 32 ={ } P 2 P 3 M State2 State3 M M C 13 ={ } C 23 ={}! 96
Zusammenfassung Es ist unmöglich, einen globalen Systemzustand gleichzeitig aufzuzeichnen Der Algorithmus von Lamport und Chandy macht einen Distributed Snapshot Dieser Snapshot hat möglicherweise so nie genau als Systemzustand stattgefunden, aber er ist konsistent 97
Auswahlalgorithmen
Auswahlalgorithmen: Überblick Zweck von Auswahlalgorithmen Bully-Algorithmus Ring-Algorithmus 99
Auswahlalgorithmen Oft benötigt: Ein ausgezeichneter Prozess Sog. Symmetry Breaking Besondere Rolle: Koordinator, Initiator, Monitor,... Aufgabe eines Auswahlalgorithmus Einen Prozess unter vielen gleichartigen bestimmen, der diese Rolle übernimmt Wichtigstes Ziel Am Ende der Wahl sind sich alle darüber einig, wer der neue Koordinator ist 100
Auswahlalgorithmen Vorgehen Jeder Prozess hat eine Nummer Diese ist allen anderen Prozessen bekannt Kein Prozess weiß, welcher andere Prozess gerade funktioniert oder nicht läuft Alle Algorithmen wählen den Prozess mit der höchsten Nummer aus Bekannte Algorithmen Bully-Algorithmus Ring-Algorithmus 101
Der Bully-Algorithmus Prozesse starten den Auswalprozess wenn... der aktuelle Koordinator nicht mehr reagiert kein Koordinator existiert Auswahlprozess P schickt Nachricht an Prozesse mit höherer Nummer Bekommt er keine Antwort, ist er der neue Koordinator Bekommt er eine Antwort, ist seine Aufgabe erledigt Der Antwortende übernimmt seine Arbeit 102
Beispiel: Bully-Algorithmus 1 2 5 4 6 0 3 7 Koordinator 103
Beispiel: Bully-Algorithmus 1 2 5 4 6 0 3 7 Koordinator 104
Beispiel: Bully-Algorithmus 1 2 5 4 6 ELECTION 0 3 7 105
Beispiel: Bully-Algorithmus 1 2 OK 5 OK 4 6 0 3 7 106
Beispiel: Bully-Algorithmus 1 2 5 ELECTION 4 ELECTION 6 ELECTION 0 3 7 107
Beispiel: Bully-Algorithmus 1 2 5 OK 4 6 0 3 7 108
Beispiel: Bully-Algorithmus 1 2 5 4 6 COORDINATOR 0 3 7 109
Ein Ring-Algorithmus Prozesse sind logisch als Ring organisiert Jeder Prozess besitzt einen Vorgänger und einen Nachfolger Entsprechend aufsteigender Prozessnummern Prozess stellt fest, dass der Koordinator ausgefallen ist Sendet ELECTION-Nachricht auf den Ring In diese trägt er sich als ersten ein Jeder weitere aktive Prozess fügt sich selbst in die Liste ein Nachricht trifft wieder beim Initiator ein Er wandelt diese in eine KOORDINATOR-Nachricht um Diese enthält den neuen Koordinator und die aktiven Mitglieder 110
Beispiel: Ring-Algorithmus [5,6,0] [2,3,4,5,6,0] 1 [5,6,0,1] [2,3,4,5,6,0,1] 0 2 [5,6,0,1,2] [2] Koordinator 7 [5,6] [2,3,4,5,6] 3 [5,6,0,1,2,3] Keine Antwort [2,3] Keine Antwort 6 4 [2,3,4,5] [5] 5 [2,3,4] [5,6,0,1,2,3,4] 111
Beispiel: Ring-Algorithmus 1 COORDINATOR = 6 COORDINATOR = 6 7 0 2 COORDINATOR = 6 3 COORDINATOR = 6 6 4 COORDINATOR = 6 COORDINATOR = 6 5 112
Literatur Uhrzeit und Uhrensynchronisation http://www.ptb.de/cms/de/presseaktuelles/uhrzeitapplikation/fragenzurzeit0.ht ml Cristian F.: Probabilistic clock synchronization in Distributed Computing, Volume 3, Issue 3, 1989, pp. 146-158, doi:10.1007/bf01784024 Lamportuhr Leslie Lamport: Time, clocks, and the ordering of events in a distributed system. In: Communications of the ACM. 21, Nr. 7, Juli 1978, ISSN 0001-0782, S. 558 565, doi:10.1145/359545.359563 Vektoruhren C. J. Fidge, Timestamps in message-passing systems that preserve the partial ordering, In K. Raymond, editor, Proc. of the 11th Australian Computer Science Conference (ACSC'88), pp. 56 66, February 1988. Reinhard Schwarz und Friedemann Mattern, Detecting Causal Relationships in Distributed Computations: In Search of the Holy Grail, in Distributed Computing, Nr. 3 Vol. 7, Springer 1994 113