F. Verteilte Berechnungen/Algorithmen

F.
Verteilte Berechnungen/Algorithmen
F.1 Typische Aufgabenstellungen
 Verteilter gegenseitiger Ausschluss („request_resource()“):
-
Ordnen der Anforderungen mithilfe einer logischen Zeitskala =>
"Voting" Verfahren ohne Reihung der Anforderungen.
ring- oder baumförmige Kommunikationsstruktur,
evtl. Zugriffsrechte über zentr. Server verteilen.
 Auswahlverfahren ("Election"):
- Verdrängungsverfahren ("Bully"),
- Hierarchische Auswahl.
- "Voting" Verfahren =>
 Mehrpunktnachrichten:
- Zuverlässiger Multicast,
- Geordneter Multicast,
- Kausaler Multicast.

Konsensus und Koordination:
- Regulär oder byzantinisch.
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F-1
 Und viele Andere:
-
Verteilter Schnappschuss (bzw. Checkpoint),
Synchronisierung von physischer Zeit.
Transaktion in verteilter Datenbank.
Raytracing in Echtzeit =>
Virtuelle Präsenz,
Grid-Computing,
Online-Spiele,
Web-Services ...
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F-2
F.2 Schnappschussgewinnung nach Chandy & Lamport
 Einsammeln eines konsistenten Zustandes.
 Ablauf:
-
Starterknoten leitet Schnappschuss ein und markiert sich als "Schnapp4711",
Versendet den Befehl "Schnapp4711" auf allen abgehenden Kanälen,
Versendet seinen Zustand weiter zum einsammelnden Knoten SAM,
Versendet alle später ankommenden Nachrichten zum Knoten SAM,
Bis er auf dem jeweilígen Kanal ein "Schnapp4711" Befehl eintrifft,
Andere Knoten sinngemäss nach Erhalt von "Schnapp4711",
"durchspülen".
Status &
Nachrichten
Starter
#1
#2
#3
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
SAM
F-3
F.3 Transaktionen
F.3.1 Grobstruktur
 Klient bzw. Anwendungsprogramm erteilt Aufträge für die Datenbank.
 Transaktionsmanager:
- Verlangt Sperren auf Objekte,
- Commit & validate,
- Setzt Zeitstempel ...
 Scheduler:
- Sucht konsistenten Ablaufplan,
- Verteilt Aufgaben im Netz ...
Klient #1
Klient #2
Klient #3
read,
write,
openTA,
close TA
Klient #4
read,
write,
validate,
commit
 Objektmanager:
-
Prüft die Folge der Zeitstempel,
Organisiert Warteschlangen,
Setzt Transaktionen zurück,
Vergibt Sperren ...
TransaktionsManager
Objekt A
Objekt B
Objekt C
read,
write,
abort,
update
Scheduler
Objekt D
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F-4
F.3.2 ACID Eigenschaften (Härder & Reuter 1983).
 Atomare Durchführung:
- Keine Unterbrechung durch andere Transaktionen.
 Consistenz der Daten:
- Vorher und nachher intakte Datenstrukturen.
 Isolierung:
- Von anderen noch laufenden Transaktionen,
- Jedoch Zugriff zum gültigen Datenbestand.
 Dauerhaftigkeit:
- Resultate werden in sicheren Speicher geschrieben,
- Überleben einen Systemabsturz.
 Ohne ACID-Eigenschaften ergeben sich Komplikationen:
- Explizite Synchronisierung durch Programmierer erforderlich,
- Nebenläufiges Arbeiten in der Datenbank schwierig,
- Erschwerte Rücksetzbarkeit.
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F-5
F.3.3 Rücksetzbarkeit
 "Alles oder Nichts" Eigenschaft einer Transaktion:
- die Transaktion wird ganz oder gar nicht durchgeführt,
- Änderungen können rückgängig gemacht werden,
- mithilfe von zurückgelegten "before images".
Trans-
 Commit-Request:
-
Before Images
aktion
auf Kollisionen mit anderen Transaktionen prüfen,
konkurrierende Transaktionen stimmen zu,
Änderungen permanent machen,
"Before images" wegwerfen.
roll back
commit
 Kaskadierende Rücksetzungen:
- Wenn Resultate einer zurückgesetzten TA gelesen wurden,
- Eventuell rekursive Wirkung auf weitere TAs.
 Rücksetzungen könne nur vermieden werden, wenn:
- alle Objekte zu Beginn der Transaktion angefordert werden,
- alle Transaktionen nur nacheinander ablaufen,
- erweitertes Zwei-Phasen Sperrverfahren.
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F-6
F.3.4 Sperren
 Synchronisierungsobjekte, Englisch "Lock".
 Regeln den Zugriff auf Objekte, die von mehreren Threads gleichzeitig
benützt werden.
 In Java durch das Schlüsselwort "synchronized" impliziert:
public class Link { // sicheres Einfügen & Entfernen in eine Liste
static Link anchor=null; Link next=null;
static synchronized Link DeQueue( ){ // nur ein Monitor für beide
Link front=anchor; anchor=anchor.next;
return front;
}
static synchronized void EnQueue( Link newElement ){
newElement.next=anchor; anchor=newElement;
}
}
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F-7
F.3.5 2-Phasen Sperrverfahren
Sperren
 Sperrphase erwirbt nach und nach alle
Sperren.
 Freigabephase gibt sukzessive alle Sperren
wieder frei:
 Striktes 2-Phasen Sperrverfahren fordert
alle Sperren sofort an und gibt diese erst
am Ende wieder frei.
 Verklemmungen vermeiden:
Sperrphase
sperren
Freigabe
t
freigeben
- Sperren sind in einer Reihe geordnet, und
werden von allen Transaktionen der Reihe
nach angefordert,
t
 Bewertung des 2-Phasen Sperrverfahrens:
- Einfach zu implementierendes Schedulingverfahren für Transaktionen,
- Viele Sperren über ein Netz anzufordern, ist jedoch teuer.
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F-8
F.3.6 Serialisierbarkeit von Transaktionen
 Aus der Sicht des Programmierers keine Interaktion zwischen TAs.
 Gesucht ein Schedule, der äquivalent zu einer seriellen Ausführung ist.
 Überlappende Ausführung für schnellere Durchlaufzeiten.
 Serialisierung mithilfe von Sperren:
- Vollständig oder teilweise serialisieren,
- Semaphore, kritische Regionen, Mutex,
- Nachrichten für "Signal" & "Wait".
 Abhängigkeiten zwischen TAs:
- Verfrühtes Schreiben wird durch eine
fremde Rücksetzung überschrieben,
- "Dirty Read" liest Daten, die später
wieder ungültig werden.
 TA#2 wird in die Rücksetzung von TA#1 hineingezogen (cascading a.).
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F-9
F.3.7 Optimistisches Scheduling von Transaktionen
 Die optimistische Strategie impliziert:
- Konflikte zwischen Transaktionen sind sehr selten (Hypothese),
- Alle Transaktionen sind rücksetzbar.
 Kommt ohne Sperren oder Locks aus:
- Kein Overhead für die Acquisition von Sperren,
- Deadlocks können nicht entstehen.
 Einteilung in drei Phasen üblich:
- Ausführung stellt provisorische Resultate bereit,
- Validierung prüft auf Konflikte zwischen TAs,
- Update macht evtl. die Resultate permanent.
Ausführung
Validierung
t
Update
?
Ausführung
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
Validierung
Update
F - 10
F.3.8 Konfliktmöglichkeiten beim Validieren:
 Transaktion #2 liege später im äquivalenten sequentiellen Schedule.
 Während der TA werden Read-Set und Write-Set aufgezeichnet.
 Read-Write Konflikt:
- ein durch andere TAs geschriebenes Objekt wird gelesen,
- Zeitpunkt des Lesens/Schreibens ist unbekannt,
- „dirty read“ Situation möglich.
 Write-Write Konflikt:
- beide Transaktionen schreiben dasselbe Objekt,
- die Schreibreihenfolge ist unbekannt,
- „premature write“ möglich:
 Erst nach erfolgreicher Validierung
werden die provisorischen Resultate
sichtbar und permanent (welche
denn ?).
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F - 11
 Vorwärtsvalidierung isoliert laufender Transaktionen:
-
nur mit überlappenden, noch aktiven TAs vergleichen,
zukünftige Read/Write-Sets mit aktuellem Write-Set vergleichen,
aktuelle oder zukünftige Transaktion abbrechen,
TA#1 wird validiert.
???
???
 Rückwärtsvalidierung isolierter TAs:
-
nur mit überlappenden, abgeschlossenen TAs vergleichen,
alte Write-Sets mit aktuellem Read/Write-Set vergleichen,
fremde, alte Readsets ignorieren,
TA#2 wird validiert.
s
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F - 12
F.3.9 Zeitstempelverfahren
 Jede Transaktion erhält einen Zeitstempel.
 Mithilfe des Zeitstempels werden die Lese- und Schreiboperationen direkt
bei den Objekten validiert oder abgebrochen.
 Eine Schreiboperation ist ungültig, wenn der letzte fremde Schreib- oder
Lesezugriff einen jüngeren Zeitstempel trägt.
 Eine Leseoperation ist ungültig, wenn die letzte fremde Schreiboperation
jünger als die Leseoperation ist ("premature write").
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F - 13
 Jede einzelne Operation trägt den Zeitstempel ihrer Transaktion.
 Wenn die Operationen und ihre Zeitstempel in Warteschlangen eingeordnet werden, so kann eine bessere Nebenläufigkeit erreicht werden:
 Scheduler könnte gegebenenfalls auch Zeitstempel der TA umordnen.
 Trifft Operation zu spät beim Objekt ein, wird die TA abgebrochen.
 Zunehmend schwierigere Implementierung:
- 2-Phasen Sperrverfahren, optimistisches Scheduling, geordnete Zeitstempel.
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
F - 14
F.3.10 Zwei-Phasen Commit Protokoll
 Commit Request am Ende jeder Transaktion.
-
Klient sendet EndOfTA zum Transaktionsmanager,
Transaktionmanager befragt die Objekt-Manager,
Commit falls alle Objekte zugestimmt haben,
Abort falls ein Objekt nicht zustimmt,
Bestätigung durch die Objekte.
 Fehlermodell:
-
Fehler falls TA-Manager mit Timeout endet,
Objekte können Ihren Teil der TA zurückrollen,
Objekte bewahren Schattenkopien auf,
Abgestürzte Server starten erneut,
Nur "Fail-Stop" Fehler.
Klient
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
EndOfTA
validateTA
Validierungsphase
Updatephase
"yes" (or "no")
DoUpdate
Updated
Done
TA-Mgr
Objekte
F - 15
F.3.11
Ein-Phasen Commit ist nicht sinnvoll
 In der Praxis unbrauchbar, da normalerweise nicht sichergestellt ist, dass
alle Objekte committen können.
 Keine Trennung in Validierung und Update.
 Keine Sicherheit bei Serverabstürzen.
EndOfTA
Klient
Transaktionsmanager
Commited
Done
Commit
Objekt#1
Verteilte Betriebssysteme, 2008/09, VS, Universität Ulm
Objekt#2
Objekt#3
F - 16