9.4 Konsistenz im Verteilten System

9. Speicherkonsistenz
9.1 Typologie verteilter Systeme (revisit)
9.1.1 Rechnernetze:






Insbesondere Internet.
Kopiersemantik (FTP, HTTP ...).
Dienstfragmente (QoS, Naming, .. ).
kein Betriebssystem (DNS, WOS ... ).
Suboptimale Nutzung (Verbindungen ..).
Wachstum und kreatives Chaos (global).
9.1.2 Verteilte Dateisysteme





Remote Disk vs. remote Files.
Zugriff auf entfernte Volumes.
Zugriff auf nicht-lokale Dateien.
Allgemein montierbare Verzeichnisbäume.
Replikation von Dateien & Verzeichnissen.
9.1.3 Netzwerkbetriebssysteme



-
Übertragen von Daten zwischen Stationen.
Weitgehend autonome Stationen:
eigene Bedienerschnittstellen,
eigene Betriebssystemkopie,
ohne Netz arbeitsfähig.
Substitution einzelner lokaler Dienste:
diskless Workstations,
Remote Login,
LMHOSTS ...


-
Lokalisierbare Dienste im Netz:
drucken und speichern,
Rechner hochfahren,
Namensdienste,
Mail-Server,
Help-Desk.
Beispiele:
Novell Netware,
Windows NT,
Linux ...
9.1.4 Verteilte Betriebssysteme:



-
Explizite Kommunikation:
Datagramm-Nachrichten,
Sockets und Streams,
Entfernte Prozeduraufrufe,
Verteilte Objekte & Methoden ( .net, rmi ),
Corba, Java Spaces (Jini) ...
Implizite Kommunikation:
transparente Prozeduraufrufe,
transparente Variablenzugriffe,
identisches API - lokal & im Netz,
softwaregestützt (Compiler & Run-Time),
oder hardwaregestützt (MMU, Segmente, ... ).
Gemeinsamer verteilter Speicher DSM:
explizite oder implizite Kommunikation,
verteilte gemeinsame Adressräume
verteilte Objekte & Variablen ...

-
Zielsetzung:
skalierbares System,
einfache Programmierung,
lokale und verteilte Programme,
sichere und effiziente Ausführung,
Konsistenzgarantie für die verteilten Daten.
9.2 Kenngrößen & Charakteristika



-
Zugriffstransparenz:
Logische Namen (nicht physische),
Single-System image,
Einheitliches API.
Ortstransparenz:
Dateien und Verzeichnisse,
Terminalzugang,
Rechenleistung,
Hauptspeicher,
Prozesse.
Dienstetransparenz:
Netzwerk-Browser und Dateisystem,
Internet-Anschluss,
Namensdienst,
Drucker ...



-
Skalierbarkeit
additive Resourcenkumulation,
Inkrementelle Erweiterung,
Nutzung von Gerätepools,
Lastverteilung.
Fehlertoleranz
Graduelle Leistungsabnahme bei Defekten,
Partitionierung und Fusion,
Transaktionssicherheit,
Replikation,
Migration.
Plattformintegration …
Formate und Byteordnung,
Betriebssysteme,
Hardware.
9.3 Verteilte nebenläufige Zugriffe
9.3.1 Lesen & Schreiben im Netz



-
Problem ist die hohe Verzögerung/Latenz.
Fall A: keine Kopien im Netz (unrepliziert)
ortsfeste oder migrierende Seiten,
Seiten-Eigentümer kann sofort zugreifen,
Kommunikationspartner brauchen länger.
Fall B: Kopien im Netz (repliziert):
lesen einer Seite ist sofort möglich,
entweder auf alle Kopien schreiben (update),
oder alle Kopien löschen und nur auf Original schreiben (invalidate).
 Matrixdarstellung:
Ortsfeste Seiten,
R/WOperation
transportiere
n
Migrierende
Speicherteile
, lokale
Operation
ohne Replikation
Verzögerung für
alle, außer für
Eigentümer
mit Replikation
sofort lesen,
überall schreiben,
"write update"
langsam lesen,
langsam
schreiben,
Seitenflattern
aus Cache lesen,
Original
schreiben,
"write
invalidate"
 Nach einem "write invalidate" müssen die Seiten von den interessierten
Lesern erneut angefordert werden.
9.3.2 Nebenläufige Ausführung
 Sequentielles Programm A:
1.
a:= 0;
2.
b:= 0;
3.
a:= 10;
4.
b:= 20;
5.
c:= a+ b;
- ergibt 30 als Resultat in der Variablen "c"
- 120 mögliche Permutationen (5*4*3*2)
- welche Permutat. ergeben richtiges Resultat ?
 Auflösung in Lese- & Schreibbefehle (z.B. für eine Kellermaschine):
"a:=0":
"b:=0":
"a:=10":
"b:=20":
"c:=a+b":
"const(0); write(a)"
"const(0); write (b)"
"const(10); write (a)"
"const(20); write (b)"
"read(a); read(b); add; write (c)"
 Unsynchronisierte Parallelisierung für drei Prozessoren zum Beispiel:
CPU #1
a:=0;
b:=20;
CPU #2
b:=0;
c:=a+b;
CPU #3
a:=10;
- mögliche Resultate für c: { 0, 10, 20, 30 } .
9.3.3 Inkorrekte Ausführungssequenzen:
 Die Reihenfolge der Lese- und Schreib-operationen ist unbestimmt, auf
Grund der Nachrichtenlatenzen über das Netz.
 Falsche Resultate können entstehen, ob-schon die Reihenfolge der
Instruktionen aus der Sicht der einzelnen Prozessoren erhalten bleibt
(sequentielle Konsistenz):
0:
CPU #1
CPU #2
CPU #3
a:=10;
a:=0;
b:=20;
b:=0;
c:=a+b;
10:
CPU #1
a:=0;
CPU #2
CPU #3
b:=0;
a:=10;
c:=a+b;
b:=20;
9.3.4 Sequenzen mit korrektem Resultat:
 Pro Variable muss der Zugriff in der richtigen Reihenfolge garantiert werden
(mit Locks oder sonst irgendwie).
30:
CPU #1
a:=0;
CPU #2
CPU #3
a:=10;
b:=0;
b:=20;
c:=a+b;
 Kausaler Zusammenhang zwischen:
"a:=10;" und "c:=a+b;"
"b:=20;" und "c:=a+b;"
 Datenflussanalyse/-graph hierzu:
 Das nachfolgende Beispiel liefert ein korrektes Resultat, obschon die Instruktionsreihenfolge nicht eingehalten wird:
30:
CPU #1
CPU #2
b:=0;
CPU #3
b:=20;
a:=0;
a:=10;
c:=a+b;
 Der Datenflussgraph wird berücksichtigt,
 Für kausal nicht zusammenhängende Operationen kann die Reihenfolge auch
innerhalb einer CPU vertauscht werden.
 Es gibt Prototypen von Datenflussmaschi-nen, welche die Abhängigkeiten
zwischen Instruktionen an die Hardware delegieren.
9.4 Konsistenz im Verteilten System
9.4.1 Multiprozessorkonsistenz
 Aus der Sicht der einzelnen CPUs sind die Speicherzugriffe streng sequentiell
und die Sicht auf den Speicher "konsistent".


In Wirklichkeit aber:
sind oft veraltete Werte im Hauptspeicher,
Sonderbehandlung nötig für TLB-Tabellen,
verschränken sich nebenläufige Zugriffe,
Ausnahmen für Streaming-Instruktionen.
Für den scheinbar sequentiellen Zugriff sorgt ein ausgefeiltes Bus-Protokoll –
sogar in einer Mehrprozessorkonfiguration.
9.4.2 Der Speicherungskontrakt
 Der Speicherungsmechanismus garantiert gegenüber den zugreifenden
Prozessen, verschiedene Regeln nach welchen er die Schreiboperationen
sichtbar werden lässt.

-
Zum Beispiel:
Sofort, bzw. Getaktet,
Sichtbar nach Anforderung,
Gleiche Sicht für alle Stationen,
Konsistent aus der Sicht einer Station,
Entsprechend einer verteilten Zeitskala,
Geordnet nach einem Zeitstempelverfahren ...
9.4.3 Strikte Konsistenz
 Leseoperationen liefern den zuletzt geschriebenen Wert. - Unabhängig davon
welcher Prozess geschrieben hat.
 Problem: in einem Netz gibt es keine globale Zeit mehr. Der Begriff "zuletzt"
ist unscharf.
Stationen
Verteilter
Speicher
Read/Write Q
 Lese- und Schreiboperationen werden in die Warteschlange unseres Modells
eingefügt.
 Atomare Lese- und Schreiboperationen.
 Die Ausführung der Instruktionen und das Einfügen in die Warteschlange
erfolgt nach einem starren Zeitraster (~ Nicht verteilt).
9.4.4 Sequentielle Konsistenz
 Alle Prozesse sehen die Schreiboperationen in der gleichen Reihenfolge.
 Die Sequenz der Operationen eines Prozes-ses bleibt unverändert.
 Die Verschränkung mit den Operationen anderer Prozesse ist jedoch unbestimmt.
Stationen
Verteilter
Speicher
Read/Write Q
 Die Warteschlangen werden nach einem zufälligen Auswahlverfahren bedient.
9.4.5 Kausale Konsistenz
 Die Forderung nach sequentieller Ausführung bezüglich eines Prozessors wird aufge
geben, nur kausal voneinander abhängige Operationen sind zeitlich geordnet.
 Die kausale Abhängigkeit ergibt sich zum Beispiel aus der operationalen Semantik
eines sequentiellen Programmes.
 Allenfalls auch aus der expliziten Synchro–nisierung eines parallelen Programmes.
 Das Rechnersystem muß den Datenfluss–graphen realisieren:
Stationen
Verteilter
Speicher
9.4.6 PRAM Konsistenz
 Die Reihenfolge innerhalb eines Prozesses wird von allen Stationen gleich gesehen.
 Unterschiedliche Prozesse erscheinen evtl. verschoben für verschiedene Stationen.
 Pipelined RAM Konsistenzmodell:
Stationen
9.4.7 Schwache Konsistenz
 Die beteiligten Prozesse sehen Schreibzu-griffe in beliebiger Reihenfolge, solange sie
nicht explizit ihren Speicher aktualisieren (~synchronisieren).
 Ein Prozess riskiert, veraltete Daten in seinem Speicher zu finden, wenn er nicht
explizit seinen Speicher synchronisiert:
Sync( )
 Update: der schreibende Prozeß verschickt spontan seine Änderungen ("propagate").
 Invalidate: der schreibende Prozeß erklärt die Daten für ungültig. Bei Bedarf werden
diese dann angefordert.
9.4.8 Release-Konsistenz
blocked
acquire
propagate
release





"acquire" versucht den Eintritt in eine kritische Region.
"release" verlässt die kritische Region.
"acquire" blockiert, falls schon ein Prozess die kritische Region betreten hat.
Teilnehmender Prozess tritt mit "acquire" in eine kritische Region ein, zum:
arbeiten mit gemeinsamen Variablen,
propagieren der Variablen,
aufrufen von "release".
Lazy Release: propagiert die Variablen erst wenn der nächste Prozess
Zugang zu den Variablen der kritischen Region wünscht.
9.4.9 Entry-Konsistenz
blocked
acquire(a)
acquire(b)
propagate(a)
release(a)


propagate(b)
release(b)
Es werden Zugriffsrechte auf gemeinsame Variablen vergeben:
separat pro Variable,
exklusiv zum Schreiben,
nicht exklusiv nur zum Lesen.
Feingranulare Synchronisierung auf Objektebene  ggf. weniger
Blockierungen
 Komplizierter zu programmieren.
 Variablen bei Bedarf propagieren ähnlich wie beim Lazy Release Verfahren.
9.4.10
Optimistische Konsistenz
 Alle Schreiboperationen werden vorerst im lokalen Speicher vorgenommen.
 Berechungen werden in rücksetzbare Transaktionen unterteilt.
 Ergeben sich Schreib/Lesekonflikte bei der Validierung, so werden
ausgewählte Trans-aktionen zurückgesetzt und erneut versucht.
 Am Ende einer Transaktion wird der gemeinsame Speicher aktualisiert bzw.
synchronisiert.
Stations
write
read
?
validate
Verteilter Speicher
9.5 Seitenbasierter gemeinsamer Speicher
MMU
Netz
virtueller Speicher

-
phys. Speicher
Abbildung des logischen Adressraumes auf Stationen im Cluster:
Hardwaremässig mithilfe MMU und Paging,
mithilfe einer Segmentierung (HW oder SW),
evtl. R/W-Befehle über Netz transportieren.



Vorteile:
einfaches Programmiermodell,
keine expliziten Nachrichten,
"single-system" Perspektive,
keine Serialisierung.
Nachteile:
Datenaufkommen für ganze Pages,
False sharing.
Verschiedene Konsistenzmodelle möglich.