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

• Prof. Dr. Oliver Haase

Verteilte Systeme

Synchronisation I

1

Überblick

2

Synchronisation 1

• Zeit in verteilten Systemen
• Verfahren zum gegenseitigen Ausschluss

Synchronisation 2

• Globale Zustände
• Wahlalgorithmen

Zeit in verteilten Systemen

3

Motivation

4

• 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?

Beispiel: Verteilte SW-Entwicklung

5

• output.o scheint jünger als output.c → wird beim

nächsten make nicht neu übersetzt.

aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen]

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 t1 = t0 + ∆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 ∆tmax = δ/(2ρ) Sekunden synchronisieren.

• Beispiel:
• δ = 1msec, ρ = 10-5 ⇒ ∆tmax = 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.
• tneu = tserv + ((T4 - T1) - (T3 - T2)) / 2

12

aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen]

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

17

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

aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen]

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 pi 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

20

P1 P3 P2 a d h k g b c e f i j l m n

• 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

Umsetzung

• Jeder Prozess Pi hat eine logische Uhr, die beim Auftreten

eines Ereignisses a abgelesen wird und den Wert Ci(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 Pi wendet den folgenden Algorithmus an, um

seine Uhr Ci richtig zu stellen:

• Ci wird vor jedem neuen Ereignis in Pi um 1 erhöht
• wenn Pi eine Nachricht N sendet, dann schickt er den

aktuellen Wert von Ci mit

• bei Erhalt von (N, t) setzt Pi seine Uhr auf t, falls t > Ci,

danach Erhöhung um 1.

22

Umsetzung: Beispiel

23

P1 P3 P2 a d h k g b c e f i j l m n

13 9 5 14 14 6 15 16 15 16 17 17 18 18

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

26

• Begriff des gegenseitigen Ausschlusses
• Algorithmen in

VS zum Erreichen des gegenseitigen Ausschlusses

• Zentraler Algorithmus
• verteilter Algorithmus
• Token-Ring-Algorithmus
• Vergleich

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

Zentraler Algorithmus: Beispiel

(a) Prozess 1 bittet den Koordinator um Zugriff auf eine gemeinsam genutzte Ressource. Erlaubnis wird gewährt. (b) Prozess 2 bittet um Zugriff auf dieselbe Ressource. Koordinator antwortet nicht. (c) Sobald Prozess 1 Ressource freigibt, teilt er dies dem Koordinator mit, der dann die Anforderung von 2 beantwortet.

29

Zentraler Algorithmus: Eigenschaften

• gegenseitiger Ausschluss wird erreicht
• fair: Tokens werden in Reihenfolge der Anfragen vergeben
• einfach zu implementieren
• nur 3 Nachrichten pro Zugang zu kritischer Region

(Anfrage, Erlaubnis, Freigabe)

30

• Koordinator ist Single Point of Failure
• Keine Antwort kann lange Warteschlange oder toten

Koordinator bedeuten

• Performance Bottleneck in großen Systemen

+ _

Verteilter Algorithmus

• Besitzt keinen ausgewiesenen Koordinator.
• 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.

31

Verteilter Algorithmus

nach Ricart und Agrawala, 1981:

32

Ricart und Agrawala: Beispiel

33

(a) P0 bittet alle Prozesse um Erlaubnis, T0 = 8 P2 bittet alle Prozesse um Erlaubnis, T2 = 12 (b) P1 erteilt P0 und P1 Erlaubnis P2 erteilt P0 Erlaubnis, da T0 < T2 P0 hält Erlaubnis an P2 zurück, da T0 < T2 (c) P0 erteilt P2 nach eigenem Zugriff Erlaubnis

Verteilter Algorithmus: Eigenschaften

34

• Jeder Knoten ist ein Single Point of Failure (lässt sich durch

sofortige Bestätigungsnachrichten minimieren, aber nicht ausschalten)

• Jeder Prozess muss bei jeder Entscheidung mitwirken, auch

wenn er selbst nicht konkurriert (Skalierbarkeit!)

• mehr Nachrichten, größere Netzwerklast

_ Nun, warum überhaupt betrachten? →zeigt, dass verteilter Algorithmus möglich ist, und →dass hier noch Forschungsbedarf besteht!

Token-Ring-Algorithmus

• Prozesse werden in logischem Ring angeordnet (z.B. anhand

(Network-ID, Prozess-ID)-Kombination

• Token kreist durch Ring.
• Wenn Prozess, der Token bekommt, einen kritischen

Abschnitt betreten möchte → selbiges einmal tun, danach Token weitergeben

• Ansonsten Token einfach weitergeben.

35

Token-Ring: Eigenschaften

• Korrektheit leicht zu sehen
• fair: Token wird der Reihe nach vergeben → kein

Aushungern

36

• tote Prozesse müssen erkannt werden
• verlorene Token schwer zu erkennen (lange

Verweilzeit)

• Koordinator muss verlorenes Token neu einspeisen

+ _

• max. Wartezeit: alle anderen Prozesse in je einem kritischen

Abschnitt

Vergleich der Algorithmen

37

Algorithmus Nachrichten pro Ausführung kritischer Abschnitt Verzögerung vor Eintritt [in Nachrichten] Probleme zentral 3 2 Ausfall Koordinator verteilt 2(n -1) 2(n -1) Ausfall eines Prozesses Token Ring 1 bis ∞ 0 bis n -1 verlorener Token

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.

38