5.1 Motivation. Globale Zeit. Zeit in Rechnern. Verteilte Betriebssysteme

Transkript

1 Verteilte Betriebssysteme Wintersemester 2017/ Motivation 5.1 Motivation Verteilte Betriebssysteme 5. Kapitel Uhrensynchronisation m letzten Kapitel haben wir uns Gedanken über verschiedene Semantiken für eine korrekte Reihenfolge gemacht m alltäglichen Leben definiert man Reihenfolgen i.d.r. über Zeit Es wird eine globale Zeit angenommen, die von Uhren abgelesen wird Prof. Matthias Werner Professur Betriebssysteme 2 / 37 Globale Zeit 5.1 Motivation 5.1 Motivation Zeit in Rechnern Die Bestimmung der Zeit und die Messung von Zeitdauern ist unverzichtbar zur Koordination menschlicher Aktivitäten Hierfür müssen unsere Uhren synchronisiert sein Synchronisation der Uhren mittels Kirchturmuhr, Telegraphie, Radio, GPS Uhrensynchronisation ermöglichte in der Schifffahrt erst die Längengradbestimmung Die Existenz einer globalen Zeit haben wir verinnerlicht Bildquelle: NMM London, MoD Art Collection Nutzung von Zeitstempeln, um die Aktualität von Daten zu bewerten... Leistungsmessungen durchzuführen... die Gültigkeit von Zugriffsberechtigungen zu bestimmen... eine Totalordnung von Ereignissen zu bewirken (z.b. für Synchronisation, Debugging und Audit)... Sensordaten auszuwerten und Aktuatoren zu steuern Achtung Das Konzept der Existenz einer globale Zeit ist auch nur eine Modellvorstellung. 3 / 37 4 / 37

2 5.2 Zeit und Uhren 5.2 Zeit und Uhren Begriffe Eine Uhr bildet die Realzeit t auf einen Zeitstempel C(t) ab Auflösung Kleinste Zeitspanne um die sich zwei Werte einer Uhr unterscheiden können Tickdauer Offset Abweichung der Uhr von der Realzeit zu einem Zeitpunkt, d.h. C(t) t Drift Abweichung der Geschwindigkeit der Uhr von der Realzeit ±10 6 bei Quarzuhren bzgl. UTC (2s pro Monat) ±10 18 bei Atomuhren bzgl. der idealen S-Sekunde Lokale Uhren 5.2 Zeit und Uhren Jeder lokale Knoten hat eine eigene ungenaue, digitale Uhr Der Uhren-Drift ist unterschiedlich Ohne Synchronisierung können sich die Werte der Uhren beliebig weit voneinander entfernen Uhrensynchronisation notwendig Nur durch Nachrichtenaustausch möglich Hierbei spielt die Nachrichtenlaufzeit eine wichtige Rolle nterne Synchronisation: Teilnehmer im verteilten System einigen sich, kein Bezug zu physischer Zeit Externe Synchronisation: Zeitquelle außerhalb des eigenen Systems, eigene Zeitzone berücksichtigen 5 / 37 Korrekte Uhren 5.2 Zeit und Uhren Eine korrekte Uhr hat eine beschränkte Drift ρ max 6 / 37 Diskussion 5.2 Zeit und Uhren Auch eine zu schnelle oder zu langsame Uhr wird als korrekt angesehen Drift wird nur im Bereich t betrachtet, der größer als die Auflösung ist 1 dc(t) 1 + ρ max (1) 1 + ρ max dt C(t) t zu schnell, dc dt > 1 exakt, dc dt = 1 (Wert der Uhr steigt linear mit der realen Zeit) zu langsam, dc dt < 1 7 / 37 Bedingung wird häufig angegeben als Aber: Betrachten ρ = 1 1 ρ dc(t) dt 1 + ρ (2) Bedingung (1): Uhr ist korrekt, solange sie nicht schneller als doppelt so schnell wie die perfekte Uhr und nicht langsamer als halb so schnell wie sie läuft Vereinfachte Bedingung (2): Uhr ist korrekt, solange sie nicht schneller als doppelt so schnell wie die perfekte Uhr läuft, aber sie darf stehen bleiben Bei ρ > 1 dürfte eine korrekte Uhr sogar rückwärts laufen Für meisten praktischen Belange (sehr kleines ρ) ist (2) ausreichend Uhren, die stets korrekte Zeit anzeigen, sind perfekte Uhren (Modellvorstellung!) 8 / 37

3 5.3 nterne Synchronisation 5.3 nterne Synchronisation 5.3 nterne Synchronisation Unvorhersehbare Nachrichtenlaufzeiten Uhrensynchronisation nach Cristian n der Realität sind Nachrichtenlaufzeiten meist lastabhängig und unbeschränkt Die Laufzeit ist bei höherer Last größer als bei niedriger Last Die Laufzeit kann beliebig lang sein Minimale Laufzeit min kann nicht unterschritten werden n diesem Fall führt das bisherige Verfahren zu einem Fehler bei der Anpassung Szenario: Prozess P2 will seine Uhr auf P1 abstimmen Vorläufige Annahme: Konstante Nachrichtenlaufzeit tx t2 = 5 t=7 P1 5 Zeit? Pr P2 t1 = 4 t3 = 8 á P2 stellt Uhr um 1 ZE zurück P2 passt seine Uhr um t2 + tx t3 an Soll die maximale Abweichung kleiner als bleiben, so ist eine erneute Synchronisation spätestens nach ρ notwendig 9 / nterne Synchronisation def Round Trip Time (RTT) D = (t3 t1 ) Sei t die lokale Zeit von P1, wenn P2 die lokale Zeit t3 hat t liegt im ntervall [t2 + min, t2 + D min] Die bestmögliche Schätzung für t ist die ntervallmitte t2 + Daher korrigiert P2 seine Uhr um t2 + Der maximaler Fehler dieser Anpassung ist emax = t2? D 2 D 2 min min dee: 1. Akzeptiere Wert der Referenzuhr nur, wenn die RTT D einen bestimmten Grenzwert U nicht überschreitet á D U 2. Wiederhole bei Fehlschlag den Versuch maximal k-mal, jeweils nach einer Wartezeit tw Sei PrU die Wahrscheinlichkeit, dass D U bei beliebigen Versuch (Fehlschlag) Wahrscheinlichkeit für k Fehlversuche: (PrU )k Erwartungswert für Anzahl von Versuchen: E = P1 1 1 (PrU ) P1 t2 P2 t1 Probabilistische Begrenzung des max. Fehlers D 2 t3 t min 10 / nterne Synchronisation Unvorhersehbare Nachrichtenlaufzeiten (Forts.) tx min t3 11 / 37 2 min P2 emax U 12 / 37

4 5.3 nterne Synchronisation Maximales Synchronisationsintervall Zwei korrekte Uhren mit der Drift ρ sollen nicht mehr als auseinanderlaufen Nach welcher Zeit muss spätestens eine Synchronisation stattgefunden haben? Annahme: zu t = 0 sind die Uhren synchron Betrachten Worst Case: Maximale Abweichung der Uhren Uhren C 1 und C 2 gehen maximal vor/nach dc 1 (t) dt dc 2 (t) dt = 1 + ρ = ρ 13 / nterne Synchronisation Maximales Synchronisationsintervall (Forts.) Uhren müssen also spätestens nach 1+ρ 2ρ+ρ synchronisiert werden 2 Für sehr kleine ρ: t 1 2ρ Wir geben die Annahme auf, dass die Uhren zu t = 0 synchron sind probabilistische Synchronisation Nach der letzten erfolgreichen Synchronisation ist die Abweichung maximal e max = D 2 min Es muss so synchronisiert werden, dass nicht mehr als = e max bis zum erfolgreichen Versuch verstreicht 5.3 nterne Synchronisation Maximales Synchronisationsintervall (Forts.) Forderung: C 1 (t) C 2 (t)! Worst case zum Zeitpunkt t: C 1 (t) = (1 + ρ)t C 2 (t) = t 1 + ρ Folglich: (1 + ρ)t t 1 + ρ Synchronisationszeit (1 + ρ) 2 t t 1 + ρ 2ρ + ρ2 t 1 + ρ t 1 + ρ 2ρ + ρ 2 14 / nterne Synchronisation Anpassung der lokalen Uhrzeit Anforderungen (aus Korrektheitsforderungen) Große Sprünge der Uhrzeit sollen vermieden werden Die Uhr darf nie rückwärts laufen Lösung Die lokale Uhr wird solange etwas langsamer bzw. schneller betrieben, bis der Offset ausgeglichen wurde t 1 2ρ ( e max) t W (3) 1 Pr U 15 / / 37

5 5.3 nterne Synchronisation Berkeley-Algorithmus 5.3 nterne Synchronisation Berkeley-Algorithmus (Forts.) Algorithmus zur internen Uhrensynchronisation Synchronisiert eine Menge von Uhren untereinander Nicht notwendigerweise Bezug zur Realzeit vorhanden Enwickelt 1989 an der University of California, Berkeley [GZ87] Funktionsweise 12:00 11:55 12:08 12:00 12: :00 11:55 12: Das System besteht aus einem Master und Slaves Der Master ermittelt für jeden Slave dessen Abweichung Wieder Annahme über konstantes t X n diesem Fall spielen Verzögerungen keine Rolle Begründet mit Ethernet als Zielplattform Korrektur um die Differenz vom Durchschnittswert und Abweichung +1 12:01 12: :01 Avg = = M = 1 0 = 1 S 1 = 1 ( 5) = 6 S 2 = 1 8 = 7 17 / nterne Synchronisation Berkeley-Algorithmus (Forts.) Auswahl eines Schwellwertes für die Abweichung Aussortieren stark abweichender Maschinen (Durchschnittsberechnung) Zu klein: Nur Synchronisation einer kleinen Teilmenge der Slaves Zu groß: Fehlerhafte Slaves verschlechtern die Präzision der synchronisierten Zeit Wert bei 20ms in der Originalpublikation von 1987 Master muß fehlertolerant sein Leader Election Problem Auch eine interne Synchronisation soll sich typischerweise an der echten Uhr, also der globalen Zeit orientieren Was ist das überhaupt? 18 / 37 Globale Zeit Älteste Grundlage der Zeitmessung: Astronomie UT - Universal Time: Astronomische mittlere Sonnenzeit Ermittelt durch astronomische Beobachtung Eine mittlere Solarsekunde ist 1/86400 eines mittleren Solartages Folgt den Schwankungen der Erdrotation Variierende Zeiteinheit Solartag wird jedes Jahrhundert ca. 1.7ms länger (Mondeffekte), vor 300 Millionen Jahren hatte ein Jahr noch 400 Tage. 19 / / 37

6 Globale Zeit (Forts.) Globale Zeit (Forts.) TA - Temps Atomique nternational: nternationale Atomzeit Basiert auf Strahlungsfrequenzen des Cäsium 133 Atoms Gewichtetes Mittel von ca. 260 Atomuhren weltweit Standardabweichungen im Bereich von wenigen Nanosekunden Zählung seit , zunehmende Abweichung zwischen UT und TA Effekte durch Atmosphäre, Strahlung schwarzer Löcher und Gravitationseffekte UTC: Koordinierte Weltzeit Temps universel coordonné bzw. Coordinated Universal Time Schaltsekunden zum Ausgleich der UT-Schwankungen ( > 0.6s) Stromnetz wird durch UTC synchronisiert, mit Schaltsekunde 51Hz/61Hz Länge einer UTC-Sekunde konstant, definiert aus internationaler Atomzeit Verbreitung per Radiosignal (±10ms) oder Satellit (±0.5ms) Zeitzonen relativ zu UTC Quelle: Synchronisation durch Messung von GPS-Signalen und Satellitenkommunikation 21 / 37 Quelle: Wikipedia Network Time Protocol NTP (Forts.) Protokoll zur Synchronisation von (Rechner-)uhren mittels nternet Mechanismus zur externen Uhrensynchronisation Große und variierende Verzögerungen von Nachrichten Unterschiedliche Qualität der Zeit-Server Redundante Kommunikationspfade Skalierbarkeit für große Anzahl periodisch anfragender Clients Schutz durch Authentifizierung Baum von Servern bis zu den Endnutzergeräten (ntpq -pn) Ausgangspunkt ist UTC-Zeitquelle, z.b. Atomuhr, bei Stratum 1 - Server >320 Stratum 1 - Server, Pool mit >3800 Servern, geschätzt 25 Millionen Knoten Eigene NTP-nfrastrukturen in Behördennetzwerken (FAA, Weather Service,...) Schiffe, NASA Shuttle, geplant für interplanetares nternet Für 99% aller NTP-Clients beträgt der Fehler zur Referenzzeit < 30 ms 23 / 37 Network Time Protocol NTP 22 / 37 DAVD MLLS Boiled down, really the only thing the protocol does is occasionally read the clock in another machine, tell whether the system clock is fast or slow, and nudge the clock oscillator one way or the other, just like the Big Ben timekeepers in London. Of course, the devil is in the details 24 / 37

7 Network Time Protocol NTP (Forts.) Eines der ältesten UDP-Protokolle (RFC 958 aus 1985) Eigene Duplikaterkennung, keine Nachrichtenfragmentierung Version 3 aus dem Jahr 1992 (25 MHz Maschinen, kaum Bandbreite) Mittlerweile Version 4 Anpassung an Gigabit-Netze und Gigahertz-Rechner Algorithmen zur Justierung der Uhr direkt im Betriebssystemkern 25 / 37 Network Time Protocol NTP (Forts.) Network Time Protocol NTP (Forts.) Austausch von Zeitstempeln Bestimmung von Offset o i und Verzögerung d i zum Zeitpunkt T 4 Es gilt: T 2 = T 1 + m + o i und T 4 = T 3 + m o i Schätzung der Verzögerung: d i = m + m = (T 4 T 1 ) (T 3 T 2 ) Schätzung des Offset: o i = 0.5((T 2 T 1 ) + (T 3 T 4 )) m, m 0, somit o T 2 T 1 und o T 4 T 3 Es ergibt sich: o i d i /2 o o i + d i /2 P 2 P 1 T 1 T 2 T 3 m o i m 26 / 37 Network Time Protocol NTP (Forts.) T 4 Sampling und Filterung von < o i, d i > Paaren, anschließend Filterung o j für das kleinste d j wird verwendet Selektion und Clustering der Ergebnisse verschiedener Server Lokaler Rechner passt seine Uhrenfrequenz an, um Drift auszugleichen NTP Zeitstempel ist ein 64-Bit UNT Anzahl der S-Sekunden seit (prime epoch), relativ zu UTC Präzision von 232 Picosekunden NTP Version 4 fügt Era-Zähler ein, um Jahr 2036-Problem zu vermeiden Datenpaket enthält leap indicator Nach 8 erfolglosen Anfragen wird Server als unerreichbar markiert Zuverlässigkeit = kleines Stratum + kleinste Verzögerung Akkumulierte Statistiken über alle Server im Pfad (root dispersion / delay) 27 / / 37

8 NTP Missbrauch Missbrauch des Protokolls erst in den letzten 10 Jahren Eigene Security-Mechanismen, da übliche Verfahren synchrone Uhren brauchen Beispiel: Fest eingetragene NTP-Server Einige mplementierungen versenden fälschlicherweise im Sekundentakt Anfragen, bis eine Antwort eintrifft Bei Fehlkonfiguration (Firewall) und vielen Geräten (Billig-Router) entsteht eine ungewollte DDOS-Attacke auf einen einzelnen Server Beispiel NETGEAR-Fall: Pakete/s von ca Geräten Beispiel: NTP-basierte Verstärkungsangriffe Grundlage ist der Versand von Paketen mit gefälschter P-Absenderadresse Server antworten dem Opfer Kommando monlist im NTP-Protokoll liefert die letzten 600 Clients Dokumentierte Angriffe mit bis zu 400GBps Publikation 1 aus 2014 dokumentiert betroffene NTP-Server Marzullo-Algorithmus Teilalgorithmus zur Bestimmung eines Zeitintervalls bei überlappenden Quellen Annahme: Zeitquellen bieten Zeit mit Vertrauensintervallen Ziel: Kleinstes ntervall mit der größten Anzahl von übereinstimmenden Quellen / 37 Marzullo-Algorithmus (Forts.) Zeitdaten als ntervall [c r, c + r] Zwei Tupel der Form (offset, type) pro Quelle: (c r, 1) und (c + r, 1) Liste der Tupel nach ersten Wert sortieren Anschließend: NT : best =0 /* largest number of overlapping intervals */ NT : count =0 /* current number of overlapping intervals */ DO LOOP FOR ALL Tupels i in List count := count - type [i] F count > best THEN best := count best_start := offset [i] best_end := offset [i+1] END F END LOOP RETURN [ best_start, best_end ] 30 / 37 EEE 1588 Precision Time Protocol (PTP) Synchronisation von Uhren mit Fokus auf Präzision (100ns Bereich) Anwendung in Fahrzeugen, ndustrieautomatisierung, Messumgebungen Hardware muss Zeitstempel eines speziellen Ethernet-Pakets erfassen können Standard ist Broadcast-Modell mit Grandmaster als Zeitquelle Kaum Unterschiede zum NTP-Protokoll Fokus auf lokale Netze, sonst spezielle Unterstützung im Router nötig Definition verschiedener Uhrenarten Ordinary Clock: Zeitquelle oder -konsument Boundary Clock: Weitergabe von Zeitinformationen über Netzwerkgrenze Transparent Clock: Korrektur und Weiterleitung von Zeitinformationen 31 / / 37

9 5.5 Grenzen der Synchronisation 5.5 Grenzen der Synchronisation Wie gut können Uhren synchronisiert werden? LUNDELUS und LYNCH, 1984 Annahmen: Lokale Uhren haben keine Drift Kommunikationszeiten im ntervall [t, t + ε] Stand der Uhren anfangs unbekannt 5.5 Grenzen der Synchronisation Grenzen der Synchronisation (Forts.) Abläufe im Worst Case Alle Abläufe e i, i = 1,..., n sind lokal nicht unterscheidbar Theorem 5.1 Es gibt keinen Algorithmus, der n Uhren enger als auf ein ntervall der Größe ε(1 1 n ) garantiert synchronisiert. Grenze ist hart: Es gibt Algorithmen, die Grenze garantieren. 33 / Grenzen der Synchronisation Grenzen der Synchronisation (Forts.) 34 / Grenzen der Synchronisation nkorrekte Uhren Sei C i der lokale Uhrenwert von Knoten i und δ die Abweichung untereinander C n C 1 + δ für Ablauf e 1 (4) C i 1 + ε C i + δ bzw. C i 1 C i + δ ε für Ablauf e i, i = 2,..., n (5) Addiere 4 und 5 n C i i=1 n C i + n δ (n 1) ε i=1 (n 1) ε n δ ( δ ε 1 1 ) n nkorrekte Uhren können jede beliebige Zeit anzeigen und das bei jeder Abfrage! Auch Sprünge oder rückwärts laufende Uhren möglich Jede Mittelwertbildung schlägt fehl Lösung: Byzantinisches Agreement Vorlesung Verlässliche Systeme Anforderung: weniger als ein Drittel aller Uhren dürfen fehlerhaft sein Anwendungsbeispiel: Synchronisation in FlexRay (Kommunikationsplattform für Kraftfahrzeuge) 35 / / 37

10 Literatur Literatur [Cri89] [LL84] Flaviu Cristian. Probabilistic Clock Synchronization. n: Distributed Computing 3.3 (1989), S Jennifer Lundelius und Nancy A. Lynch. An Upper and Lower Bound for Clock Synchronization. n: nformation and Control 62.2/3 (1984), S [Mat89] Friedemann Mattern. Verteilte Basisalgorithmen. Springer, 1989, Kapitel 5: Virtuelle Zeit in verteilten Systemen [Lam78] [Kul+14] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. n: Commun. ACM 21.7 (Juli 1978), S Sandeep S. Kulkarni u. a. Logical Physical Clocks. English. n: Principles of Distributed Systems. Hrsg. von Marcos K. Aguilera, Leonardo Querzoni und Marc Shapiro. Bd Lecture Notes in Computer Science. Springer nternational Publishing, 2014, S / 37