replikation & konsistenz iihaase/lehre/versy/slides/v8... · ansatz von radoslavov et al....
TRANSCRIPT
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