Prof. Dr. Oliver Haase

Verteilte SystemeReplikation & Konsistenz I

1

Überblick

2

Replikation & Konsistenz I

‣ Ziele von Replikation

‣ Replikationsmodelle

• datenzentriert

• Client-zentriert

Replikation & Konsistenz II

‣ Replikationsverwaltung

‣ Konsistenzprotokolle

Ziele von Replikation

‣ Replikation bedeutet das Halten mehrerer Kopien eines Datums

‣ Ein Prozess, der auf dieses Datum zugreifen will, kann auf jede beliebige Replika zugreifen.

‣ Im Idealfall erhält er immer das gleiche Ergebnis.

‣Was also erreicht werden muss, ist die Konsistenz der Kopien

‣Wobei unterschiedliche Anwendungen unterschiedliche Anforderungen an die Striktheit der Konsistenz haben.

3

Ziele von Replikation‣ Steigerung der Verlässlichkeit eines Dienstes bzw. der

Verfügbarkeit eines Datums• Wenn ein Replikat nicht mehr verfügbar ist, können andere

verwendet werden.

• Besserer Schutz gegen zerstörte/gefälschte Daten: gleichzeitiger Zugriff auf mehrere Replikate, das Ergebnis der Mehrheit wird verwendet

‣ Steigerung der Leistungsfähigkeit des Zugriffs auf ein Datum• Bei großen Systemen: Verteilung der Replikate in

verschiedene Netzregionen oder einfache Vervielfachung der Server an einem Ort

4

Das große Problem‣ Die Replikas müssen konsistent gehalten werden.

‣ Das ist insbesondere ein Problem, wenn• es viele Replikas gibt

• die Replikas weit verstreut sind.

‣ Es gibt eine Reihe von Lösungen zur strikten Konsistenzhaltung, die jedoch die Leistung des Gesamtsystems negativ beeinflussen.

‣ Dilemma: wir wollen bessere Skalierbarkeit und damit bessere Leistung erreichen, aber die dazu notwendigen Mechanismen verschlechtern die Performance.

‣ Lösung: keine strikte Konsistenz

5

Anwendungsbeispiel: News-Bulletin‣ Ansicht 1:

6

‣ Ansicht 2:

‣ Problem: Nachrichten

• tauchen in unterschiedlicher Reihenfolge auf

• fehlen

‣ Mag für diese Anwendung ok sein, aber andere?

System-Modell‣ Daten im System = Sammlung von Objekten (Datei, Java-

Objekt, etc.)

‣ Jedes logische Objekt wird durch eine Reihe physischer Objekte realisiert, die Replikate.

‣ Die Replikate müssen nicht zu jeder Zeit absolut identisch sein (sie können es tatsächlich auch gar nicht sein).

‣ Die Replikations-Intelligenz kann in den Objekten platziert sein oder außerhalb (in einer Middleware).

• Vorteil der letzteren Methode: Anwendungsprogrammierer ist frei von Überlegungen zur Replikation

7

Modell eines verteilten Datenspeichers

8

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

Konsistenzmodelle

‣Was ist ein Konsistenzmodell?• Vertrag zwischen Datenspeicher und den darauf zugreifenden

Prozessen

• “Wenn sich die Prozesse an gewisse Regeln halten, arbeitet der Datenspeicher korrekt.“

• Erwartung: Prozess, der ein Read ausführt, erwartet den Wert des letzten Write

• Was ist das letzte Write in Abwesenheit einer globalen Uhr?

• Lösung: verschiedene Konsistenzmodelle (nicht nur strikt)

9

Konsistenzmodelle

‣ Datenzentrierte Konsistenzmodelle:

• Sicht des Datenspeichers, geeignet für parallele Schreibzugriffe

‣ Client-zentrierte Konsistenzmodelle:

• Sicht des Client, weniger starke Annahmen, insbesondere keine gleichzeitigen Updates

10

Datenzentrierte Konsistenzmodelle

11

Pn: R(x)a Prozess Pn liest die Variable x, erhält a

Pn: W(x)b Prozess Pn überschreibt x mit b

Notation

Strikte Konsistenz

‣ Konsequentestes Konsistenzmodell

‣ Notwendig dazu: absolute globale Zeit

‣ Praktisch unmöglich in einem verteilten System, daher nicht implementierbar

‣ Beispiel:

12

korrekt inkorrekt

Strikte Konsistenz: Jedes Read liefert als Ergebnis den Wert der letzten Write-Operation.

Sequentielle Konsistenz

‣ Schwächeres Modell, dafür implementierbar

‣ Zeit spielt keine Rolle

‣ Beispiel:

13

korrekt inkorrekt

Sequentielle Konsistenz: Wenn mehrere nebenläufige Prozesse auf Daten zugreifen, dann ist jede gültige Kombination von Read- und Write-Operationen akzeptabel, solange alle Prozesse dieselbe Folge sehen.

Sequentielle Konsistenz‣ Beispiel:

14

‣ 6 Anweisungen → 90 gültig Ausführungsreihenfolgen unter Einhaltung der lokalen Reihenfolgen (Zuweisung vor print)

‣ 4 davon siehe hier:

Sequentielle Konsistenz

15

‣ Prints: Folge der tatsächlichen print-Ausgaben

‣ Signature: print-Ausgaben in der Reihenfolge P1,P2, P3

‣ Ausführreihenfolgen werden über Signatur charkterisiert

Sequentielle Konsistenz

16

‣ nicht alle 64 möglichen Signaturen sind erlaubt, z.B.:

• 000000 (print-Anweisungen vor Zuweisungen)

• 001001 (warum?)

‣ 90 gültige Folgen führen zu weniger als 64 unterschiedlichen gültigen Signaturen

‣ Anwendung muss alle gültigen Signaturen als richtige Antworten akzeptieren, anderenfalls ist Sequentielle-Konsistenz-Vertrag nicht eingehalten.

Kausale Konsistenz

‣ Schwächer als sequentielle Konsistenz

‣ Vergleichbar mit Lamports „happened-before“-Relation

‣ Beispiel: kausal, aber weder strikt noch sequentiell konsistent (kein kausaler Zusammenhang zwischen P1: W(x)c und P2: W(x)b)

17

Kausale Konsistenz: Write-Operationen, die potentiell in einem kausalen Verhältnis stehen, müssen bei allen Prozessen in derselben Reihenfolge gesehen werden. Für nicht in dieser Beziehung stehende Operationen ist die Reihenfolge auf unterschiedlichen Rechnern gleichgültig.

Kausale Konsistenz: Beispiele

18

korrektinkorrekt

Client-zentrierte Konsistenzmodelle

19

Anwendungsgebiet

20

‣ Verteilter Datenspeicher, der nur von wenigen Prozessen geschrieben, aber von vielen gelesen wird→ keine Schreib/Schreib-Konflikte→ nur Lese/Schreib-Konflikte

‣ Beispiele:• verteilte Datenbank stabiler Daten

• DNS

• World Wide Web

‣ Häufig Einsatz von Lese-Replikas (Caches)

Eventual Consistency: Wenn lange Zeit kein Update durchgeführt wird, werden alle Replikas (Caches) nach und nach konsistent.

Problem bei Eventual Consistency

‣ Problem kann auftreten, wenn Client die Replika wechselt.

‣ Szenarien:

• mobiler Client macht Update auf einer Replika, wechselt Ort, liest veraltete Daten von anderer Replika.

• mobiler Client liest neuere Version von einer Replika, wechselt Ort, liest ältere Version von anderer Replika.

‣ Benutzer stellt Inkonsistenz fest!

‣ Lösung: client-zentrierte Modelle, bei denen für jeden Client Konsistenz garantiert wird, jedoch nicht für nebenläufigen Zugriff durch mehrere Clients.

21

Illustration des Problems

22

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

Notation

23

xi aktueller Wert der Variablen x in lokaler Kopie Li

WS(xi) Schreiboperationen auf x in Li

R(xi) Lesen des aktuellen Werts von x von Li

Monotones Lesen

‣ Szenario: Lesen von verteilter Email-Datenbank • Benutzer-Mailbox über mehrere Rechner repliziert• neue Mail wird in irgendeine Kopie eingestellt und nach

und nach repliziert• Jede Email, die Benutzer gesehen hat, wird er in

anderem Replikat auch wieder sehen.

24

Konsistenz für monotones Lesen: Wenn ein Prozess den Wert einer Variable x liest, dann wird jede weitere Read-Operation desselben Prozesses denselben oder einen neueren Wert von x liefern.

Monotones Lesen

‣ Beispiel:

25

inkorrekt, da WS(x1) in L2 nicht wiederholt wird

korrekt, da WS(x1) in L2 wiederholt wird

Monotones Schreiben

‣ Beachte: Die obige Anforderung gilt über verschiedene lokale Kopien hinweg. ‣ Szenario: Aktualisierung einer Software-Bibliothek

durch neue Funktionen• Hinzufügen einer Funktion f in einer Replika• Bevor weitere Funktion g in andere Replika hinzugefügt

wird, wird zuerst f eingefügt.

26

Konsistenz für monotones Schreiben: Eine Schreiboperation eines Prozesses in eine Variable x wird abgeschlossen, bevor derselbe Prozesses X erneut schreiben kann.

Monotones Schreiben

‣ Beispiel:

27

inkorrekt, da WS(x1) in L2 nicht wiederholt wird

korrekt, da WS(x1) in L2 wiederholt wird

Read-Your-Writes-Konsistenz

‣ Typische Effekte ohne R-Y-W-Konsistenz:• Webseite im Texteditor aktualisiert, Browser zeigt

veraltete Version an.• Passwort für Online-Shop o.ä. geändert, Zugang erst

nach gewisser Zeit möglich

28

Read-Your-Writes-Konsistenz: Das Ergebnis einer Schreiboperation von x wird für eine anschließende Leseoperation von x desselben Prozesses stets sichtbar sein.

Read-Your-Writes-Konsistenz

‣ Beispiel:

29

inkorrekt, da WS(x1) in L2 nicht wiederholt wird

korrekt, da WS(x1) in L2 wiederholt wird

Writes-Follow-Reads-Konsistenz

‣ Szenario:• Benutzer liest News-Posting A, reagiert mit Kommentar

B, das auf einer lokalen Kopie gespeichert wird.• B wird auf anderen Kopien erst gespeichert, nachdem

Schreiboperation von A - die das Lesen von A erst ermöglicht hat - nachgezogen wurde.

30

Writes-Follow-Reads-Konsistenz: Eine Schreiboperation eines Prozesses von x, die auf eine Leseoperation von x desselben Prozesses folgt, findet auf demselben oder einem aktuelleren Wert von x statt.

Writes-Follow-Reads-Konsistenz

31

‣ Beispiel:

inkorrekt, da WS(x1) in L2 nicht wiederholt wird

korrekt, da WS(x1) in L2 wiederholt wird