138 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6. Replikation und Konsistenz 6.1 Motivation Replikation: redundantes Vorhalten von Daten auf verschied. Knoten. - Code: unproblemantisch, da i.d.r. unveränderlich, - Daten: o für Daten, die nur gelesen werden einfach, o veränderliche Daten evt. nicht konsistent (z.b. Aktualisierungen erfolgen verspätet). Vorteil - Performanz & Skalierbarkeit: - lokaler Zugriff schneller, - Aufteilung der Zugriffe auf viele Knoten, - z.b. Web-Caches, Distributed Shared Memory,... Vorteil - Fehlertoleranz: - Redundanz erlaubt Maskierung von Knotenausfällen, - solange ein Knoten zugreifbar, sind Daten verfügbar, - impliziert aber Konsistenz der Daten. Herausfoderungen: - Konsistenzsicherung erfordert zusätzliche Operationen & Interaktion (Performanz), - Nebenläufigkeit erschwert die Konsistenzsicherung (mehrere nebenläufige Schreibzugriffe von verschiedenen Knoten auf mehrere Replikate). 138 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.2 Verteilte nebenläufige Zugriffe 6.2.1 Lesen & Schreiben im Netz Problem ist die hohe Verzögerung/Latenz von Zugriffen über das Netz verglichen mit lokalen Operationen. Je nachdem ist es günstiger die Operation zu den Daten zu senden oder die Daten herzuholen. Matrixdarstellung: Ortsfeste Daten, R/W-Operation transportieren Migrierende Daten, lokale Operation ohne Replikation Verzögerung für alle, außer für Eigentümer langsam lesen, langsam schreiben, (evt. Seitenflattern) mit Replikation sofort lesen, überall schreiben, "write update" aus Cache lesen, Original schreiben, "write invalidate" Nach einem "write invalidate" müssen die Seiten von den interessierten Lesern erneut angefordert werden. 139 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.2.2 Nebenläufige Ausführung Sequentielles Programm A: - ergibt 30 als Resultat in der Variablen "c" a:= 0; b:= 0; a:= 10; b:= 20; c:= a+ b; Statements Unsynchronisierte Parallelisierung für drei Prozessoren: - verschiedene Resultate möglich für c, - 120 mögliche Permutationen (5*4*3*2), - zum Beispiel für drei Prozessoren sei c = { 0, 10, 20, 30... }: CPU #1 CPU #2 CPU #3 a:=0; b:=0; a:=10; b:=20; c:=a+b; Einfacher Stackcode push(0); write(a) push(0); write (b) push(10); write (a) push(20); write (b) add(a,b); write (c) 140 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

Inkorrekte Ausführungssequenzen: Durch Verzögerung von Nachrichten im Netz und durch präemptive Prozessumschaltungen wird die Reihenfolge der Lese- und Schreiboperationen unbestimmt. Zum Beispiel ist das Resultat entweder 0 oder auch 10: c = 0: CPU #1 CPU #2 CPU #3 a:=10; a:=0; b:=20; b:=0; c:=a+b; c = 10: CPU #1 CPU #2 CPU #3 a:=0; b:=0; a:=10; c:=a+b; b:=20; 141 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

Sequenzen mit korrektem Resultat: Pro Variable muss der Zugriff in der richtigen Reihenfolge garantiert werden (mit Locks oder sonst irgendwie). 30: CPU #1 CPU #2 CPU #3 a:=0; a:=10; b:=0; b:=20; c:=a+b; Kausaler Zusammenhang zwischen: "a:=0;" und "a:=10;" "b:=0;" und "b:=20;" "a:=10;" und "c:=a+b;" "b:=20;" und "c:=a+b;" Natürlich ist a:=0 und b:=0 überflüssig. NB: Signale, Locks und Anfragen über das Netz brauchen Zeit. 142 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

Datenflussanalyse/-graph hierzu: Die Abhängigkeiten zwischen Instruktionen können in einem Datenflussgraphen festgehalten werden. Berücksichtigen der Happens before Relation. Operationen ohne Abhängigkeit können nebenläufig stattfinden. a:= 0; b:=0; a:=10; b:=20; c=a+b; 143 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

Relaxierung: Das nachfolgende Beispiel vertauscht die Reihenfolge von Instruktionen. Es liefert trotzdem ein korrektes Resultat, da der Datenflussgraph berücksichtigt wird. 30: CPU #1 CPU #2 CPU #3 b:=0; b:=20; a:=0; a:=10; c:=a+b; Für kausal nicht zusammenhängende Operationen kann die Reihenfolge auch innerhalb einer CPU vertauscht werden. Dies wird auch durch parallelisierende Compiler ausgenutzt. 144 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.3 Daten-zentrierte Konsistenzmodelle Traditioneller Konsistenzbegriff f. Zugriffe auf gemeinsamen Speicher: - Verteilter Virtueller Speicher (VVS), - Distributed Shared Memory (DSM), - Idee von Prof. L. Keedy (1986). Konsistenzmodell = Speicherungskontrakt - Speicherungsmechanismus garantiert gegenüber den zugreifenden Prozessen Regeln nach welchen er die Schreiboperationen sichtbar werden lässt, - strenge Modelle: schränken Werte beim Lesezugriff ein o einfach für den Programmierer, o langsamer durch häufige Synchronisierung. - schwache Modelle: wenig Einschränkungen o effizienter zu realisieren, o schwerer für den Programmierer. Konsistenz: Wann sieht ein anderer Knoten die Änderung? Kohärenz: Wie sieht ein anderer Knoten die Änderung? (invalidate oder update). CPU #1 Speicherkontrakt Verteilter read Speicher write cntrl CPU #2 CPU #3 145 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.3.1 Strikte Konsistenz (Strict Consistency) Vertrag: Alle Leseoperationen liefern den global zuletzt geschriebenen Wert - unabhängig davon, welcher Prozess geschrieben hat. - Problem: in einem Netz gibt es keine globale Zeit mehr. Der Begriff "zuletzt" ist unscharf. - Entspricht Verständnis bei Multiprozessorsystemen mit Caches und Shared Memory. Jeweils atomare Schreib- /Leseops. werden in die Warteschlange unseres Stationen Modells eingefügt. Implementierung: - N Leser oder 1 Schreiber, - dedizierter Homenode verwaltet Sperren, - Schreibsperre invalidiert alle Replikate im Netz, - sehr ineffizient, aber einfach. - Z.B. IVY DSM (erstes Impl.). Read/Write Q Verteilter Speicher 146 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.3.2 Sequentielle Konsistenz Vertrag: Sequential Consistency (Lamport, 1979): - Das Ergebnis einer Ausführung ist dasselbe wie wenn alle Lese- und Schreiboperationen aller Prozesse in einer bestimmten Reihenfolge ausgeführt werden. - Die Operationen eines Prozesses erfolgen dabei in der vom Programm definierten Reihenfolge. Alle Prozesse sehen alle Schreiboperationen in gleicher Reihenfolge: - im Gegensatz zur strikten Konsistenz, bleibt offen, wann eine Änderung sichtbar wird. - evt. werden zuerst neue und dann alte Werte gelesen. Die Warteschlangen werden in unbestimmter Reihenfolge bedient. Read/ Write Q Stationen Verteilter Speicher 147 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

Beispiel: - nicht strikt konsistent (P3 & P4 lesen veralteten Wert), - aber sequentiell konsistent (alle sehen Schreibzugriffe in selber Reihenfolge). Beispiel-2: weder strikt noch sequentiell konsistent - P3 und P4 sehen Schreibzugriff von P1 und P2 in verschiedener Reihenfolge. 148 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

Implementierung: - Schreiboperationen müssen bei allen Prozessen in gleicher Reihenfolge sichtbar werden (Zeitdauer ist aber unbedeutend), - N Schreiber nebenläufig zu N Lesern, - Schreiber schicken Änderungen per reliable Multicast, - Zum Senden von Änderungen muss ein zirkulierendes Token angefordert werden. - Bewertung: o Leser können veraltete Werte sehen (im Gegensatz zur strikten Konsistenz), o aber zukünftige Schreibzugriffe können hier ältere nicht überholen. o damit eine etwas strengere Impl. der sequentielle Konsistenz. Beispiele für DSM Systeme mit sequentieller Konsistenz: - SVMlib (Uni Aachen), - Kerrighed (IRISA, Rennes, Frankreich),... 149 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.3.3 Kausale Konsistenz Vertrag: Kausale Konsistenz (Causal Consistency): - Nur kausal voneinander abhängige Schreibzugriffe sind zeitlich geordnet und werden von allen Prozessoren in derselben Reihenfolge gesehen. Unterschied zur sequentiellen Konsistenz: - Forderung nach sequentieller Ausführung bzgl. einer CPU wird aufgegeben, - nicht alle Schreiboperationen müssen von allen in der gleichen Reihenfolge gesehen werden. Beispiel-1: - kausal konsistent, - aber weder strikt noch sequentiell konsistent. P1 W(x)=1 W(x)=3 P2 R(x)=1 W(x)=2 P3 R(x)=1 R(x)=3 R(x)=2 t P4 R(x)=1 R(x)=2 R(x)=3 150 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

Beispiel-2: - kausal inkonsistent, - P3 sieht kausal abhängige Zugriffe W(x)=1 und W(x)=2 in falscher Reihenfolge. W(x)=1 P1 P2 P3 P4 R(x)=1 W(x)=2 R(x)=2 R(x)=1 R(x)=1 R(x)=2 Implementierung: - Es muss beobachtet werden, welche Prozesse welche Schreiboperationen gesehen haben, - Letztlich muss ein Abhängigkeitsgraph erstellt und verwaltet werden. - Komplexität der benötigten Algorithmen ist lokal bereits O(N 2 ). - Alternativ: Vektoruhr pro replizierter Variable o Anhand der Zeitstempel sind kausale Abhängigkeiten erkennbar, o Idee: Aktualisierungen, die kausal vor letztem Update liegen, bleiben unberücksichtigt (somit werden Zwischenwerte evt. nicht gesehen). o aber auch aufwendig Vektoruhr pro Variable. t 151 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.3.4 PRAM Konsistenz (auch Fifo-Konsistenz) Vertrag: - Schreibzugriffe eines einzigen Prozesses sehen alle Prozessoren in der gleichen Reihenfolge. - Schreibzugriffe verschiedener Prozesse können in verschiedener Reihenfolge gesehen werden. Abschwächung der kausalen Konsistenz: - Reihenfolge von kausal abhängigen Zugriffen von zwei Prozessen nicht relevant. Beispiel: - PRAM-konsistent, P1 W(x)=1 - aber weder strikt, P2 R(x)=1 W(x)=2 W(x)=3 sequentiell noch kausal konsistent. R(x)=1 R(x)=2 R(x)=3 P3 P4 R(x)=2 R(x)=1 R(x)=3 t Bem.: Beispiel-2 in 6.3.3 ist ebenfalls PRAM konsistent. Vorteile: - einfache Implementierung, - vollständig nebenläufiges Lesen und Schreiben - verschicken von Nachrichten asynchron (pipelined). 152 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

Implementierung: muss Reihenfolge pro Prozess sicherstellen - replizierte Variablen, - Lese- und Schreibzugriffe auf lokaler Kopie, - Aktualisierungsnachrichten mit Sequenznr. + ProzessID, - Sicherstellen der Reihenfolge der Updates durch Zurückstellen von Nachrichten: Problem: merkwürdiges Verhalten von Anwendungen P1 P2 P3 B=1; WHILE(B==0) ; WHILE(A==0) ; A=1; PRINT(B); - bei strikter & seq. Konsistenz: Ausgabe 1 - bei FIFO-Konsistenz: Ausgabe 0 oder 1. 153 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.3.5 Schwache Konsistenz Idee: Zusammenfassung von Operationen - explizite globale Synchronisierung aller lokalen Kopien, - Prozess riskiert, veraltete Daten in seinem Speicher zu finden, wenn er nicht explizit zuvor seinen Speicher synchronisiert. Vertrag: Weak Consistency - Aufrufe von sync() sind sequentiell konsistent (sehen alle in gleicher Reihenfolge), - Vor sync() werden alle vorherigen Schreibops. abgeschlossen (Update aller Replikate global). - Mit Aufruf von sync() werden alle späteren Lese- und Schreiboperationen verzögert bis alle sync()-aufrufe abgeschlossen sind (nach sync()-aufruf werden sicher aktuelle Werte gelesen). Beispiel: P1 W(x)=1 W(x)=2 sync P2 P3 R(x)=1 sync R(x)=1 R(x)=2 R(x)=2 sync t 154 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.3.6 Release-Konsistenz Problem bei schwacher Konsistenz: - Bei Aufruf von sync() ist unklar, ob Prozess das Schreiben abschliesst, oder Lesen beginnt. - Deshalb muss Speicher immer lokale Schreibzugriffe global sichtbar machen und entfernte Schreibzugriffe einsammeln. blocked Lösung: Release Consistency acquire - "acquire(v)" versucht Eintritt in kritische Region (Schreib-Leseblock) Blockierung bis alle lokalen Replikate aktualisiert. - "release(v)" verlässt die kritische Region propagate Update aller Replikate, global. Beispiel: release P1 P2 P3 acq(l) W(x)=1 W(x)=2 rel(l) R(x)=1 acq(l) R(x)=2 rel(l) Lazy Release: propagiert Änderungen erst wenn der nächste Prozess Zugang zur kritischen Region wünscht (z.b. Treadmarks). t 155 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.3.7 Entry-Konsistenz Vertrag: Semantik & Operationen wie bei Lazy Release Consistency. Aber keine globale Synchronisierung, sondern auf Objektebene. - Ziel feingranularere Synchronisierung, - Variablen erst bei acquire updaten, - Zugriffsrechte separat auf gemeinsame Variablen Schwierigeres Programmiermodell. Beispiel: Midway (Carnegie Mellon University). acquire(a) blocked propagate(a) propagate(b) acquire(b) release(a) release(b) 156 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.3.8 Transaktionale Konsistenz Ausschließlich rücksetzbare Transaktionen greifen auf den DSM zu. - Menge von Schreib- & Leseoperationen, - Schreibzugriff nur auf Schattenkopien, - ACId-Eigenschaften. sequentiell konsistent Spekulative Ausführung: T1 W(x)=1 Zeit - Lese- und Schreibzugriffe sind spekulativ, - Transaktion muss zurückgesetzt werden, falls Konflikt auftritt (Serialisierung), T2 R(x)=0 R(x)=1 - Konflikte werden durch Vergleich der Read- & Write-Sets erkannt. Transaktionale Konsistenz: - sequentielle Konsistenz immer gegeben. Serialisierung strikt konsistent - strikte Konsistenz zu Commit-Zeitpunkten. Am Ende einer Transaktion wird gesamter Speicher synchronisiert. T1 T2 W(x)=1 Zeit R(x)=1 R(x)=1 Beispiele: Plurix (Ulm), TCC (Stanford, HW-DSM), THOR (MIT, Persistent Object System), 157 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.4 Client-zentrierte Konsistenzmodelle Bisher Konsistenz globaler Daten. Nun noch schwächere Konsistenzmodelle aus der Sicht eines Klienten. Modelle garantieren Ordnung von Operationen eines einzelnen Klienten. Viele Anwendungen genügt seltene und zentrale Aktualisierung: - Namensdienst (DNS), - Webseiten,... 6.4.1 Eventuelle Konsistenz Vertrag: Daten werden letztendlich konsistent. Beispiel: geänderte Webseite wird nach gewisser Zeit veraltete Version in lokalen Browsercaches ersetzen Implementierung: - Push-Modell: nach Time-Out/periodisch werden Daten an alle Replikate gesandt (z.b. Zonenaktualisierung in DNS). - Pull-Modell: nach Time-Out/periodisch holen Replikate neueste Daten (z.b. Web-Cache). 158 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.4.2 Monotones Lesen Vertrag: Falls ein Prozess einen Wert a aus Datum x gelesen hat, dann wird er zukünftig weiterhin a oder einen neueren Wert lesen. Unterschied zur Fifo-Konsistenz: - bei Fifo-Konsistenz kann ein Prozess auch zwischendurch einen alten Wert sehen, - bei monotonem Lesen jedoch nicht (Fall X nicht zulässig). P1 P2 P3 P4 W(x)=1 R(x)=1 W(x)=2 W(x)=3 R(x)=1 R(x)=2 R(x)=2 R(x)=1 R(x)=3 R(x)=3 Anwendungsbeispiel: replizierte Mailbox - Klient liest von verschiedenen Replikaten Mails, - bereits gelesene Mails sollen nicht mehr als neu angezeigt werden. Implementierungsidee: - ReadSet pro Klient verwalten, - damit für Server erkennbar, was bereits gelesen wurde. t 159 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.4.3 Monotones Schreiben Vertrag: Schreiboperation eines Prozesses setzt sich durch bevor nächste Schreiboperation dieses Prozesses ausgeführt wird. Ziel: verhindern falscher Aktualisierungsreihenfolgen in den Replikaten. Impliziert FIFO-Konsistenz: - Prozesse sehen Schreibzugriffe in der Reihenfolge des schreibenden Prozesses, - hier aber bezogen auf einen einzelnen Klienten, andere (ohne oder anderer Konsistenz) sehen Schreibzugriffe evt. in anderer Reihenfolge. Implementierung: - Sequenznummern für Aktualisierungen verwenden, - Replikat merkt sich letzte Nummer bei Aktualisierung, - Aktualisierungen mit zu hoher Sequenznummer werden verzögert. 160 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6.5 Zusammenfassung Replikation: - Vorteile: Performanz, Skalierbarkeit, Fehlertoleranz, - Herausforderung: Konsistenz bei Schreibzugriffen. Konsistenzmodell: Vertrag zw. Speicher & Prozessen der festlegt wann Schreiboperationen sichtbar werden. Strenge Konsistenzmodelle: - komfortabel, aber langsamer (häufige Syncronisierung), - Synchronisierung erfolgt automatisch nach definierten Regeln. Schwache Konsistenzmodelle: - effizienter, aber schwieriger zu verwenden, - Programmierer muss explizite Synchronisierungsbefehle verwenden. 161 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner