Verteilte Systeme. Replikation & Konsistenz I. Prof. Dr. Oliver Haase

Transkript

1 Verteilte Systeme Replikation & Konsistenz I Prof. Dr. Oliver Haase 1

2 Überblick Replikation & Konsistenz I Ziele von Replikation Replikationsmodelle datenzentriert Client-zentriert Replikation & Konsistenz II Replikationsverwaltung Konsistenzprotokolle 2

3 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

4 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

5 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

6 Anwendungsbeispiel: News-Bulletin Ansicht 1: Ansicht 2: Problem: Nachrichten tauchen in unterschiedlicher Reihenfolge auf fehlen Mag für diese Anwendung ok sein, aber andere? 6

7 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

8 Modell eines verteilten Datenspeichers aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen] 8

9 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

10 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

11 Datenzentrierte Konsistenzmodelle Notation Pn: R(x)a Pn: W(x)b Prozess Pn liest die Variable x, erhält a Prozess Pn überschreibt x mit b 11

12 Strikte Konsistenz Strikte Konsistenz: Jedes Read liefert als Ergebnis den Wert der letzten Write-Operation. Konsequentestes Konsistenzmodell Notwendig dazu: absolute globale Zeit Praktisch unmöglich in einem verteilten System, daher nicht implementierbar Beispiel: korrekt inkorrekt 12

13 Sequentielle Konsistenz 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. Schwächeres Modell, dafür implementierbar Zeit spielt keine Rolle Beispiel: korrekt inkorrekt 13

14 Sequentielle Konsistenz Beispiel: 6 Anweisungen 90 gültig Ausführungsreihenfolgen unter Einhaltung der lokalen Reihenfolgen (Zuweisung vor print) 4 davon siehe hier: 14

15 Sequentielle Konsistenz Prints: Folge der tatsächlichen print-ausgaben Signature: print-ausgaben in der Reihenfolge P1,P2, P3 Ausführreihenfolgen werden über Signatur charkterisiert 15

16 Sequentielle Konsistenz nicht alle 64 möglichen Signaturen sind erlaubt, z.b.: (print-anweisungen vor Zuweisungen) (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. 16

17 Kausale Konsistenz 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. 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

18 Kausale Konsistenz: Beispiele inkorrekt korrekt 18

19 Client-zentrierte Konsistenzmodelle 19

20 Anwendungsgebiet 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. 20

21 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

22 Illustration des Problems aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen] 22

23 Notation xi WS(xi) R(xi) aktueller Wert der Variablen x in lokaler Kopie Li Schreiboperationen auf x in Li Lesen des aktuellen Werts von x von Li 23

24 Monotones Lesen 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. Szenario: Lesen von verteilter -Datenbank Benutzer-Mailbox über mehrere Rechner repliziert neue Mail wird in irgendeine Kopie eingestellt und nach und nach repliziert Jede , die Benutzer gesehen hat, wird er in anderem Replikat auch wieder sehen. 24

25 Monotones Lesen Beispiel: korrekt, da WS(x1) in L2 wiederholt wird inkorrekt, da WS(x1) in L2 nicht wiederholt wird 25

26 Monotones Schreiben Konsistenz für monotones Schreiben: Eine Schreiboperation eines Prozesses in eine Variable x wird abgeschlossen, bevor derselbe Prozesses X erneut schreiben kann. 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

27 Monotones Schreiben Beispiel: korrekt, da WS(x1) in L2 wiederholt wird inkorrekt, da WS(x1) in L2 nicht wiederholt wird 27

28 Read-Your-Writes-Konsistenz Read-Your-Writes-Konsistenz: Das Ergebnis einer Schreiboperation von x wird für eine anschließende Leseoperation von x desselben Prozesses stets sichtbar sein. 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

29 Read-Your-Writes-Konsistenz Beispiel: korrekt, da WS(x1) in L2 wiederholt wird inkorrekt, da WS(x1) in L2 nicht wiederholt wird 29

30 Writes-Follow-Reads-Konsistenz 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. 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

31 Writes-Follow-Reads-Konsistenz Beispiel: korrekt, da WS(x1) in L2 wiederholt wird inkorrekt, da WS(x1) in L2 nicht wiederholt wird 31