7 Fehlertoleranz

Zuverlässigkeit (reliability) Sicherheit vor Fehlern Sicherheit vor Angriffen (safety) (security) -> Systemsicherheit -> Netzsicherheit

(ist nicht einheitlich) 7.1 Terminologie (ist nicht einheitlich) Fehler (error): Versagen der Hardware oder Konstruktionsfehler in Hardware oder Software Fehlfunktion (fault): Teil des Systems verhält sich nicht so wie es sollte, bedingt durch Hardware- oder Software-Fehler Fehlverhalten (failure): Gesamtsystem verhält sich nicht so wie es sollte, bedingt durch Fehlfunktion Fehlertoleranz (fault tolerance): Systemeigenschaft, die bedeutet: Fehlfunktion wird so abgefangen, daß das gewünschte System- verhalten gesichert bleibt: Fehlfunktion führt nicht zu Fehlverhalten Verfügbarkeit (availability) von Systemen oder Daten: Anteil einer Zeitspanne, in dem das System ohne Fehlverhalten benutzbar ist, z.B. „Verfügbarkeit von 99,99%“

Verfügbarkeit wird oft in "Neunen" (nines) angegeben: Verfügbarkeit è Max. Ausfallszeit pro Jahr 99% 3,65 Tage 99,9% 8,76 Stunden 99,99% 52,5 Minuten 99,999% 5,25 Minuten 99,9999% 31,5 Sekunden

Zur Erreichung von Fehlertoleranz kommen verschiedene Arten von Redundanz zum Einsatz:  physische Redundanz, z.B. Überschuss an Prozessoren: - 1 Prozessor in Reserve (passive Redundanz, primary + backup) mit hot standby oder cold standby, - 3 Prozessoren tun das Gleiche, praktizieren Abstimmung (aktive Redundanz, active redundancy)  Informationsredundanz, z.B. fehlerkorrigierende Codes, n-Versionen-Programmierung, Replikation (beinhaltet physische Redundanz von Speicher)  zeitliche Redundanz, z.B. Wiederholungsversuch bei Datenübertragung hot / cold standby: zweiter Prozessor läuft mit und bekommt alle Daten gespiegelt / erst bei Bedarf aktiviert N-Versionen-Programmierung: Mehrfachimplementierung durch unabhängige Team. Zur Laufzeit Zusammenschaltung, Mehrheitsentscheidung (3) bzw. geeignete Reaktion auf unterschiedliche Ergebnisse (2)

Klassifikation von Fehlfunktionen, z.B. von Prozessoren („Fehlersemantik“): fail-stop: Prozessor wird funktionsunfähig und signalisiert dies (!) fail-silent: Prozessor „rührt sich nicht mehr“ (evtl. schwer erkennbar) byzantinisch: Prozessor läuft fehlerhaft weiter

7.2 Replikation mit Abstimmung (voting) toleriert Stations- und Netzausfälle, erhöht die Verfügbarkeit von Daten Ansatz: Verwendung von Lese- und Schreib-Quorum (vgl. 6.3.1.2b) Nebeneffekt: Lese/Schreib-Ausschluss n Kopien/Server, Kopien tragen Versionsnummer, Lese-Quorum r, Schreib-Quorum w - Schreiben auf w Kopien (statt n) - Lesen von r Kopien (statt nur 1) mit r + w > n, n/2 < w  n, 0 < r  n 6.3.1.2b: Verteilte Transaktionen -> Serialisierbarkeit durch Ausschlusssynchronisation -> verteilter Leser-Schreiber-Ausschluss

 Schreibmenge, d.h. w Server finden Schreiben in 2 Phasen:  Schreibmenge, d.h. w Server finden  Schreibnachricht an alle Mitglieder der Schreibmenge schicken (diese schreiben dann – und erhöhen die Versionsnummer); auf Bestätigungen warten und Schreibmenge wieder freigeben; (Ergänzungen notwendig, z.B. für den Fall, daß nicht alle Mitglieder der Schreibmenge eine Bestätigung schicken.)

Lesen in 2 Phasen:  Lesemenge finden, d.h. r Server finden, die bereit sind – sie melden sich mit ihrer Versionsnummer  Lesen von einem Mitglied der Lesemenge, das die höchste Versionsnummer hat Lesemenge wieder freigeben Wichtig: Die höchste Nummer ist die tatsächliche aktuelle Versionsnummer, w + r > n garantiert die Überlappung mit der letzter Schreibmenge.

© A. Tanenbaum a), b): weder für das Lesen noch für das Schreiben alle Server erforderlich

7.3 Verteilte Übereinkunft (distributed consensus/agreement) z.B. - Aufteilung einer Aufgabe - „gleichzeitige“ Abschaltung von Aggregaten - Folklore: „Byzantinische Generäle “ - u.ä.  Unzuverlässige Nachrichten: Es kann nicht garantiert werden, dass innerhalb einer vorgegebenen Zeit Einigkeit erzielt wird.

 Unzuverlässige Prozessoren: Satz für byzantinische Fehler (Lamport 1982): Verteilte Übereinkunft angesichts byzantinischer Fehler ist genau dann möglich, wenn von insgesamt 3m + 1 Prozessoren höchstens m fehlerhaft sind. (M.a.W.: mehr als zwei Drittel der Prozessoren müssen korrekt arbeiten.) Details: Coulouris et al.: Verteilte Systeme Legende: Kommunikationsproblem zwischen den osmanischen Generälen, die im Jahr 1453 n.Chr. Konstantinopel (das heutige Istanbul) belagerten. Wegen der starken Befestigung Konstantinopels war es notwendig, dass die Generäle mit ihren Truppen die Stadt gleichzeitig aus verschiedenen Richtungen angriffen. - Generäle kommunizieren mit Boten miteinander, um sich auf eine gemeinsame Aktion zu einigen - Einige der Generäle intrigieren gegen die anderen durch geschickte Fehlinformation

4 byzantinische Generäle 1 2 x y z 4 1 2 4 byzantinische Generäle 1 2 1. Schritt: Nachrichtenaustausch 2. Schritt (lokal): Akkumulieren 1 bekommt (1,2,x,4) 2 bekommt (1,2,y,4) 3 bekommt (1,2,3,4) 4 bekommt (1,2,z,4) 3 4 1 bekommt: (1,2,y,4) (a,b,c,d) (1,2,z,4) 2 bekommt: (1,2,x,4) (e,f,g,h) 4 bekommt: (i,j,k,l) 3.Schritt: Vektoren austauschen 4. Schritt (lokal): Konsens ermitteln (1,2,UNKNOWN,4)

3 byzantinische Generäle 1 2 x y 1 2 3 byzantinische Generäle 1 2 1. Schritt: Nachrichtenaustausch 2. Schritt (lokal): Akkumulieren 1 bekommt (1,2,x) 2 bekommt (1,2,y) 3 bekommt (1,2,3) 3 1 bekommt: (1,2,y) (a,b,c) 2 bekommt: (1,2,x) (d,e,f) 3.Schritt: Vektoren austauschen 4. Schritt (lokal): Konsens nicht möglich!