Überblick Wintersemester 2014/2015 Prof. Dr. Peter Mandl Verteilte Systeme Einführung und Überblick Zeitsynchronisation Wahl und Übereinstimmung RPC, verteilte Objekte und Dienste Verteilte Transaktionen Message Passing Middlewareplattformen Verteilte Architekturen Gruppenkommunikation Replikation Wechselseitiger Ausschluss Seite: 1
Überblick 1. Einführung und Motivation 2. Grundregende Transaktionskonzepte 3. Commit-Protokolle 4. Das DTP-Modell Auch ein Klassiker: Bernstein, P. A.; Hadzilacos, V.; Goodman, N.: Concurrency Control and Recovery, Addison-Wesley, 1987 Seite: 2
Zielsetzung Zielsetzung der Vorlesung: - Verstehen, wie das Transaktionskonzept in verteilten Systemen grundsätzlich funktioniert - Verstehen, wie verteilte Transaktionen sinnvoll angewendet werden können - Standards der verteilten Transaktionsverarbeitung kennenlernen und anwenden können Jim Gray, Forscher bei Microsoft Klassiker: Gray, J.; Reuter, A.: Transaction Processing, Concepts and Techniques, Morgan Kaufmann Publisher, 1993 Quelle: http://news.cnet.com/8301-13860_3-9864374-56.html Seite: 3
Lokale Transaktionen Betriebliche Informationssysteme sind meist sehr nebenläufig Die hohe Parallelität impliziert auch eine hohe Konkurrenz beim Zugriff auf die Daten Die Konsistenz der Daten muss sichergestellt werden Client-Arbeitsplätze oder Terminals Server/Mainframe... Datenbank Früher war alles einfacher! Seite: 4
Beispieltransaktion Eine einfache Beispieltransaktion auf eine SQL- Datenbank begintransaktion SELECT * FROM Konto WHERE Kontonummer = 100 SELECT * FROM Konto WHERE Kontonummer = 200 Betrag von Konto 1 abziehen Betrag zu Konto 2 zubuchen UPDATE Konto WHERE Kontonummer = 100 SET... UPDATE Konto WHERE Kontonummer = 200 SET... if (alles ausgeführt) commit work else rollback work endtransaktion Transaktion beginnt Transaktion endet erfolgreich Transaktion endet erfolglos, nichts ist passiert Seite: 5
Transaktionen in verteilter Umgebung Bei verteilten betrieblichen Informationssystemen sind Transaktionen wesentlich komplexer Eine verteilte Koordination ist erforderlich Clients Server Database 1... Database 2... Seite: 6
Überblick 1. Einführung und Motivation 2. Grundregende Transaktionskonzepte 3. Commit-Protokolle 4. Das DTP-Modell Seite: 7
Anomalien bei Nebenläufigkeit Nebenläufiger Zugriff auf Ressourcen muss synchronisiert werden - Synchronisationsprobleme wie im lokalen Umfeld - Vgl. Semaphore und Monitore Fehlersituationen, Anomalien (siehe Datenbanken) - Lost-update - Dirty-read - Unrepeatable-read - Phantoms Lösung: Scheduling, Serialisierung - Pessimistische Verfahren: Locking - Optimistische Verfahren Seite: 8
Konflikte beim Zugriff (1) Serieller Zugriff auf Objekte time T1 T2 T3 read write read read write write Keine Konflikte! o1 o2 o3 o4 o5 o6 Shared Objects o7 Seite: 9
Konflikte beim Zugriff (2) Nebenläufiger Zugriff auf Objekte time T1 read read write T2 read write T3 write Konflikte möglich! o1 o2 o3 o4 o5 o6 Shared Objects o7 Seite: 10
Anomalien durch Zugriffskonflikte T 1 T 2 T 1 T 2 T 1 T 2 read (O 1 ) read (O 1 ) read (O 1 ) write (O 1 ) read (O 1 ) write (O 1 ) read (O 1 ) write (O 1 ) read (O 1 ) write (O 1 ) rollback t t t read (O 1 ) a) lost-update b) dirty-read c) unrepeatable-read Seite: 11
Scheduler Schedules: Typisch für Datenbanken Korrektheit von Schedules: - Serialisierbarkeitstheorie, Serialisierbarkeit! Datenmanager (Ressourcen- Manager) Schedule: (T 1, O 1 ), (T 2,O 1 ), (T 2,O 2 ),... Scheduler (T 1,O 1 ), (T 1,O 2 ), (T 1,O 3 ) (T 2,O 1 ), (T 2,O 2 ), (T 2,O 3 ) (T 3,O 1 ), (T 3,O 2 ) (T x,o y ): Operation y in Transaktion x Seite: 12
Korrektheit einer Transaktion Strenge Korrektheitskriterien lösen das Problem: A.C.I.D. A.C.I.D.-Transaktionen sind kurze und schnelle Transaktionen! Strenges Konsistenzmodell! Rollback/Abort Begin Konsistenter Zustand Inkonsistenter Zustand Commit t Konsistenter Zustand Seite: 13
Transaktionsmodelle Flache Transaktionen (flat transactions) Geschachtelte Transaktionen (nested transactions) - Transaktionsbaum, Top-Level- und Subtransaktionen - Offen geschachtelt - Geschlossen geschachtelt Langlebige Transaktionen (long transactions) Verkettete Transaktionen (chained transactions) Queued Transactions Seite: 14
Beispieltransaktion: Flat Transaction void umbuchen(int artikelnummer, int anzahl, Lagerplatz quelle, Lagerplatz ziel) {... } try ( ) {. begintransaction(); quelle.abbuchen(artikelnummer, anzahl); ziel.zubuchen(artikelnummer, anzahl); committransaction(); } catch() { rollbacktransaction();... } finally() {... } Hier: Explizites Setzen der Transaktionsgrenzen Überwiegend im Einsatz! Seite: 15
Geschachtelte (nested) Transaction Offen oder geschlossen Diskussion: ACID! Praxiseinsatz fraglich Top-Level- Transaktion Subtransaktionen Subtransaktionen begintransaction... call subtransaction... call subtransaction... committransaction begintransaction call subtransaction call subtransaction committransaction begintransaction... committransaction begintransaction... rollbacktransaction begintransaction... committransaction Seite: 16
Long (langlebige) Transaction Typisch für längere Workflows Spezielle offen geschachtelte Transaktionen = Sagas Top-Level-Transaktion mit einer Kind-Ebene, die ACID- Transaktionen ausführen Starre Schachtelungsform Kompensationstransaktionen notwendig Diskussion: ACID! Seite: 17
Concurrency Control durch Sperren Konservatives Two-Phase-Locking (2PL) In der Praxis selten Problem: Kaskadierte Aborts möglich Anzahl Sperren Alle Sperren gesetzt Alle Sperren freigegeben Zunahmephase Abnahmephase t Seite: 18
Concurrency Control durch Sperren Strenges (striktes) Two-Phase-Locking (2PL) Heute Standardverfahren Vorsicht Deadlocks Timerüberwachung Anzahl Sperren Alle Sperren gesetzt Alle Sperren freigegeben Zunahmephase Abnahmephase t Alle Sperren werden hier freigegeben Seite: 19
Deadlocks, Behandlung Deadlock-Vermeidung - Alle Sperren am Transaktionsbeginn anfordern - Nicht realistisch! Deadlock-Erkennung und -Auflösung - Zeitüberwachung -> Praktikabel! - Deadlock-Detector, Wait-for-Graphen Seite: 20
Logging und Recovery Logging: Persistente Speicherung von Wiederanlaufinformation - Systemkomponente: Logging Manager Recovery: Ausführen des Wiederanlaufs unter Nutzung der Wiederanlaufinformation - Systemkomponente: Recovery Manager T 1 T 2 T 3 T 4 Standards heute: - Write-Ahead-Logging (WAL) - Undo-/Redo-Verfahren T 5 Fehler: Systemabsturz t Seite: 21
Einschub: Interessante Frage zur Diskussion Wohin wird das Transaktions-Log gespeichert und wie wird es beim Recovery genutzt? Seite: 22
Einbringen und Ersetzen Begriffe aus der Datenbanktechnologie Einbringstrategie: Regelt Schreiben von committed Daten - Force - Noforce Ersetzungsstrategie: Regelt Schreiben von uncommitted Daten - Steal - Nosteal Seite: 23
Strategien Es geht um die Freiheit der Auswahl des Zeitpunkts, wann eine Änderungsoperation auf nicht-flüchtigen Speicher geschrieben werden soll Wichtiger Optimierungsaspekt für Ressourcenmanager Auswirkungen auf die Recovery-Strategie Seite: 24
Strategien Undo und Redo-Verfahren Undo: Zurücksetzen Redo: Erneut ausführen Kombinationen möglich: - No-Undo/No-Redo - No-Undo/Redo - Undo/No-Redo - Undo/Redo Üblich bei Datenbanken: Undo/Redo-Strategie mit Write-Ahead-Logging (WAL) Seite: 25
Einordnung der Recovery-Strategien Redo notwendig Undo notwendig Seite: 26
Anatomie eines Transaktionssystems Application Coordinator RS RM (Participant) CS RS LS Log LS Log TS PS Data Protocol Stack Protocol Stack Protocol Stack Communication Protocols RS = Recovery Service LS = Logging Service TS = Transaction Service CS = Concurrency Control Service PS = Persistency Service Seite: 27
Überblick 1. Einführung und Motivation 2. Grundregende Transaktionskonzepte 3. Commit-Protokolle 4. Das DTP-Modell Seite: 28
Two-Phase-Commit (2PC) Normalfall Koordinator-/Teilnehmer-Modell, Koordinator oder ein Teilnehmer beginnt die Koordination in Phase 1 Heute Standardprotokoll, aber viele Implementierungsvarianten Anwendung Koordinator Teilnehmer 1 Teilnehmer 2 Seite: 29
Two-Phase-Commit (2PC) Fehlerszenario Entweder alle Teilnehmer oder kein Teilnehmer führen/führt Operationen aus Blockierung der Teilnehmer möglich Ausfall des Koordinators Anwendung Koordinator Teilnehmer 1 Teilnehmer 2 Commit Prepare-Request Phase 1 Prepare-Request ready Log ready Log Commit- Entscheidung Abort-Request not ready Log not ready Phase 2 Log Ergebnis aborted ok Log aborted Aborted Koordinator ist ein Single Point of Failure! 2PC hat ein Terminierungsproblem Seite: 30
2PC-Zustandsautomat Sichere Protokollimplementierung ist aufwändig Insbesondere der Recovery-Fall Koordinatorknoten Teilnehmerknoten Koordinator Koordination Teilnehmer 2PC-SAP 2PC-Protokollinstanz (Koordinator) T-SAP 2PC-PDUs 2PC-SAP 2PC-Protokollinstanz (Teilnehmer) T-SAP Transportsystem (z.b. TCP) Seite: 31
Typischer 2PC-Zustandsautomat Koordinator Init Aufruf von Commit; Sende Prepare-Request Aufruf von Rollback; Sende Rollback-Request Empfangen eines Abort- Request; Sende Rollback-Request Preparing Empfangen eines Abort-Request oder eines Prepare-Response (not ready); Sende Rollback-Request Empfangen eines Rollback- Response; Speichere Ergebnis Empfangen eines Prepare- Response (ready); Speichere Ergebnis Aborting Rollback Empfangen des letzten Prepare-Response(ready); Speichere Ergebnis und sende Commit-Request Empfangen eines Rollback- Response; Speichere Ergebnis Committing Empfangen eines Commit- Response; Speichere Ergebnis Empfangen des letzten Rollback-Response; Speichere Ergebnis Empfangen des letzten Rollback-Response; Speichere Ergebnis Empfangen des letzten Commit-Response; Speichere Ergebnis Aborted Committed Seite: 32
Typischer 2PC-Zustandsautomat Teilnehmer Empfang eines Prepare- Request; Sende Prepare-Response (ready) Init Empfang eines Prepare-Request; Sende Prepare-Response (not ready) Operationen werden verarbeitet Empfang eines Rollback-Request; Sende Rollback-Response Prepared Empfange Rollback-Request; Speichere Ergebnis und sende Rollback-Response Aborted Empfang eines Commit-Request; Speichere Ergebnis und sende Commit-Response Committed Mehrere 2PC-Varianten: Optimierung durch Reduzierung der Nachrichtenkomplexität und durch Reduzierung der Anzahl an Logsätzen Seite: 33
Recovery-Szenarien diskutieren Ausfall Teilnehmer und Restart Was findet ein Teilnehmer nach dem Restart für jede Transaktion im Logfile? Was macht er mit dieser Information? Beispiele diskutieren Committed, Aborted, nichts? Ausfall Koordinator und Restart Was findet ein Koordinator nach dem Restart je Transaktion im Logfile? Was macht er mit dieser Information? Beispiele diskutieren Committing, Committed, Aborted? Seite: 34
One-Phase-Commit (1PC) Optimierung bei nur einem Teilnehmer Anwendung Koordinator Teilnehmer Seite: 35
Three-Phase Commit (3PC) (1) Blockierungssituation soll vermieden werden Idee: Einführung einer weiteren Phase (Precommit) Blockierung durch Ausfall eines Koordinators wird verhindert durch die Wahl eines neuen Koordinators aus der Menge der Teilnehmer dadurch Terminierung sichergestellt Mehrere 3PC-Protokolle wurden vorgeschlagen, wenige implementiert; Probleme bleiben: Es ist keine 3PC-Implementierung bekannt, die vollständig korrekt arbeitet Z.B. ist nicht geklärt, wie bei Netzwerkpartitionierung vorgegangen wird, wenn versehentlich zwei Koordinatoren im Netz sind Seite: 36
Three-Phase-Commit (3PC) (2) Anwendung Koordinator Teilnehmer 1 Teilnehmer 2 Seite: 37
Three-Phase Commit (3PC) (3) Fehlerbehandlung Mit dem Precommit sichert Koordinator zu, dass er von sich aus die Transaktion nicht mehr zurücksetzt Koordinatorausfall wird durch Timeout-Überwachung der Teilnehmer erkannt Wenn Koordinator ausfällt, wird ein neuer gewählt, der zunächst (im nichtpartitionierten) Netz die Transaktionszustände erfragt: Ein Teilnehmer sendet Commit oder Abort: Transaktion wird entsprechend beendet Ein Teilnehmer sendet Precommit: Transaktion kann mit Versenden von Precommit an alle Teilnehmer weitergeführt werden Seite: 38
Commit-Protokolle Kommunikationskomplexität Vergleich bei Commit-Initiierung im Koordinator ohne Optimierungen Hier: n = Anzahl der beteiligten Prozesse alle Teilnehmer und der Koordinator Commit- Protokoll Allgemeine Formel Beispiel 1 (n=2) Beispiel 2 (n=10) Beispiel 3 (n=11) 1PC 2 * (n-1) 2 18 20 2PC 4 * (n-1) 4 36 40 3PC 6 * (n-1) 6 54 60 Seite: 39
Paxos Commit Protocol (1) Erfinder: Leslie Lamport und Jim Gray Gray, J.; Lamport, L.: Consensus on Transaction Commit, Microsoft Research, TechReport-Number MSR-TR-2003-96, 2005, http://research.microsoft.com/apps/pubs/default.aspx?id=64636 (letzter Zugriff am 17.08.2013) Basis ist das Paxos Consensus Protokoll Rollen: RM, Leader, Acceptor Protokoll, das Schwächen von Two-Phase-Commit-Protokollen und Three-Phase-Commit-Protokollen behebt Funktioniert auch bei Netzwerkpartitionierung Blockiert nicht, solange eine Mehrheit von Teilnehmern verfügbar ist Ausfallsicheres Commit-Protokoll Seite: 40
Paxos Commit Protocol (2) N Ressourcenmanager (RM) A Acceptors (= Koordinatoren) Alle N RMs sind einem Leader zugeordnet RM beginnt mit Abschluss der Transaktion durch BeginCommit-Nachricht an den Leader Mehrheit der Acceptors muss dem Commit zustimmen: A/2+1 Acceptoren sonst Blockierung bis Mehrheit an Acceptors verfügbar ist Wenn F Acceptoren ausfallen, müssen 2F+1 Acceptors vorhanden sein 2PC ist Paxos-Sonderfall mit F=0 Seite: 41
Paxos Commit Protocol (3) Protokollablauf Gutfall: RM1 startet den Commit- Vorgang Acceptors Alle Knoten verwalten Logfiles Leader A1 A2 A3 RM1 RM2 BeginCommit Prepared Prepare Prepared Commit Prepared Seite: 42
Paxos Commit Protocol (4) Nachrichtenkomplexität 2F+1 Acceptors (Koordinatoren), wobei F davon fehlerhaft sind, N RMs sind an der Transaktion beteiligt: Initialer RM informiert Leader mit 1 BeginCommit-Nachricht Leader sendet N-1 Prepare-Nachrichten an restliche RMs Alle N RMs senden an alle ausgewählten F+1 Acceptors insgesamt N(F+1) Prepared-Nachrichten F+1 Acceptors senden je eine Prepared-Nachrichten an den Leader Leader sendet Commit-Nachricht an alle N RMs Anzahl Nachrichten = NF+3N+F+1 = (N+1)(F+3)-2 Bei (F+1) = 3 aktiven Acceptors und 2 RMs: 3*5-2 = 13 Nachrichten Paxos benötigt deutlich mehr Nachrichten als 2PC im Normalfall Optimierungen: z.b. Faster Paxos Commit Protocol Seite: 43
Überblick 1. Einführung und Motivation 2. Grundregende Transaktionskonzepte 3. Commit-Protokolle 4. Das DTP-Modell Seite: 44
DTP-Modell: Lokales Modell Instanz nach DTP-Modell Meist: Ein RM und ein TM http://www.opengroup.org/ Oft im Einsatz Alle DBMS und Message-Queuing-Systeme sind RMs im Sinne des Modells AP z.b. SQL TX Flat und chained Transactions werden unterstützt Keine geschachtelten Transaktionen RM XA TM Das ist der eigentliche Standard Seite: 45
DTP-Modell: Verteiltes Modell Selten im Einsatz OSI TP ist aufwändig zu implementieren Superior Node AP Subordinate Node AP z.b. SQL TX TxRPC XATMI CPI-C z.b. SQL TX TxRPC XATMI CPI-C RM TM CRM RM XA+ XA XA TM XA+ CRM XAP-TP XAP-TP OSI TP OSI TP Seite: 46
DTP-Modell: Terminologie Thread of Control - Kurz: Thread - Auch Ausführungspfad genannt - Alle Komponenten (AP, TM, RM) müssen sich bei Operationen zu einer Transaktion über den Thread of Control einig sein - Nicht unbedingt ein Betriebssystem-Thread, aber in der Praxis üblich - Transaktionskontext ist einem Thread of Control zugeordnet Zustand einer Transaktion, Beteiligte, AP RM Transaktionskontext TM Seite: 47
DTP-Modell: Terminologie Instanz (des Modells) - Konkrete Implementierung des Modells - Enthält ein konkretes AP, einen konkreten TM und einen oder mehrere konkrete RMs - Commit zwischen TM und RMs AP RM1 RMn TM Seite: 48
DTP-Modell: Terminologie Transaktionsdomäne oder TM-Domain - Mehrere Instanzen, die den gleichen TM benutzen AP1 RM1 TM RMn AP2 Seite: 49
DTP-Modell: Terminologie Transaction Branch - Teil einer globalen Transaktion - Transaction Branch hat globale Id = Transaction Branch Identifier (beinhaltet auch Id für globale TA) - Beispiel: Eine globale TA mit drei Transaction Branches aus AP- Sicht AP1 Transaction Branch 1 RM1 Transaction Branch 3 Transaction Branch 2 AP2 RM2 AP3 RM3 Transaktionskontext Seite: 50
DTP-Modell: Terminologie Verteilte Applikation nutzt mehrere Instanzen - Zusätzlich ein CRM in jeder Instanz - OSI TP als Transaktionsprotokoll - Commit komplizierter, wird zwischen TMs propagiert AP RM1 RMn AP RM1 RMm CRM TM Instanz 1 CRM TM Instanz 2 OSI TP Seite: 51
DTP-Modell: XA-Schnittstelle Statische und dynamische Registrierung eines RM an einer Transaktion möglich XA-fähiger Transaktionsmanager ax_reg ax_unreg XA-fähiger Ressourcenmanager xa_open xa_close xa_start xa_complete xa_prepare xa_commit xa_rollback xa_recover xa_end xa_forget Seite: 52
DTP-Modell: Zusammenspiel der Komponenten Statisches Registrieren Thread tx_begin Vor erster Transaktion TM xa_open xa_open xa_start RM 1 Initialisierungen RM 2 Initialisierungen xa_start tx_commit 2 PC Log Commit- Entscheidung Log Ergebnis xa_prepare xa_prepare xa_commit xa_commit xa_end Log ready Log committed Log ready Log committed ok xa_end Nach letzter Transaktion xa_close xa_close Seite: 53
DTP-Modell: Zusammenspiel der Komponenten Dynamisches Registrieren Thread TM RM 1 tx_begin Initialisierungen Operation ax_reg XID als Returnwert tx_commit 2 PC Log Commit- Entscheidung Log Ergebnis xa_prepare Weitere RMs... xa_commit Log ready Log committed Seite: 54
DTP-Modell: Was fehlt? Nur das Commit-Protokoll wird spezifiziert Spezielle Variante von 2PC und 1PC Nur das Modell der flat Transactions wird unterstützt Keine Standards für - Logging - Recovery - Locking Seite: 55
Praktische Ansätze Flache Transaktionen kurz halten Geschachtelte Transaktionen vermeiden A.C.I.D lässt sich nicht überall gebrauchen, Aufweichungen sind oft sinnvoll Keine Transaktion beginnt im Client (am Arbeitsplatz) zu instabil One-Transaction-Per-Request Anwendung regelt Kompensation Seite: 56
Überblick Einführung und Motivation Grundregende Transaktionskonzepte Commit-Protokolle Das DTP-Modell Seite: 57