Sicherheit (Safety): Fehlerfall hat keinen katastrophalen Effekt - Menschenleben nicht gefährdet, - Datenbestand nicht zerstört.

Transkript

1 8. Fehlertoleranz 8.1 Terminologie Umfassenderer Begriff: Verlässlichkeit. Verfügbarkeit (Availability): Wahrscheinlichkeit für das korrekte Arbeiten des Systems zu gegebenem Zeitpunkt. Zuverlässigkeit (Reliability): Zeitintervall für korrektes Systemverhalten; Meantime between failure (MTBF). Unterschied zwischen Verfügbarkeit und Zuverlässigkeit: - Beispiel: System fällt alle Stunde für eine Millisekunde aus: Verfügbarkeit von 99,9999%, aber MTBF von knapp 1h. - Beispiel: System fällt alle Jahre für einen Monat aus: Verfügbarkeit von 91,67%, aber MTBF von einem Jahr. Sicherheit (Safety): Fehlerfall hat keinen katastrophalen Effekt - Menschenleben nicht gefährdet, - Datenbestand nicht zerstört. Wartbarkeit (Maintainability): Fehlerfall kann leicht repariert werden. Verlässliche Systeme müssen fehlertolerant sein. 180 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

2 8.2 Fehlerbegriff Ausfall (failure): System verhält sich nicht spezifikationskonform. Eingetretener Fehler (error): Teil eines unerlaubten Systemzustands, der zu einem Ausfall führen kann (falls nicht entsprechend behandelt). Fehlerursache (fault): Ursache für einen eingetretenen Fehler. Beispiel: - ein Bit bei Datenübertragung kippt um: z.b. DNS-Anfrage zur Auflösung einer IP-Adresse (Fault), - das führt zu falsch interpretierten Empfangsdaten: z.b. falsche IP-Adresse (Error), - das führt zu Unfähigkeit zur Kommunikation: z.b. Anwendungskomponte kann nicht erreicht werden (Failure). Problem: - Failure nicht immer leicht beobachtbar: z.b. falsche Anwendungskomponente wird erreicht, - Error hingegen beobachtbar: setzt globale Sicht auf Zustand voraus. 181 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

3 Zeitdauer von Faults Transiente Faults: - einmaliges Auftreten, - mehrfache Versuche führen in der Regel zum Ziel, - z.b. Kommunikationsfehler durch Vogel in Richtfunkstrecke. Intermittierende Faults: - sporadisches Auftreten, - z.b. Wackelkontakt. Permanente Faults: - ständiges Auftreten, - z.b. Speicherzelle durchgebrannt. 182 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

4 8.3 Fehlermodelle Rechner- bzw. Programmabsturz (Crash Failure): - z.b. Server stürzt ab und beantwortet keine Anfragen mehr Fail-Stop-Verhalten, - einfaches und gutartiges Fehlermodell, - Problem: Absturz und langsames Antworten schlecht unterscheidbar. Dienstverweigerung (Omission Failure): - z.b. Server antwortet nicht auf Anfragen (z.b. durch Nachrichtenverlust), - gutartiges Fehlermodell. Zeitfehler (Timing Failure): - z.b. Server antwortet nicht rechtzeitig. Fehlerhafte Antworten (Response Failure): - z.b. Server antwortet nicht richtig, - falsche Antwortdaten und/oder falsche Serverzustände, - schwieriges Fehlermodell. Byzantinische Fehler (Byzantine Failure): - System kann sich beliebig falsch verhalten, - z.b. Server schickt gelegentlich falsche Antworten und erreicht gelegentlich falsche Systemzustände, - sehr schwieriges Fehlermodell. 183 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

5 8.4 Fehlermaskierung Ziel: Verbergen der Fehler vor anderen Komponenten. Fehlererkennung (Detection): Identifikation der fehlerhaften Komponenten. Schadensermittlung (Damage Confinement): Identifikation der fehlerhaften Systemzustände. Fehlererholung (Recovery): - Berichtigung fehlerhafter Zustände, - Weiterarbeiten mit redundanten Komponenten oder Daten. Einsatz von Redundanz (Johnson, 1995): - Informationsredundanz: o zusätzliche Daten zur Fehlererkennung und erholung. o z.b. spezielle Codes, Checksummen,... - Zeitredundanz: o Wiederholung fehlerhafter oder unbeantworteter Anfragen/Vorgänge. o z.b. RPC-Implementierung. - physikalische Redundanz o Einsatz von mehreren Rechensystemen und Netzwerken, o Verwenden von redundanten Daten und Diensten (Replikation). 184 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6 8.5 Physikalische Redundanz Beispiel: Dreifach modulare Redundanz (Triple Modular Redundancy, TMR) mit drei Eingängen und einem Ausgang: - falls zwei oder drei Eingänge gleich dies ist die Ausgabe, - alle drei Eingänge unterschiedlich: Ausgabe ist undefiniert, - in jeder Stufe kann der Fehler eines Elementes maskiert werden, - allgemein gilt: N Modular Redundancy (N>=3) kann bis zu N-1/2 Fehler maskieren (falls Eingänge unabh.). 185 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

7 8.6 Übereinstimmung in fehlerhaften Systemen Problem: wie kommt man zu einer Übereinstimmung über eine durchzuführende Aktion im Fall: - perfekte Prozesse, aber fehlerhafte Kommunikationskanäle (2-Armeen Problem), - fehlerhafte Prozesse, aber perfekte Kommunikation (byzantinische Gernäle). 2-Armeen-Problem: Blau will rot angreifen, kann aber nur gemeinsam gewinnen (Überzahl). Notwendig: Abstimmung über Zeitpunkt des Angriffs. - Bote muss durch das rote Lager, kann gefangen werden unzuverlässige Übertragung, - Wenn Bote bei B ankommt schickt dieser ihn zu A mit Bestätigung zurück, - Wenn Bote wieder bei A schickt dieser ihn zu B zurück um Bestätigung zu bestätigen, usw. Man kann zeigen, dass die beiden Prozesse nicht zu einer Übereinstimmung kommen können. 186 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

8 Die byzantinischen Generäle: Einigungsproblem nach Lamport, Shostak und Pease, Einigung, falls es bei m fehlerhaften Prozessen mind. 2m + 1 korrekte Proz. gibt, - es müssen mind. 2/3 aller Prozesse korrekt arbeiten und #Prozesse > 3. Szenario: - n Generäle (n>3), m davon sind Verräter, - Ein Anführer gibt einen Befehl b {0,1} (z.b. Angriff), - Die anderen Generäle sollen den Befehl ausführen (auch der Anführer kann Verräter sein), - Frage: Einigung auf angreifen (1) oder abwarten (0)? (Anführer ändert Entscheidung nicht). Algorithmus: - Schritt-1: Anführer sendet Befehl an alle Generäle, - Schritt-2: Jeder General teilt allen anderen mit, welchen Befehl er vom Anführer erhalten hat, - Schritt-3: Jeder General trifft aus den erhaltenen Werten eine Mehrheitsentscheidung. - Bem.: Verräter versucht Einigung zu verhindern. (1,1,1,0) A B C D 1 1 (1,1,1,0) Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

9 8.7 Zuverlässige Gruppenkommunikation Motivation: Replikation benötigt zuverlässige Multicast-Dienste. Ziel: Jede Nachricht soll alle Mitglieder einer Gruppe erreichen. Probleme: Nachrichtenverlust, Prozess tritt Gruppe bei / stürzt ab. Zuverlässige Punkt-zu-Punkt Verbindung durch TCP vorhanden. N TCP-Verbindungen sind für kleine Gruppen praktikabel. Andernfalls ist UDP Multicast empfohlen. Einfaches Szenario: Prozess sendet an fest Gruppe: - jede Nachricht hat eine Sequenznummer, - Empfänger schicken ACK bzw. Fehler, falls eine Nachricht mit zu grosser Seq.nr. empfangen wurde Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

10 8.7.1 Scalable Reliable Multicast (SRM) Problem: Skalierbarkeit Sender wird von ACKs überschwemmt. Alternative: Nur negative Bestätigungen (NACKs) schicken. - Aber wie lange muss ein Sender eine Nachricht aufbewahren? - Nur für gewisses Zeitintervall möglich, sonst läuft Sendepuffer über. - Damit ist nicht sichergestellt, dass jede Nachricht beim Empfänger ankommt. Lösung-1: nicht-hierarchische Feedbacksteuerung - NACKs werden an die gesamte Gruppe gesendet, - Prozess erkennt NACK von einem anderen Proz. und unterdrückt eigenes NACK. - Zur Entzerrung der negativen Bestätigungen zufällige Verzögerung einfügen. - Nachteil: Proz., die Nachricht erhalten haben, werden durch NACKs unnötig unterbrochen. - Bem.: Im WAN evt. Retransmission von einem Empfänger günstiger, als vom Sender. 189 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

11 Lösung-2: hierarchische Feedbacksteuerung - Annahme: Nur ein Prozess sendet an die große Gruppe, - Gruppe ist baumartig in Untergruppen aufgeteilt, - Pro Untergruppe ein lokaler Koordinator C: o leitet Nachrichten an seine Unterknoten, o behandelt Retransmissions. - Problem: dynamischer Aufbau des Baums, o z.b. jeder Router als Koordinator. 190 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

12 8.7.2 Atomarer Multicast Nachrichten an alle Gruppenmitglieder i.d.r. in der gleichen Reihenfolge ausliefern oder an kein Mitglied (z.b. für replizierte DB). Problem: Knoten stürzt ab oder kommt neu hinzu. Lösung: Virtuelle Synchronität (Birman, 1991): - group view: Prozessliste des Senders, wenn er die Nachricht schickt, - view changes: Gruppe ändert sich Nachrichten nur an alte oder neue View, - Multicasts nicht über View-Grenzen hinweg (ähnl. Synchronisierungsvariable). 191 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

13 Wichtig: Empfang einer Nachricht und Auslieferung an die Anwendung unterscheiden zunächst Puffern! - Nachricht ist stable, wenn sie von allen Rechnern in der selben View empfangen wurde, - nur stable Nachrichten werden an die Anwendung ausgeliefert, Virtuelle Synchronität sichert Atomarität, aber Reihenfolge offen: - nicht sortiert: beliebige Auslieferung, - FIFO-sortiert: Sendereihenfolge eines Prozesses wird eingehalten, - kausal sortiert: kausale Abhängigkeiten bleiben erhalten (z.b. per Vektorzeit), - vollständig sortiert: alle Msgs. werden in gleicher Reihenfolge empf. (z.b. per Lamportzeit). Atomarer Multicast: virtuell synchroner zuverlässiger Multicast mit i.d.r. vollständig sortierter Auslieferung. Bem.: Prozessausfälle per Heartbeat Nachrichten erkennbar - Knoten prüfen periodisch, ob ein anderer noch antwortet, - Problem: wie gross muss der Timeout gewählt werden? - falls ein Proz. unabsichtlich aus der Gruppe entfernt wird, so muss er der Gruppe erneut beitreten. 192 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

14 Implementierung der virtuellen Synchronität: Problem: Falls Nachricht m in View v gesendet wurde, so muss m von allen nicht-fehlerhaften Prozessen in v empfangen werden, also bevor eine View-Anpassung stattfindet. Problem: Sender kann mitten in einem Multicast abstürzen. Lösung: Prozesse, die die Nachricht m noch nicht erhalten haben, sollten m von einem anderen Prozess bekommen. Ablauf: Änderung der View wird per Multicast bekannt gemacht: - Durch den ankommenden/abgehenden Knoten oder dem, der einen Fehler erkannt hat, - Bei Empfang von view changes sendet jeder Knoten seine unstable Nachrichten per Multicast an die neue Gruppe damit werden diese Nachrichten stable. - Sind alle unstable -Nachrichten versendet, so schickt jeder Prozess abschliessend eine flush -Nachricht. - View-Änderung ist abgeschlossen, wenn jeder Prozess von allen Mitgliedern die flush -Nachricht empfangen hat. Bem.: Falls Sender abstürzt erhalten die Empfänger keine Flush- Nachricht und verwerfen die unstable Nachrichten. 193 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

15 Beispiel: Sichtänderung an Sender (Prozess 4) a) Prozess 1 bemerkt, dass Prozess 5 abgestürzt ist und sendet eine view changes -Nachricht, b) Prozess 4 sendet allen seine unstable -Nachrichten, gefolgt von einer flush -Nachricht, c) Proz. 4 installiert neue View, wenn er von jedem Mitglied flush -Msg. empfangen hat. a ) P2 P3 b ) P2 unstable message P3 P1 view changes P4 P1 P4 flush message P5 P5 c ) P2 P3 P1 P4 P5 194 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

16 8.8 Fehlertoleranter RPC RPC soll auch bei Fehlern lokalem Aufruf weitestgehend entsprechen. Auftragsbasierte Komm.: Sender schickt Auftrag und erwartet Ergebnis. Mögliche Fehler: - Zielknoten oder -rechner wird nicht erreicht: Adressierungsproblem, Netzwerkfehler, - beteiligter Rechner oder Prozess ist abgestürzt: kann zu jedem Zeitpunkt passieren, sogar mitten in der Nachricht ; Folge: o Klient wartet z.b. endlos, falls er einen blockierenden Aufruf verwendet hat und der Server ist abgestürzt. o verwaiste Aufrufbearbeitungen (Orphans), wenn der Server bereits begonnen hat, einen Auftrag zu bearbeiten, der zugehörige Klient jedoch vor Ergebnisabnahme abgestürzt ist. - angesprochener Server ist nicht mehr vorhanden, - die gewünschte Servicefunktion wird nicht mehr angeboten. RPC Fehlersemantiken Maybe: - keine Fehlerbehandlungsmaßnahmen, - Aufruf wird gar nicht oder höchstens einmal durchgeführt, - Im Fehlerfall hat man keine Hinweise, ob Aufruf tatsächlich ausgeführt wurde oder nicht (u.u. ausreichend für Auskunftsdienste). 195 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

17 At-Least-Once: - Aufruf wird mindestens einmal ausgeführt, aber evt. auch mehrmals (unsichtbar für Klienten), - Fehlerbehandlung: nach Timeout wird der Auftrag bis zum Erfolg wiederholt, - Problem: idempotenten Operationen notwendig, d.h. derem mehrfache Ausführung das Ergebnis nicht verändert (z.b. Lesen einer Datei). At-Most-Once: - Aufruf wird höchstens einmal ausgeführt oder evt. gar nicht, - Fehlerbehandlung: Wiederholen des Auftrags (Server filtert Duplikate), - Nach N Versuchen oder einem Timeout wird abgebrochen und kein Ergebnis mehr erwartet. - verwendet für RPC in Corba & DCOM, Java RMI. Exactly-Once: - Aufruf wird genau einmal durchgeführt, - Fehlerbehandlung: bei Absturz Wiederanlauf von Komponenten, - persistente Datenhaltung und verteilte Transaktionen sind notwendig, - Exactly-Once-Semantik ist besonders komfortabel aber sehr aufwendig für Anwendungen mit hohen Sicherheitsanforderungen sinnvoll. 196 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

18 Fehlerszenerien: Klient erhält keine Antwort vom Server Annahme: Nachrichten mit Sequenznummer. Auftragsnachricht ging verloren: - Lösung: Auftrag wiederholen (auch in den folgenden Fällen sinnvoll). - Evt. empfängt Server die Nachricht doppelt. Antwort des Servers ging verloren oder ist noch nicht angekommen: - Neben der Auftragswiederholung kann man auf Serverseite die Antwort-Nachrichten zwischenspeichern und bei erneuter Anforderung nochmals, ohne wiederholte Berechnung schicken. Der Server ist gerade vor dem Versenden der Antwort abgestürzt: - Problem: Klient kann nicht entscheiden, ob Nachrichten bearbeitet wurde oder nicht, - Entweder bis Antwort (nach Reboot) kommt: erneut senden (at-least-once-semantik), - Oder direkt Fehler liefern (at-most-once-semantik). 197 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

19 Fehlerszenerien: Niemand wartet auf das Ergebnis der Berechnung Tritt ein, falls der Klient Aufruf absetzt und dann abstürzt. Derartige Berechnungen nennt man Waisen. Problem: Waisen können Ressourcen und Sperren belegen. Lösungen: 1) vor RPC: Info auf Platte sichern nach Reboot anhand der Info Waisen löschen, 2) nach Reboot: Broadcast an alle Server: Berechnungen neu beginnen Server löscht alle Berechnungen für diesen Klient, 3) wie 2., aber Server versucht Eigentümer zu finden, 4) alternativ: jeder RPC dauert max. Zeit und danach Abbau der Verbindung. 198 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

20 8.9 Fehlererholung (Recovery) Allgemeines Ziel: Einen fehlerhaften Zustand in einen korrekten Zustand überführen. Vermeiden, dass das System auf den initialen Zustand zurückfällt. Rückwärtsbehebung (Backward Recovery): - periodisch Zustände / Sicherungspunkte (Checkpoints) aufzeichnen, - nach Fehler auf alten Zustand zurücksetzen u. von dort aus fortsetzen, - Ressourcen müssen evt. zurückgefordert werden (z.b. Sperren), - partiell ausgeführte Operationen evt. zurückgesetzen (Konsistenz). Vorwärtsbehebung (Forward Recovery): - Versetzt System in konsistenten Zustand, ohne auf Zustandsinformation zurückzugreifen, die in der Vergangenheit zum Zweck der Fehlertoleranz abgespeichert wurde. - Problem: für jede Fehlersituation wird individuelle Aktion benötigt. Beispiel: Nachricht kommt defekt beim Empfänger an - Backward Recovery: Retransmission beim Sender anfordern, o gut, da unabhängig von der speziellen Fehlersituation, o aber Checkpointing und Recovery aufwendig. - Forward Recovery: Redundanz in Nachricht erlaubt Fehlerkorrektur, o Forward Error Correction (FEC), z.b. Parity, Hamming Code, Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

21 8.9.2 Zustandssicherung & Rücksetzbarkeit Zustandssicherung: - es genügt nicht, nur den Speicher der Anwendung zu sichern, - wichtig sind auch Betriebssystemzustände (z.b. Strukturen im Kern), - sowie Gerätezustände (z.b. Dateiinhalt, Kommunikationskanäle?,...), - Bedarf einer Unterstützung durch das Betriebssystem oder Einschränkungen. Stable Storage : - Sicherungspunkte i.d.r. in persistentem Speicher (z.b. Festplatte, RAID-Disk) sichern, - Schreiben auf Disk ist vergleichsweise langsam: o inkrementelle Datensicherung oder Kompression (CPU-Aufwand), o verteilt (viele Disks) oder asynchron Schreiben (zuerst Puffern). - Alternativ: Reliable DSM (RDSM) oder Replikate allgemein o Seiten verzögert schreiben (Copy-On-Write nutzen), o oder Seite nur im RAM sichern (bei Änderung nach Checkpoint). - Bem.: Diskspeicher muss irgendwann reorganisiert werden: o Sicherungspunkte müssen gelöscht werden, o aber auch alte Checkpoints notwendig, da evt. unentdeckte Fehler. 200 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

22 Rücksetzbarkeit: - Speicher einfach Schattenkopien, - Logging: Änderungen werden in Logdatei protokolliert o Name des Datums (Identifikation), o Alter Zustand (Undo), o Neuer Zustand (Redo). - eine Hardware-Ausgabe ist u.u. nicht rücksetzbar,... - bereits gesendete Nachricht kann nicht zurückgefordert werden,... Weitere Entwurfsfragen: - pessimistisch vs. optimistisch: Fehler häufig/selten Optimierung von Recovery / Checkpointing Overhead. - unabhängig vs. koordiniert: Prozesse sichern Checkpoints in koordinierter Weise oder unabhängig voneinander. - synchron vs. asynchron: System wird für den Sicherungspunkt angehalten oder dieser erfolgt nebenläufig. 201 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

23 8.9.3 Konsistente Sicherungspunkte Vermeidung von Orphan Messages: - Checkpoint enthält Prozess, der eine Nachricht empfangen hat, - jedoch nicht den zugehörigen Sender, der die Nachricht sendet (Kausalität!). - im Fehlerfall würde die Nachricht erneut gesendet und somit zwei Mal empfangen. P A m P B Vermeidung von verlorenen Nachrichten: - Checkpoint enthält Prozess, der eine Nachricht gesendet hat, - der Empfänger hat die Nachricht jedoch noch nicht empfangen. - Bem.: bei konsistenten Schnitten erlaubt (verletzt nicht Kausalität). P A P B m 202 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

24 Unabhängiges Checkpointing Jeder Knoten sichert unabhängig von anderen Rechnern Checkpoints. Keine Kosten durch Koordination von Knoten bzw. Prozessen. Aber u.u. bilden die letzten Checkpoints keinen gültigen Zustand: - Im Fehlerfall muss ein gültiger Zustand berechnet werden (Berechnungsaufwand). - Hierzu werden evt. auch ältere Sicherungspunkte benötigt (Speicherbedarf). - Jeder Knoten muss somit viele Checkpoints speichern. Hauptrisiko: Im worst-case fällt das System durch den Domino-Effekt auf den Initalzustand zurück: P A X 1 X 2 X 3 P B Y 1 Y 2 Y Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

25 Koordiniertes Checkpointing System anhalten bis jeder Knoten/Proz. Checkpoint geschrieben hat. Domino-Effekt wird vermieden. Einfach Lösung: - Koordinator sendet an alle checkpoint-request, o Prozesse erstellen Sicherungspunkt, o senden Bestätigung, wenn sie fertig sind. - Koordinator beendet Sicherungspunkt durch checkpoint-done. - Nachrichten, die nach dem Erstellen des Checkpoint eintreffen, nicht Teil des Checkpoints - Ausgehende Nachrichten werden bis zum Eintreffen von checkpoint-done gepuffert. Alternativ: Schnappschuss-Verfahren nach Chandy-Lamport. Positiv: - Relativ einfach zu implementieren. - Es muss immer nur ein Checkpoint gespeichert werden. - Zwischen zwei Checkpoints fällt im normalen Betrieb kein weiterer Aufwand an. Negativ: - Checkpointing-Intervall in der Praxis oft groß, z.b. IBM LoadLeveler min. - erheblicher Zeitaufwand für Koordinierung aller Knoten im Cluster, 204 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

26 Buchführung über Interprozesskommunikation Idee: Nachrichten in stabilem Speicher Aufzeichnen (Logging) entweder beim Sender oder Empfänger. Recovery: - nur betroffener Knoten/Proz. wird auf letzten Checkpoint zurückgesetzt und startet wieder, - mit Hilfe der Logdatei werden Nachrichten gesendet und empfangen, - gesendete Duplikate werden mit Sequenznummer gefiltert, - Nachrichtenempfang wird durch Logdatei bedient. Funktioniert nur bei deterministischen Abläufen. Bei unabhägigem Checkpointing kann #Checkpoints reduziert werden. Beispiel: Protokollierung beim Empfänger - bei Recovery von P2 werden rote Nachrichten per Logdatei generiert, - P3 filtert doppelt empfangene Nachricht. P1 P2 P3 t 205 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

27 8.10 Zusammenfassung Fehlermodelle: Crash-, Timing-, Byzantine-Failures... Übereinstimmung: 2-Armeen-Problem & byz. Generäle. Scalable Reliable Multicast (nicht-)hierarchische Feedbacksteuerung. Atomarer Multicast: an alle oder keinen einer Gruppe Nachricht senden. Fehlertoleranter RPC. Fehlererholung: - Rückwärtsbehebung per periodischer Zustandssicherung o Sicherung in stable Storage (Disk oder im RAM repliziert), o unabhängiges vs. koordiniertes Checkpointing & Logging, o Rücksetzbarkeit für HW schwierig, - Vorwärtsbegebung Redundanz mit idv. Fehlerbehandlung (z.b. FEC). 206 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner