Verteilte Systeme

Prof. Dr. Oliver Haase

Verteilte Systeme

Fehlertoleranz

Überblick

‣

^Einführung

‣

Belastbarkeit von Prozessen

‣

Zuverlässige Client-Server-Kommunikation

‣

Zuverlässige Gruppenkommunikation

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

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}

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.

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

Fehlermodelle

‣

^Zweck:

•

Klassifikation von Fehlern, um besser darauf reagieren zu können

•

Angabe der

Fehlertoleranz von Programmen mit Bezug auf die

Fehlerklassen

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

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:

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

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)

Gruppenorganisation

‣

kein Single Point of Failure

‣

Jede Entscheidung erfordert Abstimmung

‣

schneller im Normalbetrieb

‣

Problem bei Ausfall des Koordinators

aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen]

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

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

Ü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

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

Behandlung der Fälle

‣

Nur in folgenden Fällen kann überhaupt Übereinstimmung erzielt werden:

aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen]

‣

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.

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.

Byzantinische Generäle: Beispiel

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)

Szenario: n=4, G3 lügt

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

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

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)

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

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

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!

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

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

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

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.

Schwacher zuverlässiger Multicast

‣

Übereinkunft über Gruppenmitgliedschaft besteht, kein Fehlschlagen, kein dynamisches Beitreten, aber

unzuverlässiger Kanal

‣

^Lösung:

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

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.

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.

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

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

Virtuell Gleichzeitiger MC: Prinzip

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.