Verteilte Systeme F. Fehlertoleranz

Transkript

1 Verteilte Systeme F. Fehlertoleranz Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.1

2 Fehlertoleranz Abhängigkeiten in einem verteilten System: Client! Server! Dienste! Software! Hardware Fehlertoleranz bedeutet, das Gesamtsystem maskiert einen Fehler einer Komponente in den Abhängigkeitsrelationen das Fehlverhalten einer Komponente wird vom Gesamtsystem ausgeglichen. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.2

3 Fehler-Begriffe Failure das System verhält sich nicht wie spezifiziert. ist nicht leicht observierbar; muss mit speziellen Mechanismen aus einem Error abgeleitet werden. wenn nicht jeder Systemzustand erfasst wird, kann Fehlverhalten entstehen, ohne dass es bemerkt wird. Error Teil eines Systemzustands, der verantwortlich für eine zukünftige Failure ist, falls keine entsprechenden Maßnahmen getroffen werden. Lässt sich beobachten und evaluieren. Fault die Ursache eines Errors. Fault Tolerance ein (verteiltes) System ist fehlertolerant, wenn es sich sich trotz des Auftretens von Faults spezifikationskonsistent verhält Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.3

4 Hardwareredundanz Redundanz Zusätzliche Hardwarekomponentenwerden im System hinzugefügt. Softwareredundanz Softwarekomponenten oder Codesegmente werden mehrfach bereitgehalten und ausgeführt. Zeitredundanz Zusätzliche Ausführungszeit wird für die vorgenannten Techniken spendiert. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.4

5 Phasen eines fehlertoleranten Systems Fehlererkennung (engl.: error detection) ein Fehlerzustand (error) wird bemerkt und daraus auf einen Fehler (fault) in einem Teil des Systems geschlossen. Man nimmt an, dass dann ein Fehlverhalten (failure) der betroffenen Komponente des Systems auftritt. Schadensermittlung (engl.: damage confinement) Das System versucht zu erkennen, welcher Schaden bis zum Zeitpunkt der Erkennung aufgetreten ist Systemdesign so, dass Auswirkungen auf einen bekannten und beschränkten Bereich eingrenzbar Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.5

6 Phasen eines fehlertoleranten Systems (2) Fehlerbehebung (engl.: error recovery) der aufgetretene fehlerhafte Zustand wird behoben. das System wird in einen korrekten Zustand gebracht. Fehlerbehandlung und Weiterführen des Systems (engl.: fault treatment and continued system service) das fehlertolerante System soll spezifikationskonform weiter arbeiten die fehlerhafte Komponente wird umgangen oder in einer anderen Konfiguration verwendet. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.6

7 Fehlertolerante Hardware Fehlertoleranz wird in sicherheitskritischen Systemen oft durch redundante Auslegung der Hardware realisiert. triple modular redundancy, TMR) drei identische Hardwarekomponenten, die mit den gleichen Eingaben im gleichen Takt arbeiten. aus den drei Ergebnissen entscheidet die Majorität. System ist dadurch gegenüber dem Ausfall und der Fehlfunktion einer Komponente tolerant. bei nur zwei Replikaten könnte nur der Ausfall einer Komponente maskiert werden. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.7

8 Ebenen fehlertoleranter Software Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.8

9 F.1 Fehlersemantik bezeichnet das Verhalten von Systemkomponenten und damit des Systems im Fehlerfall Dienst muß, um korrekt zu arbeiten Intern korrekte Zustandsübergänge besitzen Korrekte Antworten an seine Klienten schicken Fehlverhalten kann in verschiedene Klassen aufgeteilt werden Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.9

10 Fehlerklassen Dienstverweigerung (engl.: omission failure) eine Komponente reagiert auf Auftrag nicht mit einer Antwort (z.b. verlorengehende Nachrichten im Kommunikationsdienst) fehlerhafte Antwort eine Komponente antwortet falsch auf einen Auftrag (engl.: response failure). falsche Werte werden übermittelt (engl.: value failure) intern finden falsche Zustandsübergänge statt (engl.: state transition failure) und es entstehen lokal falsche Werte. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.10

11 Fehlerklassen (2) Serverabsturz (engl.: crash failure) ein Server verweigert kontinuierlich seinen Dienst. er wird von Klienten als abgestürzt vermutet. weitere Unterscheidung je nach Zustand der Serverdaten nach Wiederanlaufen: Amnesie-Crash: der Server startet im Initialzustand. er verliert jegliche Datenzustände zum Zeitpunkt des Absturzes. Pause-Crash: der Server startet in dem Zustand, den er vor dem Absturz hatte. Halte-Crash: die fehlerhafte Komponente steht nach dem Fehler und wird nicht erneut gestartet. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.11

12 Fehlerklassen (3) Zeitfehler (engl.: timing failure) Komponente antwortet richtig, aber zum falschen Zeitpunkt. meist kommen die Antworten zu spät (z.b. durch einen überlasteten Server oder schlechte Netzverbindung) Antworten können auch zu früh ankommen. z.b. in Echtzeitsystemen oder Multimediasystemen. Byzantinische Fehler eine Komponente verhält sich beliebig. beliebige Kombinationen der anderen Fehlerklassen Ursache sind oft sind Hardwarefehler (z.b. ein defekter Timerbaustein zerstört die Ordnung von Nachrichten) Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.12

13 Implementierung von Fehlersemantiken Ein fehlertolerantes System muss Fehler maskieren. z.b. muss ein Service mit Omission-Semantik zur Fehlertoleranz so erweitert werden, dass verlorengehende Aufträge automatisch vom Klienten wiederholt werden. je mehr Fehlersemantiken tolerant begegnet werden soll, um so aufwendiger wird die Programmierung. die starke Schichtung eines Systems aus Mechanismen und Diensten bedingt eine hohe Abhängigkeit der Komponenten. Fehler werden von unteren Schichten in die höheren propagiert, dabei können sich Fehlerklassen ändern und sehr komplexe Phänomene auftreten. Zwei Ansätze zur Fehlermaskierung Hierarchische Maskierung Maskierung durch Gruppenbildung Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.13

14 Hierarchische Maskierung von Fehlern Fehler von Diensten oder Komponenten niedrigerer Ebene werden von den sie nutzenden Komponenten höherer Ebene maskiert. ist eine Maskierung auf einer unteren Ebene nicht möglich, wird eine Ausnahme (engl.: exception) auf höherer Ebene ausgelöst, um dann dort maskiert zu werden. einfaches Beispiel: Abfrage auf Division durch Null, wenn die Divisionshardware dies nicht selbst melden kann. IF Nenner <> 0 THEN Teile... ELSE Fehlerbehandlung... Wenn auf allen Ebenen die Maskierung unmöglich ist, muss letztlich der Benutzer über die Ausnahme informiert werden. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.14

15 Fehler-Maskierung durch Gruppenbildung Fehler einer einzelnen Komponente wird durch die Replikation der Funktionalität in einer Gruppe verborgen. Gruppe heißt k-fehlertolerant, wenn sie den gleichzeitigen Ausfall von k Mitgliedern maskieren kann. Anzahl Gruppenmitglieder: Maskierung des Fehlverhaltens von k Komponenten: k+1 Gruppenmitglieder genügen Maskierung byzantinischer Fehler: 3k+1 Mitglieder benötigt, da eine Mehrheitsentscheidung notwendig ist. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.15

16 F.2 Passive Redundanz Auch bezeichnet als lose Synchronisation Erreichen durch Primary-Backup-Ansatz es existieren k Replikate von Prozessen oder Daten Primärserver Anfragen werden immer an den Primärserver gestellt. ist der Primärserver fehlerhaft oder antwortet nicht, wird er durch einen Backupserver ersetzt. Backup die restlichen Replikate arbeiten als Backup. Passive Redundanz kann einen Knotenfehler, d.h. omission, des Primärservers maskieren. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.16

17 Aktualisierung der Backupserver: Hot-Standby die Backupserver laufen synchron mit dem Primärserver mit. Anfragen gehen an alle Server, die Antwort wird nur vom Primärserver erbracht. Ausfall des Primärservers: Backupserver sofort verfügbar. Warm-Standby Aufträge werden beim Primärserver gespeichert und den Backupservern periodisch übermittelt, die Backupserver werden dadurch nachgezogen. Ausfall des Primärservers: der letzte Backupblock muss noch bearbeitet werden, Backupserver ist nach kurzer Zeit verfügbar Cold-Standby Aufträge und Datenveränderungen stabil beim Primärserver gespeichert. Ausfall des Primärservers: anhand dieser Daten muss ein Backupserver vollständig nachgezogen werden, dauert u.u. recht lang Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.17

18 F.3 Aktive Redundanz Auch bezeichnet als enge Synchronisation Implementation aller beteiligten Komponenten bzw. Server als Zustandsmaschinen mit identischen Übergangsfunktionen Zustandsmaschinen beginnen im gleichen initialen Zustand Alle Kommandos und Anfragen von außen werden in gleicher Reihenfolge bearbeitet Zustandsänderungen aller Server werden synchron durchgeführt Alle Maschinen erzeugen identische Ausgaben. Maskierung des Ausfalls einer Komponente zu jedem Zeitpunkt Die Maskierung eines Fehlers erfordert Übereinkunft (engl.: agreement) und Ordnung (engl.: order). Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.18

19 Ordnung die empfangenen Kommandos werden bei allen Servern in der gleichen Reihenfolge ausgeführt. Ordnung kann man durch eindeutige Identifikatoren aller Nachrichten und eine totale Ordnung über diese Identifikatoren erreichen. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.19

20 Übereinkunft jede nicht-fehlerhafte Zustandsmaschine empfängt alle Kommandos und weiss welche anderen ebenfalls nicht-fehlerhaft sind. Realisierung von Übereinkunft durch Übereinkunftsprotokoll für byzantinische Fehler oder durch einen zuverlässigen Broadcast bei Fail-Stop-Verhalten theoretisch lässt sich in verteilten Systemen bei asynchronen Prozessen und unbeschränkter Nachrichtenlaufzeit Übereinkunft nicht erzielen, daher ist immer eine Restwahrscheinlichkeit gegeben, dass das fehlertolerante System Fehlverhalten zeigt. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.20

21 Byzantinisches Generalsproblem auf den Hügeln um Byzanz stehen die Truppen einiger römischer Generäle. um den Angriff zu koordinieren, melden sich die Generäle gegenseitig ihre Truppenstärken. keiner der Generäle ist sicher, dass nicht ein anderer General bestochen wurde und falsche Angaben macht, bzw. ob Nachrichten während der Übermittlung verfälscht werden. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.21

22 Übereinkunftsprotokoll von Lamport, Shostak und Pease 1982: die Generäle teilen sich ihre Truppenstärken mit: ,2,X,4 2 1,2,Y,4 3 1,2,3,4 4 1,2,Z,4 Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.22

23 Übereinkunftsprotokoll von Lamport, Shostak und Pease 1982: Austausch der gesammelten Informationen untereinander: ,2,X,4 1,2,X,4 1,2,X,4 1,2,X,4 2 1,2,Y,4 1,2,Y,4 1,2,Y,4 1,2,Y,4 3 a,b,c,d e,f,g,h 1,2,3,4 i,j,k,l 4 1,2,Z,4 1,2,Z,4 1,2,Z,4 1,2,Z,4 Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.23

24 Übereinkunftsprotokoll von Lamport, Shostak und Pease 1982: jeder General kann selbst eine Majoritätsentscheidung durchführen: ,2,X,4 1,2,X,4 1,2,X,4 1,2,X,4 2 1,2,Y,4 1,2,Y,4 1,2,Y,4 1,2,Y,4 3 a,b,c,d e,f,g,h 1,2,3,4 i,j,k,l 4 1,2,Z,4 1,2,Z,4 1,2,Z,4 1,2,Z,4 Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.24

25 Wieviele Komponenten sind nötig? mit dem Algorithmus können 3k+1 Komponenten k fehlerhaft arbeitende Komponenten maskieren. für die Mehrheitsentscheidung sind 2k+1 funktionstüchtige Komponenten notwendig (mehr als zwei Drittel). Hier: k=1: Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.25

26 F.4 Zuverlässigkeit bei Softwaredesignfehlern Problem: verwendet man für die Redundanz identische Software, wird ein Programmierfehler in allen Replikaten zum Tragen kommen. Lösung zur Maskierung von Softwaredesignfehlern: N-Versionen-Programmierung Recoveryblock-Methode Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.26

27 N-Versionen-Programmierung Bearbeiten eines Problems von N verschiedenen Entwicklerteams oder in N Varianten unabhängig voneinander N verschiedene Designs (gleiche Funktionalität, identische Schnittstellen) Versionen haben mit sehr hoher Wahrscheinlichkeit unterschiedliche Fehler, so dass sie gegenseitig die Fehler einzelner maskieren können. Programme laufen gleichzeitig aktiv redundant mit gleichen Eingaben die mehrfache Ausgabe wird durch einen Mehrheitsentscheid in eine einzige Ausgabe überführt. Probleme: unter Umständen kann nicht auf exakte Gleichheit geprüft werden (engl.: consistent comparison problem).z.b. kann eine Berechnung mit Gleitkommazahlen mit unterschiedlicher Rechenreihenfolge unterschiedliche Rundungsfehler erzeugen. die Laufzeit wird immer von der langsamsten Komponentebestimmt. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.27

28 Recoveryblock-Methode in einer Komponente werden kritische Kodepassagen in mehreren Versionen implementiert. die Komponente führt zuerst die Primärversion aus und prüft das Ergebnis durch einen Akzeptanztest gegen die Spezifikation. ist ein Fehler aufgetreten, wird der ursprüngliche Zustand wiederhergestellt und die nächste alternative Version benutzt. die Alternativen lassen sich schachteln. Beispiel: ensure <acceptance test> by <primary module> else by <alternate module 1>... else by <alternate module n> else error Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.28

29 Recoveryblock-Akzeptanztest Kein vollständiger, erschöpfender Test aller Systemanforderungen, sondern eher eine Stichprobe. er ist so flexibel zu halten, dass mehrere leicht unterschiedliche Ausgaben der zu testenden Module zulässig sein können. man kann dynamisch durch verschiedene Akzeptanztests auch unterschiedliches Verhalten des Systems ermöglichen. wenn der erste Akzeptanztest nicht erfolgreich ist, führt man einen abgeschwächten Test mit geringeren Anforderungen durch. wird dies wiederholt vorgenommen, kann ein adaptives System mit automatisch angepasster reduzierter Funktionalität realisiert werden (engl.: graceful degradation). Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.29