F Replikation und Konsistenz

1 Motivation
★ Replikation
◆ redundandes Vorhalten von Daten auf verschiedenen Knoten
■ Performanz, Skalierbarkeit
◆ lokaler Zugriff effizienter
◆ Aufteilung der Zugriffe auf viele Knoten
F Replikation und Konsistenz
◆ z.B. Web-Caches
■ Verfügbarkeit
◆ solange ein Knoten zugreifbar, sind Daten verfügbar
◆ z.B. DNS-Server
■ Fehlertoleranz
◆ Maskierung von Knotenausfällen
◆ impliziert Konsistenz der Daten
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
F
1
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
1.1 Probleme
F
4
■ Replizierter Code
◆ Konsistenz der Daten
◆ z.B. Implementierung mathematischer Funktionen
◆ Schreiboperationen wirken nur lokale
◆ problemlos, da unveränderlich
◆ zusätzliche Maßnahmen notwendig
■ Replizierte Daten
▲ Konsistenzsicherung
◆ unveränderliche Daten: problemlos
◆ zusätzliche Operationen
◆ veränderliche Daten: problematisch
◆ zusätzliche Interaktionen
◆ z.B. replizierte Variable für den Firmengewinn
◆ Beeinträchtigung der Performanz
• Schreiboperation nicht atomar für alle Replikate durchführbar
(im Gegensatz zu lokalem nichtrepliziertem Speicher)
▲ Nebenläufigkeit
◆ Konsistenzsicherung durch Nebenläufigkeit erschwert
◆ z.B. mehrere nebenläufige Schreibzugriffe von verschiedenen Knoten auf
mehrere Replikate
Verteilte Betriebssysteme
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
2
1.2 Was wird repliziert?
▲ Redundante Daten
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
F
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
F
3
• nebenläufige Lese- und Schreibzugriffe u.U. inkonsistent, weil
Aktualisierungen verspätet erfolgen
(im Gegensatz zu lokalem nichtrepliziertem Speicher)
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
1.2 Was wird repliziert? (2)
2 Datenzentrierte Konsistenzmodelle
■ Replizierte Objekte
■ Traditioneller Konsistenzbegriff
◆ Objekte kapseln Daten und Operationen (Code)
◆ Zugriff auf gemeinsamen Speicher
◆ Datenzugriff nur über Operationen
◆ Zugriff auf verteilten gemeinsamen Speicher
◆ Replikation veränderlicher Objektdaten problematisch
◆ Zugriff auf verteilte gemeinsame Datenbanken
◆ aber: Operationen sind systemweit einzige Zugriffspunkte
◆ Zugriff auf verteilte gemeinsame Dateien
• leichtere Eingriffsmöglickeiten für Konsistenzmaßnahmen
■ Verallgemeinerung
• Konsistenzmaßnahmen betreffen nur Objektimplementierung nicht
Aufrufer
◆ verteilter Datenspeicher
◆ jeder Prozess/Zugreifer hat lokale Kopie des Datenspeichers
Prozesse
lokale Kopien
Datenspeicher
Kommunikationsnetz
nach Tanenbaum, van Steen
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
F
5
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
F
6
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
2 Datenzentrierte Konsistenzmodelle (2)
2.1 Strenge Konsistenz
■ Konsistenzmodell
■ Vertrag (Strict Consistency)
◆ Vertrag zwischen Prozesse und Datenspeicher
◆ Lesezugriff auf ein Datum liefert den Wert des letzten Schreibzugriffs.
• Zugriffsregeln für Prozesse
■ Natürliche Definition für Monoprozessoren
• Eigenschaften der beim Lesezugriff zurückgegebenen Daten
(z.B. Wert des letzten Schreibzugriffs)
◆ im Verteilten System nicht natürlich
◆ Modell schränkt mögliche Werte beim Lesezugriff ein
▲ Problem
◆ benötigt globalen Zeitbegriff: in der Regel unmöglich
• wenig Einschränkungen: leicht zu nutzendes Modell
– aber meist nur ineffizient implementierbar
◆ Lese-Schreib-Konflikte, Schreib-Schreib-Konflikte zwischen nebenläufigen
Operationen (ähnlich wie bei Transaktionen)
• starke Einschränkungen: schwer zu nutzendes Modell
– aber meist auch effizient implementierbar
• Reihenfolge nicht eindeutig, falls Zeitsynchronisation zu schlecht
• Speicherzugriff in der Regel kürzer als beste Abweichung bei
Synchronisation
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
F
7
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
F
8
2.1 Strenge Konsistenz (2)
2.1 Strenge Konsistenz (3)
■ Beispiel mit strikter Konsistenz
■ Erweiterung der Implementierung von C.2.9
virtueller Adressraum
◆ Implementierung eines verteilten gemeinsamen Speichers nach Abschnitt
C.2.9
• keine Replikation
◆ Einführung von replizierten Speicherseiten
• Lesezugriff holt Seite, löscht sie aber nicht beim Besitzer
• auf beiden Seiten werden Schreibzugriffe gesperrt
– Seite wird read-only eingetragen
– Schreibzugriffe führen zu Unterbrechung
◆ Behandlung von Schreibzugriffen
• Invalidieren aller anderen Replikate
– Knoten müssen Einträge und Seite löschen
0
1
2
3
4
5
6
7
8
Kacheln im
0 Hauptspeicher
0 0
0 1 1
0 2 0
0 3 8
0 4
0 5 3
0
Read-Only
0
Präsenzbit
physikalische
Adresse
SKT
2 1
1 1
0
5 1
0
0
0
0
3 1
3
0
2
5
4
0
0
1
0
1
1
1
1
0
Kacheln im
0 Hauptspeicher
0
0 4
0
1
0
2 5
0
3 2
0
4 7
0 5 6
0
0
• lokale Seite muss schreibbar gemacht werden
logische
Adresse
• Schreibzugriff wird wiederholt
◆ Ergänzung des Read-Only-Bits in der Seitenkacheltabelle
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
F
9
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
2.1 Strenge Konsistenz (4)
2.1 Strenge Konsistenz (5)
■ Ablauf beim Lesen
SKT
0
2 1
1
1 1
2
0
3
5 1
4
0
5
0
6 Lesen (1)
0
7
0
8
3 1
logische
Adresse
F
10
■ Ablauf beim Lesen (fortges.)
Kacheln im
0 Hauptspeicher
0 0
0 1 1
0 2 0
0 3 8
0 4
0 5 3
0
0
SKT
3
0
2
5
4
0
0
1
0
1
1
1
1
0
Kacheln im
0 Hauptspeicher
0
0 4
0
1
0
2 5
0
3 2
1
4 7
0 5 6
0
0
Seite nur
lesbar setzen (3)
virtueller Adressraum
virtueller Adressraum
SKT
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
F
SKT
2 1
1 1
0
5 1
0
0
0
0
3 1
Kacheln im
0 Hauptspeicher
0 0
0 1 1
0 2 0
0 3 8
0 4 5
0 5 3
0
0 eintragen
in Speicher (5)
logische
Adresse
Anfrage (2)
Verteilte Betriebssysteme
0
1
2
3
4
5
6
7
8
11
SKT
3
0
2
5
4
0
0
1
0
1
1
1
1
0
Kacheln im
0 Hauptspeicher
0
0 4
0
1
0
2 5
0
3 2
1
4 7
0 5 6
0
0
Antwort mit Seite (4)
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
F
12
2.1 Strenge Konsistenz (6)
2.1 Strenge Konsistenz (7)
SKT
0
2 1
1
1 1
2
0
3
5 1
4
0
5
4 1
6 Lesen (7)
0
7
0
8
3 1
■ Ablauf beim Schreiben
Kacheln im
0 Hauptspeicher
0 0
0 1 1
0 2 0
0 3 8
1 4 5
0 5 3
0
eintragen
0
in SKT (6)
logische
Adresse
SKT
3
0
2
5
4
0
0
1
0
1
1
1
1
0
Kacheln im
0 Hauptspeicher
0
0 4
0
1
0
2 5
0
3 2
1
4 7
0 5 6
0
0
virtueller Adressraum
virtueller Adressraum
■ Ablauf beim Lesen (fortges.)
logische
Adresse
Replikation
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
SKT
0
2 1
1
1 1
2
0
3
5 1
4
0
5
4 1
6 Schreib. (1) 0
7
0
8
3 1
F
13
Kacheln im
0 Hauptspeicher
0 0
0 1 1
0 2 0
0 3 8
1 4 5
0 5 3
0
0
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
2.1 Strenge Konsistenz (9)
virtueller Adressraum
SKT
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
F
14
3
0
5
4
0
0
1
0
1
0
1
1
0
◆ nur ein Prozess/Knoten/Zugreifer kann zu einem Zeitpunkt schreiben
Kacheln im
0 Hauptspeicher
0
0 4
0
1
0
2
0
3 2
0
4 7
0 5 6
0
0
◆ jedoch: drastisch ineffizient
■ Darstellung der Zugriffe zweier Prozesse
P1
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
W(x)a
P2
R(x)a
P1 schreibt Datum a
mit Wert x
Bestätige (4)
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
5
4
■ Implementierung streng konsistent
Kacheln im
0 Hauptspeicher
0 0
0 1 1
0 2 0
0 3 8
0 4 5
0 5 3
0
0 Seite schreibbar setzen (5)
logische
Adresse
0
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
2.1 Strenge Konsistenz (8)
0
1
2
3
4
5
6
7
8
3
Kacheln im
0 Hauptspeicher
0
0 4
0
1
0
2
0
3 2
0
4 7
0 5 6
0
0
Seite
löschen (3)
Verteilte Betriebssysteme
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
SKT
2 1
1 1
0
5 1
0
4 1
Schreib. (6) 0
0
3 1
0
0
1
0
1
0
1
1
0
Invalidiere (2)
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
■ Ablauf beim Schreiben (fortges.)
SKT
t
P2 liest Wert x
für Datum a
◆ Beispiel zeigt strenge Konsistenz
F
15
Verteilte Betriebssysteme
 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm
Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors.
[2003w-VBS-F-Repl.fm, 2003-12-02 22.21]
F
16