Softwareentwicklung in verteilten Umgebungen, Teil 8 Time

Transcription

Softwareentwicklung in verteilten Umgebungen, Teil 8 Time
Softwareentwicklung in verteilten Umgebungen, Teil 8
Time
(Coulouris et al., Kapitel 14)
Dieter Schmalstieg
Jens Grubert
Dieter Schmalstieg
SVU – Time
Zeit und Uhren in Computersystemen
Network
• Uhren auf verschiedenen Computern laufen
nicht synchron  Probleme
• Beispiel: Make compiliert nur, wenn Quelldatei
neuer als
Objektdatei ist
Dieter Schmalstieg
SVU – Time
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
Dieter Schmalstieg
SVU – Time
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
Dieter Schmalstieg
Clock Drift
SVU – Time
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
Dieter Schmalstieg
SVU – Time
Wie Zeit in einem DS
synchronisieren?
Dieter Schmalstieg
SVU – Time
Digitale Zeitmessung
• Synchronisation mit Real-Zeit (extern)
– Abweichung intern-extern muss < Schwellwert bleiben
• Synchronisation untereinander (intern)
– Abweichung der Uhren untereinander muss <
Schwellwert bleiben
Dieter Schmalstieg
SVU – Time
Einfacher Zeitabgleich (Cristian‘s Algorithmus)
• Anfrage an time server
t_client = t_server + RTT/2
• Ok wenn RTT << geforderte genauigkeit
• Problem wenn Latenz C -> S != Latenz S -> C
Dieter Schmalstieg
SVU – Time
Berkeley-Algorithmus zur internen Synchronisation
• Time daemon fragt alle Computer nach der Zeit
(inkl. daemon selbst)
• Mittelwertbildung
• Anpassung aller Uhren
Dieter Schmalstieg
SVU – Time
Berkeley-Algorithmus zur internen Synchronisation
• Time daemon fragt alle Computer nach der Zeit
(inkl. daemon selbst)
• Mittelwertbildung
• Anpassung aller Uhren
Dieter Schmalstieg
SVU – Time
Berkeley-Algorithmus zur internen Synchronisation
• Time daemon fragt alle Computer nach der Zeit
(inkl. daemon selbst)
• Mittelwertbildung
• Anpassung aller Uhren
Dieter Schmalstieg
SVU – Time
Wie mit UTC übers Netzwerk
abgleichen?
Dieter Schmalstieg
SVU – Time
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 strata
[Bild von Roland Geider (PD)]
Dieter Schmalstieg
SVU – Time
Network Time Protocol (2/2)
• Betriebsmodi
–
–
–
–
Multicast (im LAN)
Procedure Call (Cristian)
Symmetric: Beobachtung über längere 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
Dieter Schmalstieg
SVU – Time
Logische Zeit
Dieter Schmalstieg
SVU – Time
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
Dieter Schmalstieg
SVU – Time
Beispiel für Happened-Before
• Happened-Before: xy
ab, bc, cd, df , ef
• Concurrent events: e||a, e||b, e||c, e||d,
p1
a
b
m1
Physical
time
p2
c
d
m2
p3
e
Dieter Schmalstieg
f
SVU – Time
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
• ab impliziert L(a)<L(b)
L(a)<L(b) impliziert NICHT ab
• Totalordnung durch Hinzunehmen der
Prozess-ID
Dieter Schmalstieg
SVU – Time
Problem mit Lamport-Timestamps
• Keine Aussage über
Events ohne
happened-before
Relation möglich
• Begrenzte
Anwendungsmöglichkeiten
Dieter Schmalstieg
SVU – Time
Vector Clocks
• Idee: Mehr Information aufheben
• Vektor aus Timestamps pro Prozess
• Vektorlänge N = Anzahl Prozesse
Dieter Schmalstieg
SVU – Time
Vector Clocks Algorithmus
•
•
•
•
Initialisierung: Vi [j]=0
Vi [i]+=1 vor Anwendung auf ein Event
Pi inkludiert Vi in jeder Nachricht
Erhält Pi eine Nachricht mit Timestamp t,
so berechnet Pi die merge operation
– Vi [j] := max(Vi [j], t[j])
– Vi [i]+=1
Dieter Schmalstieg
SVU – Time
Vector Clocks
(1,0,0) (2,0,0)
p1
a
b
m1
(2,1,0)
(0,
0, 0)
p2
p3
c
(0,0,1)
e
Dieter Schmalstieg
(2,2,0)
d
Physical
time
m2
(2,2,2)
f
SVU – Time
Vector Clocks
(1,0,0) (2,0,0)
p1
a
b
m1
(2,1,0)
(0,
1, 0)
p2
p3
c
(0,0,1)
e
Dieter Schmalstieg
Vi [i]+=1
(2,2,0)
d
Physical
time
m2
(2,2,2)
f
SVU – Time
Vector Clocks
(1,0,0) (2,0,0)
p1
a
b
m1
Vi [j] := max(Vi [j], t[j])
(2,1,0)
(2,
1, 0)
p2
p3
c
(0,0,1)
e
Dieter Schmalstieg
(2,2,0)
d
Physical
time
m2
(2,2,2)
f
SVU – Time
Vector Clocks
(1,0,0) (2,0,0)
p1
a
b
m1
(2,1,0)
(2,
1, 0)
p2
p3
c
(0,0,1)
e
Dieter Schmalstieg
(2,
2, 0)
(2,2,0)
d
Physical
time
m2
(2,2,2)
f
SVU – Time
Anwendung der Vector Clocks
• Vi [i] = Anzahl der Events von Pi
• Vi [j] (j≠i) = Anzahl der Events von Pj, von
denen Pi 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
Dieter Schmalstieg
SVU – Time
Ende
Dieter Schmalstieg
SVU – Time

Documents pareils