Verteilte Systeme Kapitel 8: Replikation und Konsistenz

Transkript

1 Verteilte Systeme Kapitel 8: Replikation und Konsistenz Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck

2 Inhaltsüberblick der Vorlesung 1. Einführung und Motivation 2. Protokolle und Schichtenmodelle 3. Nachrichtenrepräsentation 4. Realisierung von Netzwerkdiensten 5. Kommunikationsmechanismen 6. Adressen, Namen und Verzeichnisdienste 7. Synchronisation 8. Replikation und Konsistenz 9. Fehlertoleranz 10.Verteilte Transaktionen 11.Sicherheit 1-2

3 Überblick Ziele der Replikation Replikationsmodelle Datenzentriert Client-zentriert Replikationsverwaltung Konsistenzprotokolle 3

4 Sinn der Replikation Replikation: Halten von Duplikaten von Daten Steigerung der Performanz Verteilung von Replikaten in verschiedene Netzregionen Vervielfachung der Server an einem Ort Beispiel: Browser- oder DNS-Cache Steigerung der Verfügbarkeit Services laufen weiter obwohl Server ausgefallen sind Netzwerkpartitionen überbrücken (z.b. mobile User) Steigerung der Fehlertoleranz / Verlässlichkeit Schutz gegen zerstörte/gefälschte Daten durch Mehrheitsentscheid Auflösung von Inkonsistenzen (gleichzeitige Schreibzugriffe) 4

5 Replikation Halten einer oder mehrerer Kopien eines Datums Zugriff auf bestimmtes Datum: Prozesse können auf beliebige Replika zugreifen Idealfall: Erhalten immer das gleiche Ergebnis Wichtig: Konsistenz der Kopien Trivial bei nicht-veränderlichen Daten Veränderliche Daten: Overhead zur Konsistenzhaltung Anwendungen haben unterschiedliche Anforderungen an Striktheit der Konsistenz 5

6 Konsistenz Probleme Viele Kopien Starke geographische Verteilung Häufige Schreibzugriffe Lösungen zur absoluten Konsistenzhaltung in nicht-verteilten Systemen Beeinflussen jedoch die Leistung des Gesamtsystems negativ Dilemma Wunsch nach hoher Skalierbarkeit und guter Performance Die dazu notwendigen Mechanismen verschlechtern die Performance Einzige Lösung: keine strikte Konsistenz 6

7 Anwendungsbeispiel: News Ansicht 1: Ansicht 2: Probleme Nachrichten tauchen in unterschiedlicher Reihenfolge auf Sie kommen überhaupt nicht an Für News ist das evtl. ok, aber für andere Anwendungen? 7

8 System-Modell Daten im System: Sammlung von Objekten Datei, Java-Objekt, etc. Jedes logische Objekt wird durch eine Reihe physischer Objekte realisiert (die Replikate) Müssen nicht zu jeder Zeit absolut identisch sein Sie können es tatsächlich auch nicht sein Replikations-Intelligenz : 2 Varianten In den Objekten selbst platziert Außerhalb realisiert (z.b. in einer Middleware) Anwendungsprogrammierer ist frei von Überlegungen zur Replikation 8

9 Modell eines verteilten Datenspeichers Prozess 1... Prozess n Lokale Kopie Verteilter Datenspeicher 9

10 Konsistenzmodelle Vertrag zwischen Datenspeicher und zugreifenden Prozessen Wenn sich Prozesse an Regeln halten, arbeitet Datenspeicher korrekt Erwartung: Prozess, der ein Read ausführt, erwartet als Ergebnis den Wert des letzten Write Frage: Was ist das letzte Write in Abwesenheit einer globalen Uhr? Lösung: verschiedene Konsistenzmodelle (nicht nur strikt) Daten-zentrierte Konsistenzmodelle Sicht des Datenspeichers, geeignet für parallele Schreibzugriffe Client-zentrierte Konsistenzmodelle Sicht des Client mit weniger starken Annahmen Insbesondere keine gleichzeitigen Updates 10

11 Notation P n : R(x)a P n : W(x)b L n : R(x)a L n : W(x)b L n : WS(x) Prozess P n liest die Variable x und erhält den Wert a Prozess P n überschreibt die Variable x mit dem Wert b Von der lokalen Kopie L n wird aus der Variable x der Wert a ausgelesen Auf der lokalen Kopie L n wird die Variable x mit dem Wert b überschrieben Auf der lokalen Kopie L n wird ein Satz von Schreiboperationen auf x ausgeführt 11

12 Strikte Konsistenz (Daten-zentriert) Konsequentestes Konsistenzmodell Jedes Read liefert Wert der letzten Write-Operation Notwendig: absolute globale Zeit Unmöglich in verteilten Systemen nicht implementierbar Beispiel: Korrekt (Update verzögertok) Inkorrekt (Letztes Write nicht gelesen) P 1 : W(x)a W(x)a P 2 : R(x)a R(X)NIL R(x)a 12

13 Sequentielle Konsistenz Etwas schwächeres Modell, aber implementierbar Es greifen mehrere nebenläufige Prozesse auf Daten zu Jede gültige Kombination von Read- und Write-Operationen ist akzeptabel, solange alle Prozesse dieselbe Folge sehen Zeit spielt keine Rolle Beispiel P 1 : W(x) a Korrekt W(x)a Inkorrekt P 2 : W(x)b W(x)b P 3 : R(x)b R(x)a R(x)b R(x)a P 4 : R(x)b R(x)a R(x)a R(x)b 13

14 Kausale Konsistenz Schwächeres Modell als die sequentielle Konsistenz Vergleichbar mit Lamports happened-before -Relation Regeln 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 Beispiel mit W 2 (x)b und W 1 (x)c kausal unabhängig Kausal konsistent, aber nicht sequentiell oder strikt 14

15 (Nicht)Korrekte Folgen bei kausaler Konsistenz Beispiel (a) W 1 (x)a W 2 (x)b (b potenziell Ergebnis von R(x)a) Regelverstoß in kausal konsistentem Speicher Beispiel (b) Lesevorgang entfernt (keine Kausalität der Schreibvorgänge) Korrekte Sequenz

16 Eventual Consistency (Client-zentriert) Idee Über lange Zeitspannen keine Updates Im Laufe der Zeit werden alle Replikate konsistent sein Typische Anwendungen für dieses Modell DNS Web Caching Vorteil Meist sehr einfach zu implementieren Write-Write-Konflikte treten meist nicht auf 16

17 Problem bei Eventual Consistency Probleme treten auf, wenn Clients die Replika wechseln, auf die sie zugreifen Beispiel Mobiler Benutzer macht Updates, wechselt dann den Ort Updates sind eventuell noch nicht dort angekommen Benutzer stellt inkonsistentes Verhalten fest Lösung Client-zentrierte Modelle bei denen für einen Client die Konsistenz garantiert wird Jedoch nicht für nebenläufigen Zugriff durch mehrere Clients 17

18 Illustration des Problems 18

19 Monotones Lesen (Client-zentriert) Wenn ein Prozess den Wert einer Variable x liest, dann wird jede weitere Read-Operation denselben oder einen neueren Wert von x liefern Beispiel Zugriff auf -Box von versch. Orten (a) korrekt, (b) nicht korrekt 19

20 Monotones Schreiben Oft wichtig, dass Schreiboperationen in der richtigen Reihenfolge an alle Dateispeicher weitergeleitet werden Eine Schreiboperation eines Prozesses auf ein Datenelement x wird abgeschlossen, bevor eine folgende Schreiboperation auf x durch denselben Prozess erfolgen kann Beispiel: (a) korrekt, (b) nicht korrekt Weiterleiten an L 2

21 Platzierung der Replikate Unterscheidung drei verschiedener Arten von Kopien Permanente Replikate Server-initiierte Replikate Client-initiierte Replikate 21

22 Permanente Replikate Grundlegende Menge von Replikaten, die meist beim Design eines Datenspeichers schon angelegt werden Beispiele Replizierte Web-Site (Client merkt nichts von der Replikation) Mirroring (Client sucht bewusst ein Replikat aus) Meist nur sehr wenige Replikate 22

23 Server-initiierte Replikate Kurzfristig initiiert bei hohem Bedarf Meist in der (Netz-)Gegend, in der der Bedarf auftritt Grundlage für Geschäftsmodell von Web Hosting Services Schwierige Entscheidung: wann und wo sollen die Replikate erzeugt werden? Existierende Algorithmen verwenden Namen der gesuchten Dateien, Anzahl und Herkunft der Requests zur Verteilung von Dateien (Web-Seiten) Dieser Ansatz kann permanente Replikas ersetzen, wenn garantiert ist, dass immer mindestens ein Server ein Datum vorrätig hält 23

24 Client-initiierte Replikate Meist als (Client-)Cache bezeichnet Management des Caches bleibt Clients überlassen D.h., der Server kümmert sich nicht um Konsistenzerhaltung Einziger Zweck: Verbesserung der Datenzugriffszeiten Daten werden meist für begrenzte Zeit gespeichert (verhindert permanenten Zugriff auf alte Kopie) Cache meist auf der Client-Maschine platziert, oder zumindest in der Nähe von vielen Clients 24

25 Propagierung von Updates Updates werden generell von einem Client auf einem Replika durchgeführt Diese müssen dann an die anderen Replikas weiter gegeben werden Verschiedene Design-Gesichtspunkte für die entsprechenden Protokolle Was wird zu den anderen Replikaten propagiert? Wird pull oder push eingesetzt? Unicast oder Multicast? 25

26 Was wird propagiert? Spontane Idee Server, dessen Replikat geändert wurde, propagiert neuen Wert an alle anderen Alternativen Sende nur eine Benachrichtigung, dass ein Update vorliegt Invalidation Protocols: benötigen sehr wenig Bandbreite Transferiere die das Update auslösende Operation zu den anderen Servern Benötigt ebenfalls minimale Bandbreite, aber auf den Servern wird mehr Rechenleistung erforderlich 26

27 Pull oder Push? Push Updates werden auf Initiative des Servers, bei dem das Update vorgenommen wurde, verteilt Andere Server schicken keine Requests nach Daten Typisch, wenn ein hoher Grad an Konsistenz erforderlich ist Pull: umgekehrtes Vorgehen Server fragen nach neuen Updates für Daten Oft von Client-Caches verwendet 27

28 Unicast oder Multicast Unicast Sende eine Nachricht mit demselben Inhalt an jeden Replika-Server Passt besser zu Pull, wo immer nur ein Server nach einer neuen Version eines Datums fragt Multicast Sende nur eine Nachricht und überlasse dem Netz die Verteilung Multicast wird meist mit Push-Protokollen verbunden, die Server sind dann als Multicast-Gruppe organisiert Meist wesentlich effizienter, insbesondere in LANs 28

29 Protokolle zur Konsistenzerhaltung Wie lassen sich nun die verschiedenen Konsistenzmodelle implementieren? Benötigt Protokolle zur Abstimmung zwischen verschiedenen Replika- Servern Zwei grundlegende Ansätze für diese Protokolle Primary-based Protocols (Write-Operationen gehen immer an dieselbe Kopie) Replicated-Write Protocols (Write-Operationen gehen an beliebige Kopien) 29

30 Primary-Based Protocols Write-Operationen immer nur an eine Kopie Unterscheidung Kopie bleibt immer am selben entfernten Platz Primärkopie wird zu schreibendem Client verlagert Verwendung unterschiedlicher Algorithmen und Protokolle 30

31 Remote-Write-Protokolle Updates auf einem einzigen entfernten Server Lese-Operationen auf lokalen Kopien Nach Update-Aktualisierung der Kopien, ACK zurück an Primary, der dann den Client informiert Damit bleiben alle Kopien konsistent Problem: Performance, Deshalb wird auch non-blocking Update eingesetzt (aber hier wieder Problem mit Fehlertoleranz) Beste Umsetzung für sequentielle Konsistenz 31

32 Ablauf von Remote Write Client Client Write(x) Write ACK Read(x) Val(x) x Write ACK Write(x) Primary Server x Update ACK Update(x) x 32

33 Local-Write-Protokolle Prozesse, die ein Update ausführen wollen Lokalisieren die Primary Copy Bewegen diese dann an eigenen Platz Gutes Modell auch für mobile Benutzer Hole primary copy Breche Verbindung ab Arbeite Baue später Verbindung wieder auf Keine Updates durch andere Prozesse! 33

34 Ablauf von Local Write Update ACK Client Client Primary Server Request Primary Write(x) Write ACK Read(x) Val(x) x Update(x) Update ACK x Update ACK Update(x) x 34

35 Replicated-Write Protocols Write-Operationen können auf beliebigen Replikaten ausgeführt werden Es muss dann entschieden werden, welches der richtige Wert eines Datums ist Zwei Ansätze Active Replication (eine Operation wird an alle Replikas weiter gegeben) Quorum-based (es wird abgestimmt, die Mehrheit gewinnt) 35

36 Aktive Replikation Jedes Replika besitzt Prozess, der die Updates durchführt Updates werden meist als Operation propagiert Wichtigstes Problem: alle Updates müssen auf allen Replikas in derselben Reihenfolge ausgeführt werden, D.h., es wird Multicast mit totaler Ordnung benötigt Implementiert mittels Lamport-Uhren Skaliert aber nicht gut Alternative: zentraler Prozess, der die Sequentialisierung übernimmt Kombination aus beiden Ansätzen hat sich als brauchbar erwiesen 36

37 Zusammenfassung Replikation ist ein mächtiges Instrument Steigerung von Verfügbarkeit und Performance in VS Großes Problem: Konsistenz Für unterschiedliche Anwendungsanforderungen wurden unterschiedliche Lösungen erarbeitet. Konsistenzmodelle müssen implementiert werden Benötigt: Verteilungs- und Konsistenzprotokolle Wir haben eine Vielzahl von Protokollen kennen gelernt, die für jeweils unterschiedliche Modelle geeignet sind 37