Prof. Dr. Oliver Haase

Verteilte SystemeReplikation & Konsistenz II

1

Überblick

2

Replikation & Konsistenz I

‣ Ziele von Replikation

‣ Replikationsmodelle

• datenzentriert

• Client-zentriert

Replikation & Konsistenz II

‣ Replikationsverwaltung

‣ Konsistenzprotokolle

Replikationsverwaltung

3

Platzierung der Replikatserver

4

‣Optimierungsproblem: Finde K beste von N möglichen Standorten.

‣ es existieren Lösungsansätze z.B. von • Qiu et al. (2001)

• Radoslavov et al. (2001)

• Szymaniak et al. (2006)

Ansatz von Qiu et al.‣ berücksichtigt Client-Standorte

‣ bestimmt Entfernung von Clients zu Standorten (z.B. in Latenzzeit oder Bandbreite)

‣ platziert nach und nach einen Server auf denjenigen verbliebenen Standort, der im Durchschnitt allen Clients am nächsten ist

‣ Aufwand: O(N2) → Laufzeit für wenige 1000 Standorte Dutzende Minuten

‣ ungeeignet für Serverplatzierung im Fall von Flash Crowds, d.h. plötzliche gehäufte Anfragen nach bestimmten Webseiten

5

Ansatz von Radoslavov et al.‣ ignoriert Client-Standorte

‣ berücksichtigt stattdessen Topologie des Internets

‣ Internet besteht aus sog. Autonomen Systemen (AS), d.h. Netze, die • dasselbe Routing-Protokoll verwenden

• von einer Organisation verwaltet werden.

‣ platziert 1. Server in größtem AS, auf Router mit den meisten Verknüpfungen, 2. Server in zweitgrößtem AS, ...

‣ genauso gut wie Qiu et al. für gleichmäßig verteilte Clients

‣ Aufwand: ebenfalls O(N2), ebenfalls ungeeignet für schnelle Platzierungsberechnung

6

Ansatz von Szymaniak et al.‣ berücksichtigt Client-Standorte

‣ teilt Netz in Zellen auf

‣ sucht Client-Cluster, d.h. Zellen mit vielen Clients

‣ platziert Replikatserver in K größten Clustern

‣Qualität hängt von Zellengröße bei Clustersuche ab:

7

‣ ideale Zellengröße lässt sich aus durchschn. Entfernung zwischen zwei Knoten und K berechnen.

Ansatz von Szymaniak et al.

‣ arbeitet bei idealer Zellengröße annähernd so gut wie Qiu et al.

‣ Aufwand: O(N x max(log(N), k))

‣ konkretes Beispiel: N = 64000, K = 20 ⇒ 50000 Mal schneller als Qiu et al.

‣ geeignet für schnelle Platzierung bei Flash Crowds

8

Platzierung der ReplikateEs gibt 3 verschiedene Arten von Kopien:

‣ Permanente Replikate

‣ Server-initiierte Replikate

‣ Client-initiierte Replikate

9

Permanente Replikate

‣ Grundlegende Menge von Replikaten, die meist beim Design eines Datenspeichers schon angelegt werden

‣ Varianten:• transparent repliziert (Client merkt nichts von der

Replikation),

• Mirroring (Client sucht bewusst ein Replikat aus)

‣Oft geringe Anzahl

10

Server-initiierte Replikate

‣ Kurzfristig initiiert bei hohem Bedarf, meist in der Netzregion, in der der Bedarf auftritt

‣ Schwierige Entscheidung: Wann und wo sollen die Replikate erzeugt werden?

‣ Existierende Algorithmen verwenden dazu:• Namen der gesuchten Dateien,

• Anzahl und Herkunft der Requests

‣ Kann permanente Replikas ersetzen, wenn garantiert ist, dass jedes Datum immer von mindestens einem Server vorrätig gehalten wird.

11

Client-Initiierte Replikate‣ Meist als (Client-)Cache bezeichnet

‣ Management des Caches bleibt dem Client überlassen, d.h. 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 wird meist auf der Client-Maschine platziert, oder in der Nähe vieler Clients (z.B. in LAN).

12

Propagieren von Updates

‣ Client führt Update generell auf einer Replika durch.

‣ Dieses Update muss an alle anderen Replikas weitergegeben werden.

‣ Verschiedene Design-Gesichtspunkte für die entsprechenden Protokolle:• Was wird zu den anderen Replikaten propagiert?

• Wird pull, push oder leases eingesetzt?

• Unicast oder Multicast?

13

Was wird propagiert?‣ Derjenige Server, dessen Replikat geändert wurde, schickt

neuen Wert an alle anderen, oder?

‣ Nicht unbedingt → Alternativen:• Sende nur Benachrichtigung, dass Update vorliegt

- wird von Invalidation Protocols verwendet,

- sehr wenig Bandbreite

- gut, wenn viele Schreib- vs. wenig Leseoperationen

• Transferiere die Änderungsoperation zu den anderen Servern- geringe Bandbreite

- erfordert mehr Rechenleistung auf den Servern

14

Push, Pull oder Leases?‣ Terminologie für diese Betrachtung

• Server: Server, auf dem Änderung vorgenommen wurde

• Client: Server, der weiteres Replikat beherbergt, oder Client

‣ Push (Server-basiert):• Updates werden auf Initiative des Servers verteilt

• Clients schicken keine Requests nach Daten

• Server muss Liste aller Clientcaches für jedes Datum aktuell halten

• Gut, wenn

- hoher Grad an Konsistenz erforderlich oder

- viele Lese- vs. wenig Schreiboperationen15

Push, Pull oder Leases?

‣ Pull (Client-basiert):• Server bzw. Clients fragen nach neuen Updates für Daten

• oft von Client Caches verwendet

• gut bei wenig Lese- vs. viele Schreiboperationen oder wenn geringe Kohärenz erforderlich

• längere Antwortzeiten bei Cache Miss

16

Push, Pull oder Leases?‣ Leases

• Hybrid aus Push und Pull

• Lease hat bestimmte Laufzeit

• während Laufzeit überträgt Server Änderungen per Push

• danach muss Client Änderungen per Pull selbst abholen

• Client kann neuen Lease beantragen

• erlaubt dynamischen Umschalten zwischen Pull und Push

• drei Kriterien für Lease-Laufzeit:1. Änderungshäufigkeit: Änderung selten → langes Lease

2. Nachfragehäufigkeit: Client fragt oft nach → langes Lease

3. Serverlast: Serverlast gering → lange Leases

17

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 einzige Nachricht und überlasse dem Netz die Verteilung • effizienter (Multicast-Implementierung vorausgesetzt)

• wird meist mit Push-Protokollen verbunden, die Server sind dann als Multicast-Gruppe organisiert

18

Protokolle zur Konsistenzerhaltung

19

Arten von Konsistenzprotokollen

20

‣Wie lassen sich nun die verschiedenen Konsistenzmodelle implementieren?

‣ Dazu benötigt man Protokolle, mit deren Hilfe sich die verschiedenen Replika-Server abstimmen.

‣ Aufteilung wiederum in• datenzentrierten Konsistenzprotokolle und

• Client-zentrierten Konsistenzprotokolle

Datenzentrierte Konsistenzprotokolle

Zwei grundlegende Ansätze für diese Protokolle:

‣ Urbildbasierte Protokolle (Primary-based Protocols)

• Write-Operationen gehen immer an dieselbe Kopie

• auch: Urbildsicherungsprotokolle (Primary Backup Protocols)

‣ Protokolle für replizierte Schreibvorgänge (Replicated-Write Protocols)

• Write-Operationen gehen an beliebige Kopien

21

Urbildbasierte Protokolle

‣Wenn alle Write-Operationen immer nur an eine Kopie gehen, kann man unterscheiden, ob die Primärkopie

• immer am selben entfernten Platz bleibt→ Remote-Write-Protokolle

• zu dem schreibenden Client verlagert wird→ Local-Write-Protokolle

22

Remote-Write-Protokolle

‣ alle Updates auf einem entfernten Urbildserver

‣ Lese-Operationen auf lokalen Kopien

‣Wenn Client Datum x ändern möchte:

• lokaler Server S leitet Änderung an Urbildserver U weiter

• U macht Änderung, informiert alle Kopien

• Jede Kopie macht Änderung, sendet ACK an U

• Nachdem alle ACKs eingetroffen: U sendet ACK an S

23

Remote-Write-Protokolle

24

Datenspeicher

R1 R2

ClientClient

Urbildserver für Datum X

W1 W6

W2 W3

W4W5

W1 - SchreibanforderungW2 - Weiterleitung SchreibanforderungW3 - AktualisierungsanforderungW4 - ACKW5 - ACKW6 - ACK

R1 - LeseanforderungR2 - Ergebnis des Lesens

Remote-Write-Protokolle

‣ Problem: Performance, deshalb wird auch non-blocking Update eingesetzt (aber hier wieder Problem mit Fehlertoleranz)

‣ Beste Umsetzung für sequentielle Konsistenz

25

Local-Write-Protokolle‣ Jeder Prozess, der ein Update ausführen will, lokalisiert das

Urbild und bewegt dieses an seinen eigenen Platz.

‣ Gutes Modell auch für mobile Benutzer:• hole Urbild ab

• breche Verbindung ab

• arbeite

• baue später Verbindung wieder auf

• keine zwischenzeitliche Änderungen durch andere Prozesse!

• andere Prozesse können aber weiterhin lesen

26

Local-Write-Protokolle

27

Datenspeicher

R1 R2

ClientClient

alter Urbildserver für Datum X

W1 W4

W2 W5

W6W3

W1 - SchreibanforderungW2 - UrbildanforderungW3 - ACKW4 - ACKW5 - AktualisierungsanforderungW6 - ACK

R1 - LeseanforderungR2 - Ergebnis des Lesens

Replizierte Schreibvorgänge

‣ Bei dieser Art von Protokollen können Write-Operationen auf beliebigen Replikaten ausgeführt werden.

‣ Es muss dann entschieden werden, welches der richtige Wert eines Datums ist.

‣ Zwei Ansätze:

• Aktive Replikation: eine Operation wird an alle Replikas weitergegeben

• Quorum-basiert: es wird abgestimmt, die Mehrheit gewinnt

28

Aktive Replikation

‣ Jede Replika besitzt einen Prozess, der Updates durchführt.

‣ Updates werden meist als Operation propagiert.

‣Wichtigstes Problem: alle Updates müssen auf allen Replikas in derselben Reihenfolge ausgeführt werden→ es wird Multicast mit totaler Ordnung benötigt (kann mittels Lamport-Uhr implementiert werden)

‣ skaliert schlecht

‣ Alternative: zentraler Prozess, der Sequentialisierung übernimmt.

29

Quorum-basierte Protokolle ‣ Grundidee: Clients müssen vor Lese- oder

Schreiboperation Erlaubnis mehrerer Server einholen

‣ Konkret: • Angenommen, es gibt N Replikate des Datum X

• X besitzt Versionsnummer

• Schreibprozess benötigt Schreiberlaubnis von NW Servern

• NW > N/2 → verhindert Schreib/Schreib-Konflikte

• Leseprozess benötigt Leseerlaubnis von NR Servern

• NW + NR > N → garantiert, dass Quorum mindestens eine Kopie der neuesten Version enthält

30

Quorum-basierte Protokolle

31

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

(a) keine Schreib/Schreib-, keine Lese-/Schreib-Konflikte(b) Schreib/Schreib-Konflikte möglich, da NW = N/2(c) Spezialfall: Read-One-Write-All (ROWA)

Client-zentrierte Konsistenzprotokolle

‣ Jedem Schreibvorgang W wird vom Ursprungssserver eine global eindeutige ID zugewiesen;

‣ Pro Client C werden zwei Reihen von Schreibvorgängen überwacht:

1. Lesevorgangsreihe: Schreibvorgänge (aller), die für Lesevorgänge von C relevant sind;

2. Schreibvorgangsreihe: Schreibvorgänge von C

32

Client-zentrierte Konsistenzprotokolle

‣ Konsistenzerhaltungsprotokolle für

• Konsistenz für monotones Lesen

• Konsistenz monotones Schreiben

• Read-Your-Writes-Konsistenz

• Write-Follows-Reads-Konsistenz

laufen nach folgendem Schema ab, wobei

• <OP>: Lese- oder Schreiboperation

• <OP-Reihe>: Lese- oder Schreibvorgangsreihe

33

Client-zentrierte Konsistenzprotokolle

‣ Sobald Client C lokale Operation <OP> auf Server S durchführt, bekommt S Cs <OP-Reihe>;

‣ S prüft, ob alle relevanten Operationen aus <OP-Reihe> lokal durchgeführt wurden;

‣ Falls nein, dann• kontaktiert S die Server, die fehlende Operationen aus <OP-

Reihe> durchgeführt haben, und holt diese nach, oder

• die Operation <OP> wird an einen solchen Server delegiert.

‣ Nach erfolgter Operation <OP> wird diese ggf. in <OP-Reihe> aufgenommen

34

Client-zentrierte Konsistenzprotokolle

35

<OP> <OP-Reihe>

monotones Lesen

monotones Schreiben

Read Your Writes

Write Follows Reads

Lesen Lesevorgangsreihe

Schreiben Schreibvorgangsreihe

Lesen Schreibvorgangsreihe

Schreiben Lesevorgangsreihe