Verteilte Systeme Kapitel 8: Replikation und Konsistenz

Verteilte Systeme Kapitel 8: Replikation und Konsistenz Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-lueb...
Author: Jesko Hermann
13 downloads 1 Views 2MB Size
Verteilte Systeme Kapitel 8: Replikation und Konsistenz Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer

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

Überblick • Ziele der Replikation • Replikationsmodelle – Datenzentriert – Client-zentriert

• Replikationsverwaltung • Konsistenzprotokolle 3

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

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

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

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

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

Modell eines verteilten Datenspeichers

Prozess 1

Lokale Kopie

...

Prozess n

Verteilter Datenspeicher

9

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

Notation Pn: R(x)a

Prozess Pn liest die Variable x und erhält den Wert a

Pn: W(x)b

Prozess Pn überschreibt die Variable x mit dem Wert b

Ln: R(x)a

Von der lokalen Kopie Ln wird aus der Variable x der Wert a ausgelesen

Ln: W(x)b

Auf der lokalen Kopie Ln wird die Variable x mit dem Wert b überschrieben

Ln: WS(x)

Auf der lokalen Kopie Ln wird ein Satz von Schreiboperationen auf x ausgeführt

11

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ögert P1: P2:

ok)

W(x)a

Inkorrekt (Letztes Write nicht gelesen) W(x)a

R(x)a

R(X)NIL

R(x)a 12

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 Korrekt P1: P2: P3: P4:

Inkorrekt

W(x) a

W(x)a W(x)b

W(x)b R(x)b

R(x)a R(x)b R(x)a

R(x)b

R(x)a R(x)a

R(x)b 13

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 W2(x)b und W1(x)c kausal unabhängig Kausal konsistent, aber nicht sequentiell oder strikt

14

(Nicht)Korrekte Folgen bei kausaler Konsistenz • Beispiel (a) W2(x)b (b potenziell Ergebnis von R(x)a) – W1(x)a – Regelverstoß in kausal konsistentem Speicher

• Beispiel (b) – Lesevorgang entfernt (keine Kausalität der Schreibvorgänge) – Korrekte Sequenz

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

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

Illustration des Problems

18

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 Email-Box von versch. Orten – (a) korrekt, (b) nicht korrekt

19

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 L2

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

21

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

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

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

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

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

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

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

Protokolle zur Konsistenzerhaltung • Wie lassen sich nun die verschiedenen Konsistenzmodelle implementieren? • Benötigt – Protokolle zur Abstimmung zwischen verschiedenen ReplikaServern

• 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

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

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

Ablauf von Remote Write Client

Client

Write ACK

Write(x)

Val(x)

Read(x) Primary Server

x

Write ACK Write(x)

x

Update ACK Update(x)

x

32

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

Ablauf von Local Write Client

Update ACK

Write ACK

Write(x)

Primary Server

x

Client

Val(x)

Read(x)

Request Primary

Update(x) Update ACK

x

Update ACK Update(x)

x

34

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

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

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