Verteilte Systeme Synchronisation I Prof. Dr. Oliver Haase 1 - PowerPoint PPT Presentation

Verteilte Systeme Synchronisation I Prof. Dr. Oliver Haase 1

Überblick Synchronisation 1 ‣ Zeit in verteilten Systemen ‣ Verfahren zum gegenseitigen Ausschluss Synchronisation 2 ‣ Globale Zustände ‣ Wahlalgorithmen 2

Zeit in verteilten Systemen 3

Motivation ‣ Für viele dieser Algorithmen ist ein gemeinsames Verständnis der ‘Zeit’ in allen beteiligten Knoten notwendig: • wer hat ein Ereignis zuerst ausgelöst? • wer hat auf zuerst / zuletzt auf eine Ressource zugegriffen? ‣ In einem zentralisierten System kein Problem, da es dort nur eine Zeitquelle gibt. ‣ In verteilten Systemen hat jedoch jeder Knoten seine eigene Zeitquelle und damit u.U. eine andere Uhrzeit. ‣ Problem? 4

Beispiel: Verteilte SW-Entwicklung aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen ] ‣ output.o scheint jünger als output.c → wird beim nächsten make nicht neu übersetzt. 5

Zeit in verteilten Systemen ‣ Computer haben eine lokale Uhr, die mit einer bestimmten Frequenz H einen Interrupt auslöst (Clock Tick). Die Interrupts werden gezählt und messen die Zeit. • typische Frequenz H : 50 oder 60 Hz, i.e. 50/sec oder 60/sec ‣ Problem: die Uhren unterschiedlicher Computer zeigen unterschiedliche Zeiten an! • Problem 1: unterschiedliche Startzeiten → kann relativ leicht gelöst werden • Problem 2: unterschiedliche Laufzeiten → schwieriger zu lösen 6

Universal Coordinated Time (UTC) ‣ weltweite Standardzeit, Grundlage aller staatlicher Zeiterfassungen ‣ basiert auf TAI (Temps Atomique International), i.e. gemittelte Atomzeit ‣ UTC passt TAI regelmässig um Schaltsekunden der Sonnenzeit an (Sonnensekunde wird permanent länger) ‣ hat mittlere Greenwich-Zeit abgelöst ‣ Empfänger für UTC-Sender mittlerweile recht billig 7

Genauigkeit von Uhren ‣ Chips haben eine Genauigkeit - Draftrate ρ - von etwa 10 -5 . ‣ Beispiel: • Bei H = 60Hz sollte eine Uhr 216 000 mal pro Stunde ticken. • Realistisch ist ein Wert zwischen 216 998 und 216 002. • eine Uhr läuft korrekt, wenn sie die vom Hersteller angegebene Driftrate ρ einhält, auch wenn sie dann zu langsam oder schnell läuft. 8

Uhrensynchronisation ‣ Folge: zu einem Zeitpunkt t 1 = t 0 + ∆ t nach der Synchronisation zweier Uhren können die beiden Uhren maximal δ = 2 ρ∆ t auseinander liegen. ‣ Beispiel: • ∆ t = 20sec, ρ = 10 -5 ⇒ δ = 0,4msec ‣ Will man sicherstellen, dass zwei Uhren niemals mehr als ein gewünschter Wert δ auseinander liegen, muss man die Uhren innerhalb von ∆ t max = δ /(2 ρ ) Sekunden synchronisieren. ‣ Beispiel: • δ = 1msec, ρ = 10 -5 ⇒ ∆ t max = 50sec 9

Uhrensynchronisation ‣ Nicht jeder Rechner hat einen UTC-Empfänger, so dass keine externe Synchronisation durchgeführt werden kann. ‣ Stattdessen gibt es Uhrensynchonisationsalgorithmen, die auf der Verwendung weniger Zeitserver basieren. 10

Der Algorithmus von Christian ‣ Es wird die Existenz eines UTC-Empfängers im System angenommen, der dann als Zeit-Server fungiert. ‣ Jede andere Maschine sendet mind. alle δ /(2 ρ ) ein Time Request an den Server, der so schnell wie möglich mit der aktuellen UTC antwortet. ‣ Nun könnte man Uhr auf erhaltene UTC-Zeit setzen. ‣ Erstes ABER: • Wenn Anfragender schnelle Uhr hat, dann müsste seine Uhr zurückgesetzt werden. Verboten, da kein Zeitpunkt zweimal auftaucht darf! • Lösung: Uhr wird graduell angepasst, indem sie eine Weile langsamer läuft, d.h. verringerte Zeitspanne pro Clock-Tick. 11

Der Algorithmus von Christian ‣ Zweites ABER: • Wegen Signallaufzeit für die Nachrichten ist Antwort, wenn sie kommt, schon veraltet. • Lösung: Signallaufzeit wird gemessen bzw. geschätzt. • Annahme: Signallaufzeit in beide Richtungen gleich. aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen ] • t neu = t serv + ((T 4 - T 1 ) - (T 3 - T 2 )) / 2 12

Network Time Protocol NTP ‣ Entwickelt in den 1980er Jahren, inzwischen ein IETF RFC ‣ Ziele • Clients sollen sich möglichst genau mit UTC synchronisieren können, trotz stark schwankender Übertragungsverzöger- ungen im Netz • Bereitstellung eines zuverlässigen Dienstes mittels Redundanz • Clients sollen in der Lage sein, sich oft zu synchronisieren, Skalierbarkeit wird damit ein Thema 13

Funktionsweise von NTP ‣ Der NTP-Dienst wird von einem Netzwerk von Servern erbracht. ‣ Die Primary Servers sind direkt mit der UTC-Quelle verbunden. ‣ Die Secondary Servers synchronisieren sich mit den Primary Servers. ‣ Das Server-Netzwerk ist rekonfigurierbar,um auf Fehler reagieren zu können. 14

Funktionsweise von NTP ‣ Die Server tauschen häufig Nachrichten aus, um Netzwerkverzögerungen und Uhrungenauigkeiten zu messen. ‣ Clients synchronisieren sich mit dem Server mit der geringsten gemessenen Signallaufzeit. ‣ NTP erreicht eine weltweite Genauigkeit von 1 bis 50 ms. 15

Berkeley-Algorithmus ‣ Entwickelt für eine Gruppe von Berkeley-Unix-Rechnern ‣ Sinnvoll, wenn kein UTC-Server zur Verfügung steht ‣ Ein Rechner wird als Zeit-Server bestimmt ‣ Zeit-Server fragt regelmäßig aktiv bei allen Rechner nach aktueller Zeit und bildet Durchschnitt ‣ Durchschnitt wird allen Rechnern mitgeteilt, die ihre Uhren danach anpassen 16

Berkeley-Algorithmus aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen ] a) Zeit-Daemon (Zeit-Server) sendet seine Zeit an alle b) jeder Rechner antwortet mit seiner Differenz c) Zeit-Daemon errechnet neuen Durchschnitt und sendet jedem Rechner Korrekturdifferenz 17

Logical Time ‣ Generell unmöglich, physikalische Uhren in verteilten System absolut zu synchronisieren → unmöglich, basierend auf Zeit 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 . ‣ Lösung: Logische Zeit (logical time) 18

Happened-Before-Beziehung ‣ eingeführt von Leslie Lamport ‣ a → b bedeutet: a hat vor b stattgefunden ‣ auch relation of causal ordering • wenn in einem Prozess p i gilt: a → i b, dann gilt auch für das Gesamtsystem: a → b • für jede Nachricht m gilt: send(m) → receive(m) • a → b und b → c, dann auch a → c (Transitivität) • Ereignisse, die nicht in dieser Beziehung stehen, gelten als nebenläufig 19

Happened-Before: Beispiel P1 m a e i P2 b d g j n P3 c f h k l ‣ a → e → i → m; b → d → g → j → n; c → f → h → k → l ‣ a → d, g → h, h → k, k → m ‣ deshalb z. B.: a → g, g → m ‣ nebenläufig z.B.: a, b, c; und e, d, f 20

Umsetzung ‣ Jeder Prozess P i hat eine logische Uhr, die beim Auftreten eines Ereignisses a abgelesen wird und den Wert C i (a) liefert. ‣ Dieser Wert muss so angepasst werden, dass er als C(a) eindeutig im ganzen verteilten System ist. ‣ Ein Algorithmus, der die logischen Uhren entsprechend richtig stellt, muss folgendes umsetzen: Wenn a → b, dann C(a) < C(b). 21

Umsetzung ‣ Jeder Prozess P i wendet den folgenden Algorithmus an, um seine Uhr C i richtig zu stellen: • C i wird vor jedem neuen Ereignis in P i um 1 erhöht • wenn P i eine Nachricht N sendet, dann schickt er den aktuellen Wert von C i mit • bei Erhalt von (N, t) setzt P i seine Uhr auf t, falls t > C i , danach Erhöhung um 1. 22

Umsetzung: Beispiel P1 13 14 15 18 m a e i 9 14 15 16 17 P2 b d g j n 5 6 16 17 18 P3 c f h k l 23

Zusammenfassung ‣ Die absolut selbe Zeit in allen Rechnern eines Systems kann nicht erreicht werden. ‣ Hardware-Synchronisation ist möglich, jedoch haben nicht alle Rechner einen UTC- Empfänger ‣ Synchronisationsalgorithmen für die physikalische Zeit funktionieren recht gut (NTP). ‣ In vielen Anwendungen genügt Wissen über die Ordnung von Ereignissen ohne quantitative Zeitangaben → Verwendung logischer Zeit 24

Verfahren zum gegen- seitigen Ausschluss 25

Überblick ‣ Begriff des gegenseitigen Ausschlusses ‣ Algorithmen in VS zum Erreichen des gegenseitigen Ausschlusses • Zentraler Algorithmus • verteilter Algorithmus • Token-Ring-Algorithmus ‣ Vergleich 26

Definition ‣ Wenn sich zwei oder mehrere Prozesse beim Zugriff auf gemeinsame Daten koordinieren müssen, um die Konsistenz der Daten zu erhalten, geschieht dies am einfachsten über das Konzept der kritischen Region . ‣ Jeweils nur ein Prozess darf in einer kritischen Region aktiv sein, d.h., es wird gegenseitiger Ausschluss (mutual exclusion) erreicht. ‣ Ein-Prozessor-Systeme: Semaphore oder Monitore ‣ Wie funktioniert das in verteilten Systemen? 27

Zentraler Algorithmus ‣ Einer der Prozesse wird zum Koordinator für eine kritische Region bestimmt. ‣ Alle anderen müssen sich nun zuerst an den Koordinator wenden, bevor sie die entsprechende Region betreten. ‣ Wenn die kritische Region frei ist, erhält der Prozess das OK vom Server. Nach Abarbeitung der Aufgaben gibt der Prozess dieses Token zurück. ‣ Ist die Region nicht frei, wird der anfragende Prozess in eine Warteschlange aufgenommen. Er erhält erst das Token, wenn alle Prozesse vor ihm bedient wurden. 28