Verteilte Systeme. Fehlertoleranz. Prof. Dr. Oliver Haase

Transkript

1 Verteilte Systeme Fehlertoleranz Prof. Dr. Oliver Haase 1

2 Überblick Einführung Belastbarkeit von Prozessen Zuverlässige Client-Server-Kommunikation Zuverlässige Gruppenkommunikation 2

3 Anforderungen an verteilte Systeme Verfügbarkeit (Availability) unmittelbare Benutzbarkeit eines Systems bezieht sich auf einen bestimmten Zeitpunkt Zuverlässigkeit (Reliability) das System läuft fortlaufend ausfallfrei bezieht sich auf ein Zeitintervall 3

4 Einschub: Verfügbarkeit vs Zuverlässigkeit Beispiel 1: System, das jede Stunde für 1ms ausfällt Verfügbarkeit: - 99,99997% (sehr hoch) Zuverlässigkeit: - eher gering Beispiel 2: System, das nie ausfällt, aber im Jahr zwei Wochen für Wartungsarbeiten heruntergefahren wird Verfügbarkeit: - 96,2% (eher niedrig) Zuverlässigkeit: - sehr hoch 4

5 Anforderungen an verteilte Systeme Funktionssicherheit (Safety) es passiert nichts Schlimmes, wenn ein System vorübergehend nicht korrekt arbeitet Wartbarkeit (Maintainability) wie leicht kann ein ausgefallenes System repariert werden? Ein System, das die obigen Anforderungen erfüllt, wird als verlässlich (dependable) bezeichnet. 5

6 Störungen Man sagt, Systeme fallen aus, wenn sie ihre Zusagen nicht mehr einhalten können. Die Ursache dafür wird als Störung (fault) bezeichnet. Beim Aufbau verlässlicher Systeme geht es um die Kontrolle der Störungen, insbesondere um die Möglichkeit, solche Fehler zu tolerieren. Arten von Störungen: Vorübergehend (transient): einmaliger Vorfall Wiederkehrend: unberechenbares Wiederauftreten Permanent: Fehler bleibt bestehen, bis die fehlerhafte Komponente ersetzt wird 6

7 Fehlermodelle Zweck: Klassifikation von Fehlern, um besser darauf reagieren zu können Angabe der Fehlertoleranz von Programmen mit Bezug auf die Fehlerklassen aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen] 7

8 Maskierung von Fehlern Beste Vorgehensweise: Verbergen der Fehler vor anderen Komponenten (Maskierung) Wird erreicht durch Redundanz Informationsredundanz: - Verwendung zusätzlicher Bits, um den möglichen Ausfall anderer Bits abzufangen - Beispiel: Hamming Code für Forward Error Correction Zeitliche Redundanz: - Wiederholung von Aktionen - Beispiel: Transaktionen zurückgesetzte Aktionen werden wiederholt 8

9 Maskierung von Fehlern Technische Redundanz - Zusätzliche Hardware oder Software (Prozesse) - Beispiele: Biologie: zwei Augen, zwei Ohren, zwei Lungenflügel Luftfahrt: vier Triebwerke, doppelte Steuerkreise Sport: mehrere Schiedsrichter technische Schaltungen: 9

10 Belastbarkeit von Prozessen Generelles Vorgehen Replikation von Prozessen, die dieselbe Aufgabe erfüllen Zusammenfassung in Prozessgruppen Ergebnis: fehlertolerante Gruppe von Prozessen Wird eine Nachricht an die Gruppe geschickt, bekommt jeder Prozess die Nachricht Wir betrachten Organisation der Gruppen Fehlermaskierung und Replikation Erzielung von Übereinstimmung in fehlerhaften Systemen 10

11 Gruppenorganisation Prozessgruppen sind dynamisch können erzeugt und gelöscht werden Prozesse können ein- und austreten Prozesse können Mitglied mehrerer Gruppen sein Zweck des Einsatzes von Gruppen: Abstraktion von den Einzelprozessen, Darstellung gegenüber der Außenwelt als eine Einheit Gruppenstruktur strukturlos (flach), oder hierarchisch (ein Koordinator) 11

12 Gruppenorganisation aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen] kein Single Point of Failure Jede Entscheidung erfordert Abstimmung schneller im Normalbetrieb Problem bei Ausfall des Koordinators 12

13 Maskierung von Fehlern Anwendung der bereits bekannten Replikationsstrategien Urbildbasiert (Primary-based) - Koordinator, der alle Write-Operationen koordiniert - passt gut zu hierarchischen Prozessgruppen - Wenn der Koordinator abstürzt, wählen die übrigen Prozesse einen neuen Aktive Replikation /Quorumbasierte Protokolle: - passt gut zu flachen Gruppen 13

14 Maskierung von Fehlern Wichtige Frage: wieviel Replikation ist nötig? Vereinfachung der Betrachtung: flache Prozessgruppen k-fehlertoleranz: Gleichzeitiger Ausfall von k Prozessen kann maskiert werden Anzahl benötigter Prozesse hängt stark vom Fehlerverhalten ab: Dienstausfälle: - (k+1) Prozesse Byzantinische Fehler (fehlerhafter Dienst): - (2k +1) Prozesse Kann man aber so genau sagen, dass maximal k Fehler auftreten? statistische Analysen 14

15 Übereinstimmung in fehlerhaften Systemen Problem: wie kommt man zu einer Übereinstimmung über eine durchzuführende Aktion? Ziel verteilter Einigungsalgorithmen alle nicht fehlerhaften Prozesse werden sich in begrenzter Zeit über einen bestimmten Aspekt einig Unterschiedliche Eigenschaften von Systemen erfordern unterschiedliche Lösungen 15

16 Unterschiedliche Fälle Synchrone und asynchrone Systeme Synchrone Systeme gehen zusammen jeweils immer einen Schritt weiter Kommunikationsverzögerung ist begrenzt oder nicht Nachrichtenauslieferung in korrekter Reihenfolge oder nicht Nachrichtenübertragung per Unicast oder Multicast 16

17 Behandlung der Fälle Nur in folgenden Fällen kann überhaupt Übereinstimmung erzielt werden: aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen] Meisten vert. Systeme sind asynchron, verwenden Unicast Reihenfolgetreue zwingend, z.b. TCP/IP 17

18 Byzantinische Generäle Dient der Veranschaulichung des Problems, zu einer Übereinstimmung in einem fehlerhaften verteilten System zu kommen In den diversen Kriegen der byzantinischen Zeit (5. bis 15. Jahrhundert) ging es oft darum, Übereinstimmung über die Truppenstärken verschiedener Armeen zu erreichen. Dies unter dem Einfluss verräterischer Generäle etc. Leslie Lamport schlug 1982 eine Lösung für das Problem vor. 18

19 Problemstellung & Lösungsansatz Synchrone Generäle (Prozesse), Unicast, Reihenfolge- Erhaltung, begrenzte Kommunikationsverzögerung N Generäle, davon höchstens k fehlerhaft Generäle (Prozesse) sollen Einigung erzielen. Jeder General i sendet seine Truppenstärke vi an alle anderen Generäle. Ziel: jeder General konstruiert einen Vektor V der Länge N, so dass V[i]= vi, falls i nicht fehlerhaft ist. 19

20 Byzantinische Generäle: Beispiel Szenario: n=4, G3 lügt 1) alle Generäle melden ihre Truppenstärke allen anderen (Bild a) 2) jeder General bildet Vektor aller gemeldeten Werte (Bild b) 3) alle Generäle tauschen Vektoren miteinander aus, G3 lügt erneut (Ergebnis in Bild c) 4) 1, 2 und 4 erzielen Einigung in Form von (1, 2, undefined, 4) 20

21 Zuverlässiger RPC/RMI RPC/RMI abstrahiert von einer Kommunikationsbeziehung, aber dahinter steht immer Kommunikation über ein Netz Wenn sowohl Kanal als auch Sende-/Empfangprozesse perfekt funktionieren, ist RPC/RMI zuverlässig. Mögliche Probleme (Fehlerklassen): 1) Client findet Server nicht 2) Anfrage geht verloren 3) Server stürzt nach Erhalt der Anfrage ab 4) Antwort geht verloren 5) Client stürzt nach Senden der Anfrage ab 21

22 1) Client findet Server nicht Ursachen: Server down unterschiedliche Versionen von Stub und Skeleton Lösung: Exceptions auf Client-Seite Verlust von Transparenz nicht jede Sprache unterstützt Exceptions 22

23 2) Anfrage geht verloren einfachstes Problem Timer starten beim Abschicken der Nachricht Nachricht wird erneut geschickt, wenn der Timer vor Eintreffen einer Antwort abläuft ist die Nachricht tatsächlich verloren gegangen, merkt der Server keinen Unterschied Erhält der Server die Nachricht doppelt, dann muss er dies erkennen siehe 4) Antwort geht verloren u. U. bereits in Transportprotokoll enthalten (z.b. in TCP, nicht aber in UDP) 23

24 3) Server stürzt ab Der Server kann abstürzen, nachdem (b) oder bevor (c) er die Operation ausgeführt hat. Beide Fälle müssen unterschiedlich behandelt werden: (b) Client muss informiert werden (z.b. Exception bekommen) (c) Nachricht kann erneut (an einen anderen Server) geschickt werden Problem: Client kann (b) und (c) nicht unterscheiden 24

25 3) Server stürzt ab Lösung: drei verschiedene Philosophien 1) Mindestens-Einmal-Semantik: (at least once) - führe die Operation so oft aus, bis sie erfolgreich war, d.h. bis Antwort eingetroffen ist warten auf Server-Reboot oder anderen Server verwenden - Operation wird mindestens einmal ausgeführt 2) Höchstens-Einmal-Semantik (at most once): - Sofortige Aufgabe, Fehlermeldung - RPC wurde höchstens einmal ausgeführt, evtl. gar nicht 25

26 3) Server stürzt ab 3) keine Garantie - Anfrage kann gar nicht, einmal oder viele Male ausgeführt worden sein - Client wird alleine gelassen - leicht zu implementieren Wünschenswerte Genau-Einmal-Semantik nicht realisierbar! 26

27 4) Antwort geht verloren Problem: für den Client nicht zu unterscheiden von 3) Server-Crash Kann eine Operation einfach wiederholt werden, wenn sie schon ausgeführt wurde? Idempotente Operation: ein Aufruf ändert nichts am Zustand, kann beliebig oft aufgerufen werden Versuche, möglichst nur idempotente Prozeduren zu verwenden (geht nicht immer) Mögliche Lösungen: zustandsbehaftete Server, die sich Sequenznummern von Client-Requests merken Identifikation von Wiederholungsanfragen (z.b. Bit in Header) 27

28 5) Client-Crash Client stürzt ab, bevor Server Antwort sendet die entstehenden elternlosen Antworten können zu Problemen führen Ressourcenverschwendung Konfusion bei Neustart des Clients und anschließendem Empfang der Antwort Mögliche Lösungen Extermination: merke Dir alle angestossenen Operationen in permanentem Speicher, lösche dann nach Neustart noch eintreffende Antworten 28

29 5) Client-Crash Reinkarnation: Verwendung von Epochen Lebenszeit des Client. - Wenn Client neu startet, beginnt neue Epoche, - Client sendet Broadcast mit neuer Epoche an alle Computer - diese löschen anhängige alte Requests - Client lösche Antworten von überlebenden alten Requests 29

30 Zuverlässige Gruppenkommunikation Multicast ist eine effiziente Umsetzung für Gruppenkommunikation, insbesondere bei vielen Prozessen. Jedoch selten implementiert Zuverlässig bedeutet, dass alle Prozesse einer Gruppe jede gesendete Nachricht bekommen. Komplizierter wird es bei Prozessausfall oder dynamischem Join während der Kommunikation. 30

31 Schwacher zuverlässiger Multicast Übereinkunft über Gruppenmitgliedschaft besteht, kein Fehlschlagen, kein dynamisches Beitreten, aber unzuverlässiger Kanal Lösung: Problem: Skalierbarkeit, ACK Implosion 31

32 Lösungen NACKs ( Verpasst 24 ) statt ACKs Meistens besser als ACKs keine Garantie gegen Implosion Nachrichten müssen theoretisch endlos im Sendepuffer gehalten werden Diverse Vorschläge für skalierbares zuverlässiges Multicast Nicht-hierarchische Rückkopplung - z.b. Scalable Reliable Multicast (SRM): reduziere die Zahl der Antworten durch Rücksenden von NACKs über Multicast, andere unterdrücken dann ihr NACK Hierarchische Rückkopplung: Aggregation der NACKs entlang von Multicastbäumen, besonders geeignet für große Multicast-Gruppen 32

33 Atomarer Multicast Schwierigerer Fall: zuverlässiger MC bei Prozessausfällen entweder alle bekommen die Nachricht oder keiner in derselben Reihenfolge dies wird als atomarer Multicast bezeichnet Wichtig z.b. bei aktiver Replikation über Multicast, in der jedes Replikat von einem Prozess verwaltet wird Wenn ein Prozess abstürzt, könnten bei Nicht-Atomizität Inkonsistenzen entstehen. 33

34 Atomarer Multicast: Idee Eine Multicast-Nachricht m wird einer Liste von Prozessen zugeordnet, an die sie ausgeliefert werden soll. Sender hat damit eine Gruppensicht Sicht auf die Menge die Prozesse, die in der Empfängergruppe sind an dem Zeitpunkt, an dem m gesendet wird. Jeder Prozess aus der Menge hat dieselbe Sicht auf alle Nachrichten, d.h. eine Nachricht wird an alle oder an keinen ausgeliefert. 34

35 View Change Was passiert, wenn ein Prozess während der Multicasts der Gruppe G beitritt oder sie verlässt? Dies wird durch eine weitere Multicast-Nachricht vc bekanntgegeben. Es muss dann garantiert werden, dass entweder alle Prozesse in G zuerst m bekommen, bevor vc an einen der Prozesse ausgeliefert wird, oder m gar nicht ausgeliefert wird 35

36 Virtuell Gleichzeitiger MC Strengere Form des zuverlässigen Multicast: Nachricht wird an alle nicht-fehlerhaften Prozesse in G ausgeliefert Wenn der Sender von m während des MC abstürzt, kann die Nachricht an alle Empfänger ausgeliefert werden oder von allen ignoriert werden (wenn einige Empfänger die Nachricht vor dem Absturz nicht bekommen haben) Virtuelle Gleichzeitigkeit: Alle Multicasts finden zwischen Änderungen der Sicht statt. Anders gesagt: kein Multicast kann die Grenze einer Sichtänderung überschreiten. Implementierung ist schwierig Beispielsystem: Isis 36

37 Virtuell Gleichzeitiger MC: Prinzip 37

38 Zusammenfassung Fehlertoleranz ist ein wichtiges Konzept in verteilten Systemen Es gibt viel mehr Fehlerquellen als in zentralisierten Systemen Das System funktioniert möglicherweise trotz teilweiser Fehler. Wir haben Lösungen betrachtet für die Koordination von redundanten Prozessen und für Fehlerfälle beim Remote Procedure Call. 38