Softwareentwicklung in verteilten Umgebungen, Teil 8 Time and Global States (Coulouris et al., Kapitel 11) Dieter Schmalstieg

Transkript

1 Softwareentwicklung in verteilten Umgebungen, Teil 8 Time and Global States (Coulouris et al., Kapitel 11) Dieter Schmalstieg

2 Zeit und Uhren in Computersystemen Netw ork Uhren auf verschiedenen Computern laufen nicht synchron Probleme Beispiel: Make compiliert nur, wenn Quelldatei neuer als Objektdatei ist

3 Technische Definition der Zeit Solarzeit, gemessen in Solartagen Erdrotation nicht konsistent, Verlangsamung Atomzeit (International Atomic Time, TAI) 1 sec = 9,192,631,770 Transitionen v. Caesium 133 Coordinated Universal Time (UTC) Atomzeit Gelegentliche Schaltsekunden zur Abgleichung mit Solarzeit Schaltsekunde = doppelte gezählte Sekunde

4 Digitale Zeitmessung Externe Zeitangaben UTC über Funk, Satelliten, GPS Interne Zeitmessung Timer = Zähler für Uhrimpulse (clock ticks) Quarzkristall CMOS RAM mit Batterie Uhrabweichung (clock drift) unvermeidbar Abweichungrate bestimmt Synchronisationsintervalle Synchronisation mit Real-Zeit (extern) Abweichung intern-extern muss < Schwellwert bleiben Synchronisation untereinander (intern) Abweichung der Uhren untereinander muss < Schwellwert bleiben Clock Drift

5 Synchron versus asynchron Synchrones Distributed System Einfache verteilte Algorithmen Uhrensynchronisation nötig Garantierte Genauigkeit Asynchrones verteiltes System Entspricht der Realität Oft keine deterministischen Algorithmen

6 Einfacher Zeitabgleich (Cristian s Algorithmus) Halbe Zeit des Round-trip Client-Server ((T 2 -T 1 ) + (T 4 -T 3 )) / 2

7 Berkeley-Algorithmus zur internen Synchronisation Time daemon fragt alle Computer nach der Zeit (inkl. daemon selbst) Mittelwertbildung Anpassung aller Uhren

8 Network Time Protocol (NTP) (1/2) Internet-Standard zum Uhrenabgleich Primary Servers: Direkte Zeitquelle (Funkuhr) Secondary Servers: indirekter Abgleich über Primary Servers Organisation der Server in stratums 1 Primary Server

9 Network Time Protocol (2/2) Betriebsmodi Multicast (im LAN) Procedure Call (Cristian) Symmetric: Beobachtung über länge Zeit Statistisches Fehlermodell Hosts passen ihre Zeit lokal an Zeit darf niemals rückwärts laufen! Verlangsamung/Beschleunigung der Uhr Verwendung mehrere Zeitserver Mehrere (8) Messungen geringste Latenz

10 Physische vs logische Zeit Oft benötigt ein Algorithmus keine Zeitangaben, sondern nur eine Reihenfolge Halbordnung: einige Events geordnet, andere (potentiell) gleichzeitig Logische Zeit basiert auf happened-before Relation In einem Prozess sind Events geordnet Versand einer Nachricht vor Empfang der Nachricht Transitive Ordnung Potential Causal Ordering: Kausaler Zusammenhang kann (muss nicht) bestehen

11 Beispiel für Happened-Before Notation für Happened-Before: x y a b, b c, c d, d f e a, e b, e c, e d, e f p 1 a b m 1 p 2 Phy sica l c d m 2 time p 3 e f

12 Lamport-Clock Berechnung von Happened-Before durch Timestamps Jeder Prozess hat eine Lamport-Clock L Vor jedem Event L erhöhen Jede versendete Nachricht erhält L als Timestamp Bei Erhalt einer Nachricht, setze lokales L := max(lokales L, erhaltenes L)+1 Totalordnung durch Hinzunehmen der Prozess-ID a b impliziert L(a)<L(b), aber nicht umgekehrt!

13 Problem mit Lamport-Timestamps Keine Aussage über Events ohne happened-before Relation möglich Begrenzte Anwendungsmöglichkeiten

14 Vector Clocks Idee: Mehr Information aufheben Vektor aus Timestamps pro Prozess (1,0,0) (2,0,0) p 1 a b m 1 p 2 (2,1,0) (2,2,0) c d m 2 Phy sica l time (0,0,1) (2,2,2) p 3 e f

15 Vector Clocks Algorithmus Initialisierung: V i [j]=0 V i [i]+=1 vor Anwendung auf ein Event P i inkludiert V i in jeder Nachricht Erhält P i eine Nachricht mit Timestamp t, so berechnet P i die merge operation V i [j] := max(v i [j], t[j]) V i [i]+=1

16 Anwendung der Vector Clocks V i [i] = Anzahl der Events von P i V i [j] (j i) = Anzahl der Events von P j, von denen P i kausal abhängen kann Vergleich von Vector Clocks V = V iff V[j] = V [j] j V V iff V[j] V [j] j V < V iff V[j] V [j] und V V Es gilt nun V(a)<V(b) a b Nachteil: Mehr Speicherplatz nötig Optimierung: nur nötige Teile übertragen

17 Global State Wie erfasst man den Zustand des Gesamtsystems? Kein einzelner Prozess in einem Distributed System hat ausreichende Informationen

18 Wozu braucht man Global State? p 1 p 2 obj ect ref erenc e me ssag e a. Garba ge colle ction gar bage ob ject Kann ein Objekt gelöscht werden? p 1 w a it-f or p 2 b. Dea dloc k Wird sich etwas tun? w a it-f or p 1 p 2 c. Termination pas sive activa te pas sive Ist das Programm fertig?

19 Prädikate von Global State Stability System erreicht Zustand S mit Pr(S)=TRUE Pr(S) bleibt TRUE in allen von S erreichbaren Zuständen Safety Pr=FALSE für S und alle von S erreichbaren Zustände Wichtig für unerwünsche Pr (z.b. Deadlock) Liveness In jeder bei S beginnenden Linearisierung kann ein Zustand erreicht werdenm in dem Pr=TRUE Wichtig für erwünschte Zustände (z.b. Terminierung)

20 Erfassen von Global State durch Cuts 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 Physical time Inconsistent cut (Wirkung ohne Ursache) Consistent cut Consistent cut C: events e C: f e f C

21 Snapshot-Algorithmus Erzeugung eines Systemabbilds Zustände und Nachrichten in Bewegung Global konsistent, aber nicht notwendigerweise ein Zustand, der real existiert hat Verwendung von Marker-Messages 1. Marker erhalten lokaler Zustand erfassen Danach alle eingehenden Nachrichten erfassen Marker aus bestimmten Eingangskanal Ende der Nachrichtenerfassung für diesen Kanal

22 Chandy and Lamport s snapshot Marker receiving rule for process p i On p i s receipt of a marker message over channel c: if (p i has not yet recorded its state) it records its process state now; records the state of c as the empty set; turns on recording of messages arriving over other incoming channels; else p i records the state of c as the set of messages it has received over c since it saved its state. end if Marker sending rule for process p i After p i has recorded its state, for each outgoing channel c: p i sends one marker message over c (before it sends any other message over c).

23 Beispiel P1 fordert bei P2 10 widgets um je 10$ an c p 2 1 p 2 c 1 $10 00 (no ne) $ acc ount w idgets acc ount w idgets

24 Beispiel Vorher: Anforderung 5 widgets 1. Globa l s tate S 0 <$1 000, 0> p c (empty) 1 2 p 2 <$5 0, 20 00> c 1 (empty) 2. Globa l s tate S 1 <$9 00, 0 > p c (Or der 10, $100 ), M 1 2 p 2 <$5 0, 20 00> c 1 (empty) 3. Globa l s tate S 2 <$9 00, 0 > p c (Or der 10, $100 ), M 1 2 p 2 <$5 0, 19 95> c 1 (fiv e w idge ts ) M 4. Globa l s tate S 3 <$9 00, 5 > p c (Or der 10, $100 ) 1 2 p 2 <$5 0, 19 95> c 1 (empty) (M = ma rke r messa ge) Endzustand: P1 <$1000,0>, P2 <$50,1995>, c1 <5 widgets>, c2 <>

25 Erreichbarkeit Stabiles Prädikat TRUE inm S snap Prädikat auch TRUE in S final actual execution e 0,e 1,... S init recording begins recording ends S final pre-snap: e ' 0,e' 1,...e' R-1 S snap post-snap: e ' R,e' R+1,...

26 Ende