1-fach - KBS TU

Verteilte Algorithmen
Fehlertoleranz
PD Dr.-Ing. Gero Mühl
Kommunikations- und Betriebssysteme
Fakultät für Elektrotechnik u. Informatik
Technische Universität Berlin
Übersicht
> Einführung
> Maskierende Fehlertoleranz
> Konsens und verwandte Problem
> Nichtmaskierende Fehlertoleranz
> Selbststabilisierung
G. Mühl
VA / Fehlertoleranz
2
Fehlertoleranz (Fault Tolerance)
> Kein (nicht-triviales) System ist fehlerfrei!
> Berücksichtigung möglicher Fehler absolut notwendig!
> In großen Systemen (z.B. dem Internet) werden stets
einige Komponenten fehlerhaft arbeiten
> Einfache Motivation: Alle Rechner eines Systems müssen
gleichzeitig verfügbar sein (Reihenschaltung)
>
>
>
>
G. Mühl
1 Rechner
10 Rechner
100 Rechner
1000 Rechner
 System 1% der Zeit nicht verfügbar
 System 10% der Zeit nicht verfügbar
 System 63% der Zeit nicht verfügbar
 System 99.99% der Zeit nicht verfügbar
VA / Fehlertoleranz
3
Grundlegende Begriffe
> Störung (fault)
> Auslösendes Ereignis, beispielsweise
verursacht, durch externe Störungen oder
durch Abnutzung
Störung
> Fehler (error)
> Interner Systemzustand, der nicht der
Spezifikation entspricht, verursacht durch
eine Störung
> Ausfall (failure)
> System erbringt nach außen nicht mehr den
Dienst, den es erbringen sollte, verursacht
durch einen Fehler
G. Mühl
Fehler
Ausfall
VA / Fehlertoleranz
4
Klassifizierung von Fehlern – Gutmütige Fehler
> „Crash Failure“: Ein Knoten fällt plötzlich aus, d.h. bis zum
Zeitpunkt des Fehlers verhält er sich spezifikationsgerecht,
danach werden keine Aktionen mehr durchgeführt
> Auch als „Halting Failure“ oder „Fail Stop“ etc. bezeichnet. Oft
bedeuten diese Begriffen aber zusätzlich, dass alle nicht
ausgefallenen Knoten den Ausfall sicher feststellen können
> „Omission Failure“: Manche Aktionen werden nicht ausgeführt
> „Timing Failure“: Im Prinzip spezifikationsgerechtes Verhalten,
aber manche Aktionen werden zu spät ausgeführt
> Allen gemeinsam: Der fehlerhafte Prozess führt keine Aktionen
aus, die ein korrekter Prozess nicht machen würde
⇒ Nicht immer realistisch!
G. Mühl
VA / Fehlertoleranz
5
Klassifizierung von Fehlern – Bösartige Fehler
> Häufig als Byzantinische Fehler bezeichnet
(Lamport, 1982)
> Fehlerhafte Prozesse können beliebige Aktionen
ausführen und dabei auch untereinander kooperieren
> Z.B. beliebige Berechnungen durchführen und beliebige
Nachrichten senden
> Häufig auch etwas eingeschränktes Modell
> Z.B. fehlerhafte Prozesse können beliebige mit polynomieller
Komplexität berechenbare Aktionen ausführen (also z.B.
keine digitalen Signaturen von korrekten Knoten fälschen!)
> Modell umfasst alle beliebigen Arten von Fehlern, z.B.
auch gezielte Angriffe von außen auf ein System
G. Mühl
VA / Fehlertoleranz
6
Paradigmen der Fehlertoleranz
> Maskierende Fehlertoleranz (masking fault tolerance)
> Ziel: Systemausfall möglichst verhindern
> Nichtmaskierende Fehlertoleranz
(non-masking fault tolerance)
> System darf teilweise oder zeitweise ausfallen
> Besser als ein vollständiger und / oder permanenter Ausfall
G. Mühl
VA / Fehlertoleranz
7
Maskierende Fehlertoleranz
> Notwendig, wenn ein (auch temporäres) Versagen des
Systems inakzeptable Folgen hätte
> Z.B. Tod von Menschen oder hohe finanzielle Verluste
> Sinnvoll auch bei vielen anderen Anwendungen
> Sicherheit und Lebendigkeit sicherstellen!
> Beispiel Autobremsen: Getrennte Bremskreisläufe für
rechtes Vorderrad und linkes Hinterrad sowie für linkes
Vorderrad und rechtes Hinterrad
G. Mühl
VA / Fehlertoleranz
8
Maskierende Fehlertoleranz
>
>
>
>
Benötigt stets Redundanz zur Umsetzung
Ist stets nur für dedizierte Fehler möglich
Kann nie alle möglichen Fehler berücksichtigen
Ist nur dann erfolgreich, wenn lediglich ein begrenzter Teil
der Komponenten fehlerhaft ist
> Wie groß der fehlerhafte Anteil der Komponenten sein
darf, ist abhängig vom Fehlermodell
G. Mühl
VA / Fehlertoleranz
9
Redundanz im Raum bzw. in der Zeit
> Redundanz im Raum:
Mehrfache Auslegung von Komponenten
> Beispiel: Ein Server hat mehrere unabhängige Netzteile
> Einzelnes, funktionsfähiges Netzteil ausreichend
> Fehlerhafte Netzteile werden im Betrieb ausgetauscht
> Redundanz in der Zeit:
Mehrfache Durchführung von Aktionen
> Beispiel: Pakete werden mehrmals hintereinander mittels
eines unzuverlässigen Netzwerks übertragen; aus diesen
Duplikaten wird (falls möglich) ein fehlerfreies Paket erzeugt
G. Mühl
VA / Fehlertoleranz
10
Aktive und Passive Replikation
> Aktive Replikation
> Alle Replikate arbeiten produktiv mit
> Z.B. Augen, Triebwerke, Bremssysteme, ...
> TMR (Triple Modular Redundancy)
A1
A2
A3
x
y
Voter
x
x
> Passive Replikation
> Replikate treten nur im Fehlerfall in Aktion (primary/backup)
> Z.B. Ersatzreifen (keine Maskierung), Notstromaggregat, ...
G. Mühl
VA / Fehlertoleranz
11
Fehlertoleranz durch redundante Komponenten
> k-Zuverlässigkeit eines Systems in Bezug auf eine
Komponente, die n-fach vorhanden ist: System kann Ausfall von
bis zu k der n Instanzen der Komponenten tolerieren
> Nicht-byzantinische Fehler
> System mit einer n-fach vorhandenen Komponente
ist (n – 1)-zuverlässig in Bezug auf diese Komponente
> Byzantinische Fehler
> Annahme: korrekte Ausgabe kann eindeutig durch einen
hochzuverlässigen Voter aus den n Ausgaben bestimmt werden
> System mit einer n-fach vorhandenen Komponente ist
-zuverlässig in Bezug auf diese Komponente
G. Mühl
VA / Fehlertoleranz
12
Beispiel: 1–Zuverlässigkeit
> Betrachte File Server S mit Operationen read() und write()
> Nicht-byzantinische Fehler
> S schickt bei read() entweder richtigen Inhalt oder gar nichts
> Realisierung mit zwei Servern S1 und S2
> write( ): an beide Server
> read( ): wenn S1 nicht antwortet dann S2
auch möglich: S1 und S2 fragen; 1. Antwort verwenden
> Byzantinische Fehler
> S schickt bei read( ) entweder den richtigen Inhalt oder einen
falschen Inhalt oder gar nichts
> Realisierung mit drei Servern S1, S2 und S3
> write( ): an alle drei Server
> read( ): an alle drei Server, Mehrheitsentscheid beim Client
G. Mühl
VA / Fehlertoleranz
13
Beispiel: N-Version Programming
> Anwendung wird von unabhängigen Programmierteams
mehrfach entwickelt
> Ergebnisse der Module werden zur Laufzeit durch
Mehrheitsentscheid bewertet
> Probleme
> Vergleich von Ergebnissen mit zulässiger Ungenauigkeit
(z.B. Ergebnis einer numerischen Approximation)
> Vergleich bei mehreren möglichen korrekten Lösungen
(z.B. Nullstellen eines Polynoms)
> Entwicklung häufig nicht wirklich „unabhängig“
> …
G. Mühl
VA / Fehlertoleranz
14
Nichtmaskierende Fehlertoleranz
> Anwendbar, wenn ein teilweises oder temporäres
Versagen des Systems/der Komponente akzeptabel ist
> 1. Mögliches Ziel: Bei einem Fehler, das System in einen
sicheren Zustand bringen (fail safe)
> Sicherheit gewährleisten
> Beispiel Ampelsteuerung: Bei einem Fehler der
Ampelsteuerung werden alle Ampeln auf Rot geschaltet
> Beispiel mechanisches Haltesignal für Züge:
Beim Reißen des Zugseiles fällt der Arm des Signals in die
Stellung „Halten!“
G. Mühl
VA / Fehlertoleranz
15
Nichtmaskierende Fehlertoleranz
> 2. Mögliches Ziel: Bei einem Fehler, das System mit
eingeschränkter Funktionalität weiter betreiben
(graceful degradation)
> Sicherheit und eingeschränkte Lebendigkeit gewährleisten
> Beispiel Servolenkung: Bei Ausfall der Servopumpe ist das
Lenken weiterhin möglich, allerdings nur mit größerem
Kraftaufwand
G. Mühl
VA / Fehlertoleranz
16
Nichtmaskierende Fehlertoleranz
> 3. Mögliches Ziel: Bei einem Fehler, das System so
umkonfigurieren, dass es wieder korrekt arbeitet
> Sicherheit nach Rekonfiguration (eventual safety) wieder
gewährleisten
> Lebendigkeit ist nicht betroffen, wenn die Rekonfiguration
nur eine beschränkte Zeit dauert
> Beispiel Kommunikation über mehrere hintereinander
geschaltete Strecken: Bei Ausfall einer oder mehrerer
Strecken, wird ein Alternativroute ohne Verwendung der
ausgefallenen Strecken aufgebaut
G. Mühl
VA / Fehlertoleranz
17
Maskierende Fehlertoleranz:
Konsens und verwandte Probleme
Konsens und verwandte Probleme
> Byzantinische Generäle (Byzantine generals)
> Ein Wert wird von einem ausgezeichneten Prozess vorgegeben
1. Alle korrekten Prozesse einigen sich auf den gleichen Wert (IC1)
2. Ist der vorgebende Prozess fehlerfrei, erfolgt die Einigung auf
dessen Wert (IC2)
> Interaktive Konsistenz (interactive consistency)
> Von jedem Prozess wird ein Wert vorgegeben
1. Alle korrekten Prozesse einigen sich auf den gleichen Wertevektor
2. Die Vorgabewerte fehlerfreier Prozesse werden in dem
Wertevektor richtig wiedergegeben
> Konsens (consensus)
> Von jedem Prozess wird ein Wert vorgegeben
1. Alle korrekten Prozesse einigen sich auf den gleichen Wert
2. Wenn alle korrekten Prozesse den gleichen Wert vorgeben,
einigen sich alle auf diesen Wert
G. Mühl
VA / Fehlertoleranz
19
Agreement vs. Consensus vs. Consistency
> Die drei Problemstellungen können ineinander überführt werden!
> Siehe auch Coulouris, Seiten 452-455
Byzantinische
Generäle
Verteilung des
Initialwerts an alle
Jeder Knoten startet
Instanz des Algorithmus
Berechnung aus
gemeinsamen Vektor
Konsensus
G. Mühl
Interaktive
Konsistenz
VA / Fehlertoleranz
20
Byzantinische Generäle  Interaktive Konsistenz
> Lösung für die byzantinischen Generäle vorhanden, für
Interaktive Konsistenz gesucht
> Jeder Knoten startet eine Instanz des Algorithmus für die
byzantinischen Generäle mit seinem Wert
> Jeder fehlerfreie Knoten nimmt als i-te Komponente seines
Ergebnisvektors, den Wert, den er als Lösung für die
byzantinischen Generäle mit Prozess Pi als Anführer erhält
> Die Ergebnisvektoren der Knoten sind eine korrekte Lösung
des Problems der interaktiven Konsistenz
G. Mühl
VA / Fehlertoleranz
21
Interaktive Konsistenz  Konsens
> Lösung für Interaktive Konsistenz vorhanden, für Konsens
gesucht
> Die Knoten bestimmen eine Lösung für die interaktive
Konsistenz
> Jeder Knoten gibt dabei den Wert vor, den er auch für den
Konsens vorschlagen würde
> Dann bestimmt jeder Knoten aus seinem Ergebnisvektor
mittels der Mehrheitsfunktion einen Wert; falls keine
Mehrheit vorhanden ist, nimmt er den Default-Wert
> Die aus den Werten der Knoten gebildete Lösung ist eine
korrekte Lösung des Konsensproblems
G. Mühl
VA / Fehlertoleranz
22
Konsens  Byzantinische Generäle
> Lösung für Konsens vorhanden, für byzantinische
Generäle gesucht
> Der Initialwert wird vom Anführer an alle Leutnants und an
sich selber verteilt
> Dann wird eine Lösung des Konsensproblems unter allen
Generälen bestimmt
> Jeder Leutnant hat danach einen Konsenswert. Die
Konsenswerte aller Leutnants bilden zusammen eine
korrekte Lösung des Problems der byzantinischen Generäle
G. Mühl
VA / Fehlertoleranz
23
Byzantinische Generäle
> Lamport, Shostak, and Pease, 1982
> n > 3 Generäle, m davon sind Verräter
(verursachen byzantinische Fehler)
> Einer der Generäle ist der Anführer
(commanding general) und gibt einen
Wert v ∈ {0, 1} vor
> Die anderen Generäle (lieutenant
generals) sollen den Befehl des
Anführers ausführen
> Mindestens 1 Leutnant ist loyal
(fehlerfrei)
> Auch Anführer kann Verräter sein
> Frage: Zusammen angreifen (v = 1)
oder abwarten (v = 0)?
G. Mühl
Anführer
Verräter
VA / Fehlertoleranz
24
Byzantinische Generäle – Annahmen
> Synchrones Systemmodel
> Jeder Prozess ist mit jedem anderem direkt verbunden
 vollständige Vermaschung
> Nachrichten
>
>
>
>
>
G. Mühl
gehen nicht verloren
werden nicht dupliziert
kommen wie gesendet an
können nicht fälschungssicher signiert werden
erlauben die Bestimmung der Identität des Absenders
 oral messages
VA / Fehlertoleranz
25
BG – Algorithmus für m = 1
1. Der Anführer nennt den anderen seinen Wert (0 oder 1)
2. Dann teilt jeder General jedem anderen General den
Wert mit, den er vom Anführer erhalten hat
3. Jeder der Generäle trifft aus seinen erhaltenen Werten
eine Mehrheitsentscheidung
> Achtung: Ein fehlerhafter Anführer oder General kann
schicken, was er will!
G. Mühl
VA / Fehlertoleranz
26
BG – Versagen des Algorithmus für n = 3 und m = 1
1. Fall: Anführer ist fehlerhaft  Gute Generäle erhalten {a, b}
2. Fall: Rechter General ist fehlerhaft  Linker General erhält {a, b}
3. Fall: Linker General ist fehlerhaft  Rechter General erhält {a, b}
Anführer: 0
Leutnants: 1, 2
1. Fall
2. Fall
0:a
G. Mühl
0:b
Es gilt a ≠ b !
3. Fall
0:a
0:a
0:b
0:b
1:0:a
1:0:a
1:0:a
2:0:b
2:0:b
2:0:b
VA / Fehlertoleranz
27
BG – Versagen des Algorithmus für n = 3 und m = 1
> Der linke General kann den 1. und 2. Fall nicht
unterscheiden. Daher muss er den vom Anführer
vorgegebenen Wert a wählen, um IC2 zu erfüllen
> Der rechte General kann den 1. und 3. Fall nicht
unterscheiden. Daher muss er den vom Anführer
vorgegebenen Wert b wählen, um IC2 zu erfüllen
> Dies bedeutet aber, dass im 1. Fall die beiden Generäle
unterschiedliche Werte wählen. Daher ist IC1 verletzt
⇒ Widerspruch
> Für n = 3 und m = 1 ist keine Lösung möglich!
> Dieser Resultat lässt sich verallgemeinern auf:
Für n ≤ 3m ist keine Lösung möglich!
G. Mühl
VA / Fehlertoleranz
28
Byzantinische Generäle für n = 4 und m = 1
> Einfachster Fall mit n ≥ 3m + 1
1. Fall: Anführer ist fehlerhaft
> Jeder General erhält {a, a, b} und entscheidet sich für a
0:a
0:b
0:a
1:0:a
2:0:a
2:0:a
Anführer: 0
Leutnants: 1, 2, 3
Es gilt a≠ b !
3:0:b
3:0:b
1:0:a
G. Mühl
VA / Fehlertoleranz
29
Byzantinische Generäle für n = 4 und m = 1
2. Fall: Ein General ist fehlerhaft
> Linker General erhält {a, a, b} und entscheidet sich für a
> Mittlerer General erhält {a, a, b} und entscheidet sich für a
0:a
0:a
0:a
1:0:a
2:0:a
2:0:a
3:0:b
Es gilt a ≠ b !
3:0:b
1:0:a
G. Mühl
VA / Fehlertoleranz
30
Byzantinische Generäle
> Algorithmus kann auf größere m verallgemeinert werden,
durch eine rekursive Ausführung des Algorithmus
> Der Algorithmus benötigt m + 1 Runden (dies ist minimal!)
⇒ Einheitszeitkomplexität m + 1
> Bei m fehlerhaften Prozessen ist Agreement möglich,
wenn es mindestens 2m + 1 korrekte Prozesse gibt
⇒ Es muss gelten: n ≥ 3m + 1 (Die Schranke ist also hart!)
⇒ Mehr als 2 / 3 aller Prozesse müssen korrekt arbeiten
G. Mühl
VA / Fehlertoleranz
31
Rekursiver Algorithmus OM für Oral Messages
Initial action at commander:
OM(m, 0, {1, …, n - 1}, v);
Initial action at lieutenant L: ML={}
PROC OM(m, C, G, t) {
FOREACH L in G DO
SEND (m, G, C + ":" + t ) TO L;
END
}
{Message (m, G,
IF (m, G, t)
ML := ML ∪
IF m != 0
FI
t) is received by lieutenant L}:
is pending THEN
t;
THEN OM(m - 1, L, G \ {L}, t); FI
{Lieutenant P has received all messages}:
v:=tree_majority(ML);
G. Mühl
VA / Fehlertoleranz
32
Rekursionsbaum für n = 4 und m = 1
0
1. Runde
1
2
3
4
2. Runde
2
G. Mühl
3
4
1
2
4
1
2
4
1
2
3
VA / Fehlertoleranz
33
Byzantinische Generäle – Nachrichtenkomplexität
G. Mühl
>
>
>
>
>
Eine Instanz von OM(m) startet (n – 1) Instanzen von OM(m – 1)
Jede Instanz von OM(m – 1) startet (n – 2) Instanzen von OM(m – 2)
Jede Instanz von OM(m – 2) startet (n – 3) Instanzen von OM(m – 3)
…
Jede Instanz von OM(1) startet (n – m) Instanzen von OM(0)
>
>
>
>
>
>
Jede Instanz von OM(m) verschickt (n – 1) Nachrichten
Jede Instanz von OM(m – 1) verschickt (n – 2) Nachrichten
Jede Instanz von OM(m – 2) verschickt (n – 3) Nachrichten
…
Jede Instanz von OM(1) verschickt (n – m) Nachrichten
Jede Instanz von OM(0) verschickt (n – 1 – m) Nachrichten
VA / Fehlertoleranz
34
Byzantinische Generäle – Nachrichtenkomplexität
>
>
>
>
>
1. Runde:
2. Runde:
3. Runde:
…
(m+1)-te R.:
1 Instanz mit je n – 1 Nachrichten
n – 1 Instanzen mit je n – 2 Nachrichten
(n – 1)(n – 2) Instanzen mit je n – 3 Nachrichten
(n – 1)! / (n – 1 – m)! Instanzen
mit je n – 1 – m Nachrichten
> Ableitung der Nachrichtenkomplexität
G. Mühl
VA / Fehlertoleranz
35
Byzantinische Generäle – Nachrichtenkomplexität
> n = 4, m = 1
> 3 + 3 · 2 = 3 + 6 = 9 Nachrichten
> n = 7, m = 2
> 6 + 6 · 5 + 6 · 5 · 4 = 156 Nachrichten
> n = 10, m = 3
> 9 + 9 · 8 + 9 · 8 · 7 + 9 · 8 · 7 · 6 = 3.609 Nachrichten
> n = 13, m = 4
> 13 + 13 · 12 + 13 · 12 · 11 + 13 · 12 · 11 · 10 + 13 · 12 · 11 ·
10 · 9 = 108.384 Nachrichten
G. Mühl
VA / Fehlertoleranz
36
Nachrichtenbaum / Baummehrheitsfunktion
> Jeder General bildet einen Nachrichtenbaum aus den
Nachrichten, die er empfangen hat
> Hierfür ordnet er die empfangenen Nachrichten
entsprechend des Postfixes ihres Nachrichtenpfades
> Wiederholte Mehrheitsbildung, bis sich ein einzelner Wert
ergibt, nach folgender Methode
> Für jeden Knoten direkt oberhalb der Blätter wird die
Mehrheit gebildet aus seinem Wert und den Werten der
unter ihm liegenden Blätter
G. Mühl
VA / Fehlertoleranz
37
Nachrichtenbaum für General 1 und n = 7, m = 2
0:a
Postfix 2:0
3:0:a
2:0:a
4:0:a
5:0:b
6:0:b
2:5:0:b
3:2:0:a
2:3:0:a
4:2:0:a
4:3:0:a
5:2:0:b
6:2:0:b
G. Mühl
2:4:0:a
3:4:0:a
5:3:0:b
6:3:0:b
2:6:0:b
6:5:0:b
3:5:0:b
5:4:0:b
3:6:0:b
4:5:0:b
6:4:0:b
4:6:0:b
5:6:0:b
VA / Fehlertoleranz
38
Nachrichtenbaum für General 1 und n = 7, m = 2
0:a
a
a
a
b
b
Diese Abbildung zeigt den Nachrichtenbaum
der vorigen Folie nach der 1. Mehrheitsbildung.
G. Mühl
VA / Fehlertoleranz
39
Nachrichtenbaum für General 1 und n = 7, m = 2
a
Diese Abbildung zeigt den Nachrichtenbaum
der vorigen Folie nach der 2. Mehrheitsbildung.
G. Mühl
VA / Fehlertoleranz
40
Byzantinische Generäle – Signed Messages
> Können Nachrichten fälschungssicher signiert werden
(signed messages), dann kann Agreement bei beliebig
vielen fehlerhaften Prozessen erreicht werden
> Voraussetzung bisher: Synchrones System
> "In einem asynchronen System ist kein Agreement möglich."
Fisher et al., 1985
> Viele weitere (theoretische) Arbeiten zu diesem Thema
mit den vielfältigsten Annahmen
G. Mühl
VA / Fehlertoleranz
41
Nicht-Maskierende Fehlertoleranz:
Selbststabilisierung
Selbststabilisierende Systeme
„We call the system "self-stabilizing" if and only if, regardless
of the initial state […], the system is guaranteed to find itself
in a legitimate state after a finite number of moves.“
Dijkstra, 1974
Legitimer
Zustand
Initialer
Zustand
G. Mühl
VA / Fehlertoleranz
43
Nachweis der Selbststabilisierung
> Menge aller Zustände Z
> Menge der legitimen Zustände L ⊆ Z
> Zu zeigen: Konvergenz und Abgeschlossenheit
Z
L
> Konvergenz: Startend von einem Zustand aus Z \ L wird nach
einer beschränkten Zahl von Schritten ein Zustand in L erreicht
> Konstruiere eine Funktion t (Terminierungsfunktion) von Z nach ℕ,
die mit jedem Schritt abnimmt und am Ende mit t = 0 die
Stabilisierung anzeigt
> Abgeschlossenheit: Startend in einem Zustand aus L ist jeder
Folgezustand wieder in L
> Nachweis in der Regel durch eine Invariante
G. Mühl
VA / Fehlertoleranz
44
Erholung von transienten Fehlern
> Selbststabilisierende Systeme erholen sich von beliebigen transienten
Fehlern, wenn genügend lange Zeit keine neuen Fehler auftreten
> Der Zustand nach dem Ende des letzten noch wirkenden Fehlers ist der
betrachtete „initiale“ Zustand  Erholung garantiert
> Die Klasse der transienten Fehler beinhaltet unter anderem
> Temporäre Netzwerkfehler
> Den Absturz und anschließenden Neustart von Prozessen
> Die willkürliche Korruption von Datenstrukturen
> Beachte: Nichtselbststabilisierende Systeme fallen auch nach
transienten Fehlern eventuell permanent aus!
> Beliebiger Teil der Ressourcen kann von Fehlern betroffen sein
> Ausnahme: Programmcode und Daten im ROM werden nicht korrumpiert
G. Mühl
VA / Fehlertoleranz
45
Selbststabilisierende Systeme – Eigenschaften
> Brauchen nicht initialisiert zu werden, da sie aus jedem
Startzustand einen legalen Zustand erreichen
> Tolerieren beliebige transiente Fehler mit einem einheitlichen
Mechanismus
> Können nicht sicher wissen, ob sie stabilisiert sind
> Dürfen nicht terminieren
> Passen sich ggf. an dynamische Änderungen der Topologie an
> Brauchen Fehler nicht notwendigerweise zu detektieren, um
sich von ihnen zu erholen
> Bieten effiziente Lösungen für viele Probleme
> Informationsverteilung, Wechselseitiger Ausschluss,
Spannbaumkonstruktion, Auswahl, …
G. Mühl
VA / Fehlertoleranz
46
Komposition von Algorithmen
> Herkömmliche Komposition von Algorithmen A und B
> Hintereinanderausführung von A und B
> B wird gestartet, wenn A terminiert ist
> Die Ausgabe von A dient als Eingabe für B
A
B
G. Mühl
VA / Fehlertoleranz
47
Komposition von Algorithmen
> Komposition selbststabilisierender Algorithmen
> Gleichzeitige Ausführung von A und B
> Wenn A stabilisiert hat, wird danach auch B stabilisieren
> Voraussetzung: B schreibt keine Daten, die A liest
> Stabilisierungszeit der Komposition ist die Summe der
Stabilisierungszeiten der einzelnen Algorithmen und
etwaiger Verzögerungen
A
A beginnt zu
stabilisieren
A ist stabilisiert
B
B beginnt zu
stabilisieren
G. Mühl
B ist stabilisiert
VA / Fehlertoleranz
48
Selbst-Stabilisierender Token Ring (Dijkstra, 1974)
> n + 1 Prozesse sind in einem unidirektionalen Ring angeordnet
> Jeder Prozess kann einen von k Zuständen annehmen (k > n)
 Variable s ∈ {0, …, k - 1}
> Jeder Prozess kann auf den Zustand seines linken Nachbarn
durch eine gemeinsame Variable left zugreifen
> Jeder Prozess, der ständig ziehen kann, zieht auch irgendwann
ON bottom process (P0):
WHILE TRUE DO
IF (left == s) THEN
‹token›
s := (s+1) mod k;
FI
END
END
G. Mühl
ON other process (Pi, i≠0):
WHILE TRUE DO
IF (left != s) THEN
‹token›
s := left;
FI
END
END
VA / Fehlertoleranz
49
Selbst-Stabilisierender Token Ring
Prozess
Zustand
0
3
3
3
3
3
0
0
0
0
1
1
2
3
3
3
3
3
0
0
0
0
2
0
0
0
3
3
3
3
0
0
0
3
1
1
0
0
3
3
3
3
0
0
Beispielablauf
für n = 3 und k = 4
Prozess führt
Schritt aus und
greift auf das
Token zu.
Zustand nach
Schritt in
nächster Zeile
Prozess könnte
Schritt ausführen
und auf das
Token zugreifen
G. Mühl
VA / Fehlertoleranz
50
Selbst-Stabilisierender Token Ring
> Originale Spezifikation
> Sicherheit: Es gibt höchstens ein Token im System
> Lebendigkeit: Mindestens ein Token zirkuliert im Ring
> Fairness: Kann ein Prozess ständig ziehen, so zieht er auch
nach endlicher Zeit
> Selbststabilisierende Variante
> Sicherheit: Nach endlich vielen Schritten gibt es höchstens
ein Token im System
> Lebendigkeit und Fairness wie oben
G. Mühl
VA / Fehlertoleranz
51
Selbststabilisierende Spannbaumkonstruktion
> Prozesse {P1, …, Pn} sind in einer beliebigen,
zusammenhängenden Topologie angeordnet
> Annahmen
> Jeder Prozess hat eine eindeutige Identität > 0, in seinem
ROM gespeichert
> Jeder Prozess hat denselben Timeout-Wert ρ in seinem
ROM gespeichert
> Im fehlerfreien Fall gehen keine Nachrichten verloren und
Nachrichten haben eine beschränkte Laufzeit
G. Mühl
VA / Fehlertoleranz
52
Selbststabilisierende Spannbaumkonstruktion –
Grundidee im Fehlerfreier Fall
> Wurzel (Knoten mit kleinster ID) schickt mit der Periode ρ Heartbeats
an alle ihre Nachbarn
> Knoten leiten empfangene Heartbeats an alle anderen Nachbarn weiter
> Jeder Knoten wählt als Vater den Nachbarknoten, der der Wurzel am
nächsten liegt; bei Gleichheit wird der Knoten mit kleinerer ID gewählt
> Empfangener Heartbeat unterdrückt den Wunsch anderer Knoten,
Wurzel zu werden  rechtzeitige Zustellung sicherstellen
7
4
10
9
3
1
5
2
11
13
G. Mühl
12
14
15
VA / Fehlertoleranz
53
Selbststabilisierende Spannbaumkonstruktion –
Grundidee im Fehlerfall
> Fällt eine Verbindung aus, so bildet sich ein anderer Spannbaum mit
der gleichen Wurzel
> Fällt die Wurzel aus oder ist sie nicht mehr erreichbar, bildet sich ein
Spannbaum mit einer anderen Wurzel
> In beiden Fällen ist der Auslöser für das Bilden eines neuen
Spannbaums das Auftreten von Timeouts
> Ist der Fehler transient, so bildet sich nachdem z.B. der Knoten wieder
verfügbar ist, wieder der ursprüngliche Spannbaum aus
7
4
10
9
3
1
5
2
11
13
G. Mühl
12
14
15
VA / Fehlertoleranz
54
Selbststabilisierende Spannbaumkonstruktion
> Jeder Prozess P hat
> eine Variable PV, die auf einen seiner Nachbarn
(seinen Vater) zeigt
> eine Variable PW, die auf die aktuelle Wurzel zeigt
> eine Variable PL, die seinen Level im Baum angibt und
> eine Variable PF, welche bei einem Timeout ausgelesen und
evtl. verändert wird
> Ziel: Nach endlicher Zeit sollen die PV -Verweise aller Knoten
einen Spannbaum bilden
> Bemerkung zur nächsten Folien:
> (v1, v2, v3) < (w1, w2, w3)
⇔ v1 < w1 ∨ (v1 = w1 ∧ v2 < w2) ∨ (v1 = w1 ∧ v2 = w2 ∧ v3 < w3)
G. Mühl
VA / Fehlertoleranz
55
Selbststabilisierende Spannbaumkonstruktion
> Ein Knoten P empfängt eine Nachricht (w, l, i)
> Falls (PW, PL, Pv) < (w, l + 1, i) oder P < w, ignoriert er
die Nachricht
> Falls (PW, PL, Pv) = (w, l + 1, i), setzt er PF auf 2 und schickt
dann eine Nachricht (PW, PL, P) an alle anderen Nachbarn
> Ansonsten setzt er (PW, PL, Pv) := (w, l + 1, i) sowie PF := 2
und schickt dann eine Nachricht (PW, PL, P) an
alle anderen Nachbarn
> Bei einem Prozess P läuft der Timeout ρ ab
> Falls PF ≥ 2, setzt er PF := 1
> Falls PF = 1, setzt er PF := 0
> Falls PF ≤ 0 setzt er (PW, PL, Pv) := (P, 1, P), lässt PF unverändert
und schickt dann eine Nachricht (PW, PL, Pv) an alle Nachbarn
Fehlerfreier Fall
G. Mühl
Fehlerbehafteter Fall
VA / Fehlertoleranz
56
Selbststabilisierende Spannbaumkonstruktion
7
4
10
9
3
(1,1,1)
1
(9,1,9)
5
2
11
13
12
14
15
(Wurzel, Level, Vater)
G. Mühl
VA / Fehlertoleranz
57
Selbststabilisierende Spannbaumkonstruktion
7
(1,2,1)
4
Knoten 5 und 7
ignorieren die Nachricht
von Knoten 9!
9
3
(9,1,9)
5
(1,2,1)
10
(1,1,1)
1
2
11 (9,2,9)
(1,2,1) 13
12
(1,2,1)
14
15
(Wurzel, Level, Vater)
G. Mühl
VA / Fehlertoleranz
58
Selbststabilisierende Spannbaumkonstruktion
(1,3,3)
(1,3,3)
7
(1,2,1)
4
9
3
5
(1,2,1)
(1,3,3) 10
(1,1,1)
(9,1,9)
1
(1,3,2)
2
11 (9,2,9)
(1,2,1) 13
12
(1,2,1)
14
(1,3,2)
15
(9,3,11)
(Wurzel, Level, Vater)
G. Mühl
VA / Fehlertoleranz
59
Selbststabilisierende Spannbaumkonstruktion
(1,3,3)
(1,3,3)
7
(1,2,1)
4
9
3
5
(1,2,1)
(1,3,3) 10
(1,1,1)
(1,4,5)
1
(1,3,2)
2
11 (1,4,14)
(1,2,1) 13
12
(1,2,1)
14
(1,3,2)
15
(1,4,14)
(Wurzel, Level, Vater)
G. Mühl
VA / Fehlertoleranz
60
Eigenschaften des konstruierten Spannbaumes /
Nachweis der Konvergenz
> Der aufgebaute Spannbaum ist im fehlerfreien Fall eindeutig, da
> der Prozess mit der kleinsten Identität die einzige Wurzel wird und
> jeder Prozess außer der Wurzel denjenigen Prozess unter seinen
Nachbarn als Vorgänger wählt, welcher unter den Nachbarn mit
kleinstem Level die kleinste Identität hat
> Im fehlerfreien Fall dürfen nur die von der Wurzel getriggerten
Auffrischungsnachrichten unterwegs sein
> Das System ist in einem legalen Zustand, wenn
1. der Zustand der Prozesse dem obigen Spannbaum entspricht und
2. keine fehlerhaften Nachrichten mehr unterwegs sind
> Für die Konvergenz ist zu zeigen, dass das System startend aus
einem beliebigen Zustand einen legalen Zustand erreicht
G. Mühl
VA / Fehlertoleranz
61
Sicherstellung der Abgeschlossenheit
> Jeder Knoten außer der Wurzel muss immer wieder eine
Auffrischungsnachricht erhalten, jeweils bevor dieser sich selbst zur
Wurzel erklären würde
> Sei δmin die minimale und δmax die maximale Nachrichtenlaufzeit auf
einem Link und d die Länge des längsten Pfades in der Topologie
> Die Höhe des sich ergebenden Baumes ist immer kleiner als d
> Der maximale zeitliche Abstand zwischen zwei
Auffrischungsnachrichten tritt ein,
> wenn die Wurzel und der betrachtete Knoten maximal weit voneinander
entfernt sind (also d Hops) und
> die 1. Nachricht minimal ( d δmin) sowie
> die 2. Nachricht maximal ( d δmax) verzögert wird
G. Mühl
VA / Fehlertoleranz
62
Sicherstellung der Abgeschlossenheit
> Der Empfang der 1. Auffrischungsnachricht setzt
PF auf 2
> Der 1. Timeout kann direkt nach dem Empfang
auftreten; dieser setzt PF auf 1
> Die 2. Auffrischungsnachricht muss eintreffen,
bevor zwei weitere Timeouts auftreten
Wurzel
t1
ρ
2ρ > a1 - a0
⇒
t0
a0 = t0 + d δmin
a1 = t1 + d δmax
t1 = t0 + ρ
d δmax
2ρ > ρ + d (δmax - δmin)
1
2
⇒
Max.
d Hops
ρ > d (δmax - δmin)
d δmin
G. Mühl
a0
2ρ
a1
VA / Fehlertoleranz
63
Literatur
1.
2.
3.
4.
5.
G. Mühl
E. W. Dijkstra. Self-Stabilizing Systems in Spite of Distributed Control.
Communications of the ACM, 17(11):643--644, 1974.
S. Dolev. Self-Stabilization. MIT Press, 2000.
M. Schneider. Self-stabilization. ACM Computing Surveys, 25(1):45--67, 1993.
L. Lamport, R. Shostak, and M. Pease. The Byzantine Generals Problem.
ACM Transactions on Programming Languages and Systems, 4(3):382-401, 1982.
F. C. Gärtner. A survey of self-stabilizing spanning-tree construction algorithms.
Technical Report 200338, Swiss Federal Institute of Technology (EPFL),
School of Computer and Communication Sciences, Lausanne, Switzerland,
June 2003.
VA / Fehlertoleranz
64