Überblick Wintersemester 2014/2015

Transkript

1 Ü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

2 Literatur für diesen Teil Coulouris G., et al.: Distributed systems: concepts and design, 5. Auflage, Prentice-Hall, 2012 Tanenbaum, A., Steen, M.: Verteilte Systeme - Prinzipien und Paradigmen, 2. Auflage, Prentice-Hall, 2008 Bengel, G.; Baun C.; Kunze, M.; Stucky, H.: Masterkurs Parallele und Verteilte Systeme, Vieweg-Teubner-Verlag, 2008 Weber, M.: Verteilte Systeme, Spektrum Akademischer Verlag, 1998 Burrows, M., Google Inc: The Chubby lock service for loosely-coupled distributed systems, OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November, 2006 Ricart, G.; Agrawala, A. K.: An Optimal Algorithm for Mutual Exclusion.in Computer Networks. Communications of the ACM, Januar 1981, Ausgabe 24, Nummer 1, S Maekawa M.: A n Algorithm for Mutual Exclusion in Decentralized Systems. in: ACM Transactions on Computer Systems, Volume 3 Issue 2, May 1985, S Seite: 2

3 Zielsetzung Zielsetzung der Vorlesung: - Der Studierende soll die Probleme beim wechselseitigen Ausschluss zur verteilten Synchronisation kennenlernen und verstehen und - die Behandlung von Deadlocks in verteilten Systemen nachvollziehen können. Seite: 3

4 Überblick 1. Wechselseitiger Ausschluss in verteilten Systemen 2. Fallbeispiel: Google s Chubby Lock Service 3. Verteilte Deadlocks und Deadlockbehandlung Prof. Dr. Peter Mandl Verteilte Systeme Seite: 4

5 Wechselseitiger Ausschluss Alternativen (1) Lokale Lösungsansätze - Nutzung von Semaphoren, Locks, Monitoren,... - Nur ein Prozess/Thread darf zu einer Zeit in einen kritischen Abschnitt Es gibt zwei Ansätze für verteilte Systeme - Zentralisierte Entscheidung durch einen dedizierten Serverprozess, der den kritischen Abschnitt überwacht - Entscheidung in einer Gruppe von gleichberechtigten Prozessen (Ring- oder Abfrage-basiert) Kritischer Abschnitt darf zu einer Zeit nur von einem Prozess betreten werden Warteschlange wird geführt Seite: 5

6 Wechselseitiger Ausschluss Alternativen (2) - Übersicht Wechselseitiger Ausschluss Lokales System Verteiltes System Semaphore Locks Monitore... Zentralisiert... Gruppenabstimmung P(); Kritischer Abschnitt V(); Dedizierter Serverprozess Ring-basiert Abfrage-basiert Seite: 6

7 Zentralisierter Ansatz Dedizierter Serverprozess (Koordinator) führt eine Warteschlange für die kritische Ressource Koordinator stellt Single Point of Failure dar Vernünftiger Nachrichtenaufwand Beispielsweise sind folgende Nachrichtentypen notwendig - Anfrage auf Eintritt in kritischen Abschnitt (wie P-Operation) - Warten, da belegt - Verlassen des kritischen Abschnitts (wie V-Operation) - Erlaubnis Seite: 7

8 Zentralisierter Ansatz - Beispielablauf Beispiel: P z ist der Koordinator (KA = kritischer Abschnitt) Schritt 1: P1 fragt an P z Zentraler Prozess mit Queue Schritt 2: P2 fragt an P z P2 P1 P2 P3 Pn P1 P2 P3 Pn Schritt 3: P1 verlässt KA P z P2 Schritt 4: P2 darf in KA P z P1 P2 P3 Pn P1 P2 P3 Pn Seite: 8

9 Verteilter Ansatz: Ring-basiert Protokoll Kein dedizierter Serverprozess notwendig Die Prozesse sind logisch als Ring angeordnet und über einen Kommunikationskanal verbunden Prozess P i kommuniziert mit Prozess P (i+1) mod n (n = Anzahl der beteiligten Prozesse) Protokoll - Ein sog. Eintrittstoken wird in einer Nachricht im Ring weitergereicht - Prozesse, die kein Interesse haben, leiten das Token an den nächsten Prozess weiter - Wenn ein Prozess in den kritischen Abschnitt eintreten möchte, behält er das Token und gibt es erst wieder weiter, wenn seine Arbeit abgeschlossen ist Seite: 9

10 Verteilter Ansatz: Ring-basiert Beispiel - Knotenausfall Token wird immer im Ring gesendet Schritt 1: P5 hält das Token aktuell Schritt 2: Prozess P6 fällt aus P2 P3 P2 P3 P1 P4 P1 [Token] P4 [Token] P7 P5 P7 P5 P6 P6 Ring muss wieder geschlossen werden Seite: 10

11 Verteilter Ansatz: Ring-basiert, Bewertung Hohes Nachrichtenaufkommen, auch wenn kein Prozess in den kritischen Abschnitt möchte Der Ring ist fehleranfällig und muss immer geschlossen sein Es muss einen automatisierten Rekonfigurationsmechanismus geben (kompliziert) Wie kann ein Prozess, der wieder aktiv wird, in den Ring zurückfinden? Tokenfehler müssen erkannt werden (sichere Übertragung) Eintrittsverzögerung muss ggf. in Kauf genommen werden (0 bis n 1 Prozesse vorher) Seite: 11

12 Verteilter Ansatz: Abfrage-basiert, Protokoll Ansatz nach Ricart et al. (1981) Prozess sendet eine Anfrage an alle, die Anfrage enthält einen Zeitstempel (Lamport-Uhr) Die anderen Prozesse melden ihre Zustände an den anfragenden Prozess: Released: Prozess ist nicht im kritischen Abschnitt Held: Prozess gerade im kritischen Abschnitt Wanted: Prozess möchte auch in den kritischen Abschnitt Alle Antworten müssen abgewartet werden und dann kann der kritische Abschnitt betreten werden Alle Prozesse mit Zustand Released antworten mit einer Erlaubnis Ist ein Prozess im Zustand Held, antwortet er nicht Ist ein Prozess im Zustand Wanted, entscheidet der Zeitstempel ggf. gemeinsam mit der Id des Prozesses (bei Gleichheit) Nach dem Verlassen des kritischen Abschnitts, wird eine Erlaubnis an die in der eigenen Warteschlange eingereihten Prozesse gesendet Seite: 12

13 Verteilter Ansatz: Abfrage-basiert, Beispiel (1) Anfrage Runde 1: 4 Prozesse, P1 und P4 wollen fast gleichzeitig in den kritischen Abschnitt (keiner ist momentan drinnen) Beide fragen an P2 C 1 = 20 P1 P3 Anfrage von P1 Anfrage von P4 P4 C 4 = 18 Seite: 13

14 Verteilter Ansatz: Abfrage-basiert, Beispiel (2) Einigung Runde 2: P4 hat den kleinsten Zeitstempel und gewinnt P1, P2 und P3 bestätigen P4 Erlaubnis für P4 P1 erhält keine Bestätigung von P4 P4 ist im Zustand Held und antwortet P1 nicht P2 C 1 = 20 P1 P3 Zeitstempel von P4 ist kleiner: C 4 < C 1 P4 C 4 = 18 P1 P1 wird in Queue eingetragen Seite: 14

15 Verteilter Ansatz: Abfrage-basiert, Beispiel (3) Wartender Prozess erhält nun die Erlaubnis Runde 3: P4 tritt in kritischen Abschnitt ein, beendet seine Arbeit und sendet anschließend die Erlaubnis an P1 P2 C 1 = 20 P1 P3 P1 hat jetzt von allen die Erlaubnis und darf eintreten P4 C 4 = 18 P1 Seite: 15

16 Verteilter Ansatz: Abfrage-basiert, Bewertung (1) Algorithmus funktioniert für kleine Gruppen, die Ihre Mitgliedschaften nie oder sehr selten ändern Nachrichtenaufkommen: 2(n-1) Nachrichten je Knoten, der in kritischen Abschnitt will, bei n Knoten Hohes Nachrichtenaufkommen, wenn alle n Prozesse gleichzeitig in den kritischen Abschnitt wollen: Jeder Knoten benötigt 2(n-1) Nachrichten 2n(n-1) = 2n 2-2n Nachrichten insgesamt Kommunikationsaufwand bei O(n 2 ) Unnötige Arbeitsbelastung für Prozesse, die gar nicht in den kritischen Abschnitt wollen (Anfragen bearbeiten) Seite: 16

17 Verteilter Ansatz: Abfrage-basiert, Bewertung (2) Prozess-Id muss global eindeutig sein dies bedeutet, ein zentraler Mechanismus zur Prozess-Id-Konfigurierung ist erforderlich (möglich: Id = IP-Adresse + PID) Ein zentraler Manager muss alle Prozesse kennen und auch bei Ausfall informiert werden und reagieren Protokoll ist daher fehleranfällig, zentraler Manager ist Single-Point-of- Failure Ohne zentralen Manager gäbe es n Fehlerstellen und damit n Single-Point-of- Failures und die Ausfallwahrscheinlichkeit wäre dann n mal so groß Seite: 17

18 Wechselseitiger Ausschluss: Vergleich der Protokolle n beteiligte verteilte Prozesse Protokoll Nachrichten pro Eintritt und Austritt Verzögerung pro Eintritt in Nachrichtenzeiten Mögliche Probleme Zentralisiert 3 2 Koordinator ist Single-Point of Failure Ring-basiert 1 bis unendlich 0 bis n-1 Token kann verloren gehen, ein Prozess stürzt ab Abfrage-basiert 2(n-1) 2(n-1) Absturz irgendeines Prozesses Quelle: Angelehnt an Tanenbaum (2008) Weiterer Ansatz: Maekawa (1985): Nicht alle Prozesse, sondern nur eine Teilmenge der Prozesse wird gefragt Voting Sets Seite: 18

19 Wechselseitiger Ausschluss: Resümee Komplizierte und fehleranfällige Protokolle Alle Varianten sind nur bei sehr zuverlässigen verteilten Systemen einsetzbar Zentralisierter Ansatz ist noch am besten Bei betrieblichen Informationssystemen zusätzlich zu beachten: - Problem beim Datenzugriff (z.b. Ressourcenverwalter mit Zugriffskontrolle) ist zu lösen, wechelseitiger Auschluss alleine reicht nicht aus: Siehe Datenbankmanagementsystem Siehe Sperrkonzepte Siehe Transaktionen Seite: 19

20 Überblick 1. Wechselseitiger Ausschluss in verteilten Systemen 2. Fallbeispiel: Google s Chubby Lock Service 3. Verteilte Deadlocks und Deadlockbehandlung Seite: 20

21 Chubby Lock Service Überblick Chubby Lock Service wurde von Google als verteilter Lock Manager (DLM) entwickelt: Prof. Dr. Peter Mandl Anforderung: Wenige schreibende Clients, viele lesende Google nutzt Chubby für seinen DNS-Server, für das Google Filesystem (GFS), für die Masterauswahl im Google Filesystem,... Rollen: Client mit Chubby-Library 5 Server, auch Replicas genannt, innerhalb einer sog. Chubby- Zelle, einer davon ist der Master (je Replik eigene Kopie der Daten) Pool mit Ersatzservern Replicas nutzen das Paxos Consensus Protokoll zur Abstimmung von Schreibzugriffen und zur regelmäßigen Masterbestimmung Verteilte Systeme Seite: 21

22 Chubby Lock Service Architektur DNS-Server nslookup 5 Server eine Chubby-Zelle Ersatzserver-Pool Chubby-Client Applikation Chubby- Library Session Replica 1 Ersatzserver 1 Sehr viele Clients... (überwiegend lesend) RPC: master-location-request() open()... Replica 2 Master Ersatzserver 2... Chubby-Client Applikation Chubby- Library Callbacks Events Replica 3 Replica 4... Ersatzserver n Anfrage an Master Master-location-request geht an alle Server KeepAlive: Hauptlast Prof. Dr. Peter Mandl Verteilte Systeme Seite: 22

23 Chubby Lock Service Lock-Anfrage Chubby-Zelle: 5 leistungsstarke Server im LAN (und nicht mehr) werden von Google empfohlen Viele Tausend (90.000) Clients möglich Caching im Client Cache-Kohärenzmaßnahme: Server sendet Nachrichten-Event an alle betroffenen Clients und an die Replicas Lock-Anfrage für Dateizugriff Master-Location-Request dient zum Finden des Masters Client wendet sich über Google s RPC mit einem Master-Location- Request an alle Server Replicas geben mit No-Master-Response die Master-Adresse zurück Lesezugriffe übernimmt Master alleine, Schreibzugriffe stimmt der Master mit den anderen Servern über Paxos Consensus Protokoll ab Prof. Dr. Peter Mandl Verteilte Systeme Seite: 23

24 Chubby Lock Service Client API und Events Chubby API: Wie Filesystem-Interface open(): Öffnet Datei oder Verzeichnis liefert Handle close(): Zerstört Handle getcontentsandstat(): Liefert Inhalt und Status einer Datei setcontents(): Verändert Dateiinhalt / delete(): Datei oder Verzeichnis löschen... /dir1 Chubby Events /dir1/f1 Asynchrone Zustellung an Clients up-call, Callback-Routine stellt Client bereit Typische Events: Master abgestürzt und Fail-over durchgeführt Lock-Anforderung oder Lock-Konflikt,... Prof. Dr. Peter Mandl Verteilte Systeme Seite: 24

25 Chubby Lock Service Locks Lock-Typen werden beim Öffnen einer Datei angegeben open()-aufruf: Jeder Knoten im Filesystem kann ein Lock repräsentieren Shared Lock zum Lesen von Dateien Exclusive Lock zur Dateibearbeitung: Sperrt Datei für alle anderen Clients Lock-Konflikte werden bereinigt, indem Clients mit Events benachrichtigt werden, Locks bei Konfliktsituationen ggf. freizugeben Jeder Lock erhält eine eindeutige Sequenznummer Prof. Dr. Peter Mandl Verteilte Systeme Seite: 25

26 Chubby Lock Service Kommunikationsszenario Repliken in der Chubby-Zelle Client Cache DNS nslookup... Master R1 R2 R3 R4 master-location-request no-master-response(adr. Master) open() setcontents() Response Paxos Consensus... Seite: 26

27 Überblick 1. Wechselseitiger Ausschluss in verteilten Systemen 2. Fallbeispiel: Google s Chubby Lock Service 3. Verteilte Deadlocks und Deadlockbehandlung Seite: 27

28 Verteilte Deadlocks: Grundlegendes Voraussetzung für die Entstehung von Deadlocks sind drei notwendige und eine hinreichende Bedingung Notwendige Bedingungen sind: - Exklusiver Zugriff der Prozesse auf Betriebsmittel unter gegenseitigem Ausschluss - Halten-und-Warten: Ein Prozess darf weitere Betriebsmittel anfordern während er vorher reservierte behält - Keine Verdrängung: Ein Entzug eines Betriebsmittels ist nicht möglich, Prozesse geben diese nur freiwillig ab Wenn alle drei Bedingungen erfüllt sind, dann besteht die Gefahr eines Deadlocks Zyklische Wartesituation mehrerer Prozesse tritt als vierte Bedingung ein Deadlock Seite: 28

29 Deadlock-Erkennung Zentralisierter Ansatz Einfachste Lösung: - Es gibt nur einen zentralen Kontrollknoten, der einen globalen Wartegraphen verwaltet - Graph wird zyklisch über einen Deadlock-Detektor nach Deadlockzyklen durchsucht - Alle Anfragen nach Ressourcen gehen an den zentralen Knoten Vorteil: - Einfach zu realisieren und robuste Lösungen machbar Nachteil: - Single-Point of Failure Seite: 29

30 Deadlock-Erkennung Zentralisierter Ansatz: Optimierung Weiterhin ein zentraler Kontrollknoten, der einen globalen Wartegraphen verwaltet und einen Deadlock-Detektor enthält Alle anderen Knoten (Server, Ressourcenmanager) verwalten lokale Wartegraphen und senden diese zu bestimmten Zeiten an die Zentrale Vorteil: - Vermeidung des Single Point of Failure Nachteil: - Umständlichere Kommunikation Seite: 30

31 Deadlock-Erkennung Wartegraphen Zyklen deuten auch hier auf einen Deadlock hin P 2 Ressource R i wird gehalten von Prozess P j R i P j P 1 R 2 Zyklus R 3 Host 2 R i P j Prozess Pj wartet auf Resource R i R 1 Host 1 P 3 P 2 Zyklus: P 2 P 3 P 3 R 4 Host 3 Seite: 31

32 Deadlock-Erkennung Phantom-Deadlocks (1) Als Deadlock erkannt, aber eigentlich kein Deadlock Kann bei verteilter Deadlock-Erkennung vorkommen Dies hängt mit der Übertragungszeit zusammen Beispiel: - Ein Prozess blockiert (sperrt) in einem Knoten eine Ressource - Lokaler Wartegraph wird an andere Knoten übertragen - Andere Knoten erkennen einen Deadlock - Ressource aber mittlerweile schon freigegeben Phantom-Deadlock Phantoms bei Two-Phase-Locking nicht möglich siehe Transaktionskonzepte Seite: 32

33 Deadlock-Erkennung Phantom-Deadlocks (2) Beispiel: P 1 belegt R 1 und verursacht Phantom-Deadlock P 1 RM 1 RM 2 RM 3 R 1 sperren Sperre erhalten R 1 freigeben Lokaler Wartegraph x Deadlock erkannt x Deadlock erkannt RM x = Ressourcen-/Sperrmanager Seite: 33

34 Deadlock-Erkennung Edge-Chasing (1) Wartegraph wird auf alle Knoten, die Ressourcen verwalten, verteilt Grundlegende Idee: - Alle Knoten verwalten einen Teil des Wartegraphen - Ressourcenverwalter (Server) versenden bei Erkennen möglicher Blockadesituationen sog. Probe-Nachrichten an andere Server entlang der Kanten des Wartegraphen, um so Zyklen aufzudecken - Server schicken die Probe-Nachricht weiter, wenn sie auch blockiert sind - Ein Server erkennt einen Deadlock, wenn eine von ihm initiierte Probe- Nachricht wieder zu ihm zurückkommt (Zyklus) - Der Server löst schließlich den Deadlock auf Abbruch Auch Anwendung für die Deadlockerkennung in verteilten Transaktionen Seite: 34

35 Deadlock-Erkennung Resümee Zentrale Lock-Verwaltung erleichtert Deadlockerkennung Chubby Lock Service mit einer replizierten Lockverwaltung erleichtert Deadlockerkennung auch Dezentrale Deadlockerkennung vermeidet zwar einen möglichen Single Point-of Failure ist aber wesentlich schwieriger zu implementieren Chubby ist aber ohnehin durch Replikation abgesichert Seite: 35

36 Das war s Wechselseitiger Ausschluss in verteilten Systemen Fallbeispiel: Google s Chubby Lock Service Verteilte Deadlocks und Deadlockbehandlung Seite: 36