Verteilte Systeme

Prof. Dr. Th. Letschert
CS5001
Verteilte Systeme
Master of Science (Informatik)
- asynchrone Algorithmen -
© Th Letschert FH Gießen-Friedberg
Verteilte Systeme
Modelle verteilter Berechnungen :
asynchrone Algorithmen
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
2
Beispiel: GGT-Algorithmus
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
3
Beispiel: ggt-Algorithmus in asynchronem Modell
Verteilte Berechnung des GGT
P
4
Verteilter Algorithmus:
P:
v = Startwert;
do for all P: P ist Nachbar {
P!v;
}
do for all P : P ist Nachbar {
P ? nv ­> if nv < v {
do {
v>nv ­> v = v ­ nv;
nv>v ­> nv= nv ­ v;
}
do for all P: P ist Nachbar {
P!v;
}
}
}
Kontroll-orientierte Notation
Dr. Th. Letschert, FH Gießen
Beispiel: Topologie und
Startwerte
R
9
Q
6
P:
v = Startwert;
send v to all Neighbors
upon receive nv =>
if nv < v {
v = ggt(v, nv);
send v to all Neighbors
Verteilte Systeme
Ereignis-orientierte Notation
(mehr informal)
4
Beispiel: ggt-Algorithmus in asynchronem Modell
Verteilte Berechnung des GGT
Zeitlicher Ablauf: Zeitdiagramm
1=ggt(4,9)
1
P: 4
9
4
Q: 6
6
3
2
1
2
3
1
1
1
1
R: 9
SendeEreignis
EmpfangsEreignis
internes
Ereignis
P
Zeit
Topologie
Welche Zeitdiagramme sind möglich?
Wovon hängt das Verhalten ab?
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
R
Q
5
Beispiel: ggt-Algorithmus in asynchronem Modell
Verteilte Berechnung des GGT
Nichtdeterministisch
aktuelles Verhalten hängt ab vom Zeitverhalten
der Prozesse (Dauer lokaler Aktionen)
der Laufzeit der Nachrichten
asynchron: Zeitverhalten unbestimmt
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
6
Beispiel: ggt-Algorithmus in asynchronem Modell
Verteilte Berechnung des GGT
Terminierung
Terminiert der Algorithmus:
Wenn alle den gemeinsamen GGT kennen ?
Wenn keine zwei Prozesse das gleiche v haben ?
Wenn das System einen stabilen Zustand hat ?
Welche Kriterien sind äquivalent?
Wie kann man feststellen, ob die Kriterien erfüllt sind?
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
7
Beispiel: ggt-Algorithmus in asynchronem Modell
Verteilte Berechnung des GGT
Beobachten des Algorithmus'
Kann ein Beobachter feststellen ob der Algorithmus terminiert ist?
... ob alle Prozesse das gleiche v haben ?
... ob das System einen stabilen Zustand hat ?
Was bedeutet Terminierung in einem verteilten System?
P: 4
9
4
Q: 6
6
3
2
1
3
2
1
1
1
Kein alles
sehender und
alles wissender
Beobachter.
1
R: 9
Beobachter
Dr. Th. Letschert, FH Gießen
Beobachtungs
Ereignisse
Verteilte Systeme
8
Beispiel: Broadcast-Algorithmen
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
9
Broadcast
Broadcast
–
–
Aufgabe:
● Informiere alle Knoten im Netz, so dass
– jeder irgendwann informiert ist
und
– Nachrichten nicht sinnlos / endlos im Netz kreisen
Modell / Anwendung:
●
Netztopologie
●
●
●
●
●
Kommunikation
●
●
●
Punkt-zu-Punkt (kein Broadcast-Medium)
stabil
(keine Änderungen)
verbunden
(jeder ist erreichbar)
ansonsten beliebig
asynchron
sicher
(beliebige/endliche Laufzeit)
(kein Verlust/Verfälschung
kein globaler Zustand/Beobachter
●
kein Knoten kennt die Topologie
(kein zentraler Knoten, Problem sonst trivial)
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
10
Broadcast: Fluten
Broadcast-Algorithmus „Fluten“ (Flooting)
– Fluten Teilnehmer
●
●
–
Initiator:
Empfänger:
Info an alle ohne dass
ein „Routing“ vorausgesetzt
wird: Basis-Algorithmus für
Router.
Ausgang der Nachricht
alle anderen
Algorithmus
●
Initiator
sendet an all seine Nachbarn
Empfänger
–
●
–
–
–
informiert = false
empfange Nachricht
falls informiert = false:
● informiert = true
● Nachricht speichern
● sende Nachricht an alle Nachbarn,
außer an den, von dem sie kam
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
Ereignis-orientierte
Notation
Ereignis für Initiator:
„spontan“,
d.h. Anstoß von
außerhalb des Systems
~ spontanes Ereignis.
11
Broadcast: Fluten / etwas formaler
Initiator
informed = false
SpontaneousEvent(I) =>
send(I) to all Neighbors
informed = true
Receiver
informed = false
receive(I) from N =>
if not informed
send(I) to all Neighbors except N
informed = true
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
12
Broadcast: Fluten
Eigenschaften „Fluten“ (Flooting)
– werden alle informiert ?
–
Terminierung ?
der Algorithmus endet :=
Es sind keine Nachrichten mehr unterwegs
dabei aber kein Deadlock
–
Terminierungs-Erkennung:
wann kann der Initiator sicher sein, dass
alle informiert sind?
–
globale Informiertheit => Terminierung !
wenn alle informiert sind, endet der Algorithmus.
–
Terminierung ╪> Informiertheit
aus der Terminierung allein kann nicht geschlossen werden,
dass informiert sind.
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
13
Broadcast: Fluten
Eigenschaften „Fluten“ (Flooting)
2*e – n + 1 Nachrichten werden gesendet ?
–
System mit n Knoten (Nodes) und e Kanten (Edges)
Kante = bidirektionaler Kanäle
–
jeder Knoten sendet auf allen Kanten
● e Kanten -> 2*e Nachrichten
(hin/her)
außer auf seiner Eingangs-Kante
● 2*e – n
(jeder Knoten hat eine Eingangs-Kante)
–
–
außer dem Initiator, der auf allen Kanten sendet
● 2*e – n + 1 Nachrichten
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
14
Terminierung: Lokal und Verteilt
●
lokale Terminierung: (lokaler) Prozess terminiert
definierter Endzustand erreicht, keine Aktion mehr möglich
●
Verteiltes System / verteilter Algorithmus terminiert
Definition
alle Prozesse sind terminiert, oder
stabiler Endzustand erreicht
keine Aktivität in Prozessen (müssen dazu nicht terminiert sein) und
keine Nachrichten unterwegs
Erkennung
Explizite Terminierung (Prozess-Terminierung)
Ein / alle Prozess(e) ist / sind in einem Zustand an dem er / sie die (globale)
Terminierung erkennt / erkennen
Implizite Terminierung (Nachrichten-Terminierung)
Stabiler Endzustand ist erreicht, ohne dass ein Prozess dies explizit weiß
Deadlock
stabiler Zustand erreicht,
der aber nicht Endzustand ist (Berechnungsziel nicht erreicht)
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
15
Terminierungserkennung
Erkennen der Terminierung
Algorithmus mit expliziter (Prozess-) Terminierung verwenden
schwieriger Algorithmen
Terminierung entdecken und bekannt geben
Algorithmus A : Berechnen
Algorithmus A mit impliziter (Nachrichten-) Terminierung berechnet Aufgabe
Algorithmus B: Erkennen
Algorithmus B beobachtet Algorithmus A und erkennt die Terminierung
Algorithmus C: Bekanntgeben
Algorithmus C wird von B informiert und gibt die Terminierung bekannt
Bekanntgabe der Terminierung
Broadcast-Algorithmus notwendig
Fluten als Broadcast-Algorithmus geeignet ?
muss selbst explizit terminieren
Broadcast mit expliziter Terminierung
Werkzeug der Terminierungserkennung
Bestandteil anderer Algorithmen
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
16
Terminierungserkennung
Fluten: Erkennen der Terminierung
Initiator informieren
wenn Info eintrifft -> Nachricht an Initiator, Initiator zählt Bestätigungen
Problem: Initiator nicht direkt erreichbar
Problem: Initiator muss wissen, wie viele Knoten im Netz sind
Überlagerung mit Beobachtungs- / Informationsalgorithmus
Problem: welche Überlagerungsalgorithmen
Modifikation des Algorithmus
aus Broadcast mit impliziter Terminierung
Broadcast mit expliziter Terminierung machen
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
17
Broadcast: Echo-Algorithmen
Echo-Algorithmus = Fluten mit Quittung
– Wozu:
–
●
Initiator soll erfahren, wenn alle informiert sind
●
Broadcast mit expliziter Terminierung
Problem:
●
Initiator kann nicht von jedem direkt informiert werden
(Modell: keine globale Topologie-Kenntnis /
keine Direktverbindung aller Knoten)
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
18
Broadcast: Echo-Algorithmen
Echo-Algorithmen / Prinzip
– Empfänger quittieren den Empfang von Nachrichten
–
derart dass
●
der Initiator nicht alle Quittungen sammeln muss, sondern
●
jeder Knoten eine Pflicht
zur Information seiner Nachbarn erhält
– diese erfüllt
– und diese Erfüllung bestätigt
Initiator weiß dass alle informiert sind
–
●
–
wenn er eine Quittung von jedem seiner Nachbarn erhalten hat
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
19
Echo-Algorithmen: PIF
PIF-Algorithmus (ein Echo-Algorithmus)
Fluten mit Quittungsmeldungen („Echos“) :
Echo-Algorithmus / PIF-Algorithmus
(PIF: Propagation of Information with feedback)
●
Initiator:
●
●
●
Der Initiator sendet Info-Pakete an alle Nachbarn
Wenn von allen Nachbarn eine Nachricht gekommen ist,
ist der Broadcast beendet.
sonstiger Knoten / Empfänger:
● empfängt (und zählt dabei) Nachrichten von allen Nachbarn.
Merkt sich den Nachbar f, von dem die erste Nachricht kam
● Nach Empfang der ersten Nachricht von Nachbar f wird diese
an allen anderen Nachbarn weiter gesendet
● Wenn von jedem Nachbarn eine Nachricht eingetroffen ist,
wird an f eine Echo-Nachricht gesendet.
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
20
Broadcast: PIF-Algorithmus
PIF-Algorithmus im Detail
●
●
Zwei Arten von Nachrichten
●
Explorer-Nachricht:
verbreitet Info
●
Echo-Nachricht:
Rückmeldung
Drei Knotenzustände
●
Weiss:
Urzustand, weiß von nichts
●
Rot:
Hat Explorer-Nachricht empfangen, ist
informiert
●
Grün:
Hat Echo gesendet, fertig
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
21
Broadcast: PIF-Algorithmus
Initiator-Knoten
count = 0
state = white
foreach n in Nachbarn:
send Explorer­Msg to n
do {
count != #Nachbarn ­>
receive msg from Nachbar n
if state == white {
state = red
}
count = count+1 }
state = green
fertig
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
22
Broadcast: PIF-Algorithmus
Empfänger-Knoten
count = 0
state = white
f = ? // VorgängerKnoten
do { count != #Nachbarn ­>
receive msg from Nachbar n
if state == white {
state = red
f = n
foreach n in Nachbarn:
send Explorer­Msg to n
}
count = count+1 // für jede Art von Nachricht
}
state = green
send Echo­Msg to f
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
23
Echo-Algorithmus
Wellen-Algorithmus / virtueller Broadcast
Rot ausdehnen, Grün schrumpfen
starten
fertig
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
24
Echo-Algorithmus uns Spannbaum
Echo-Algorithmus berechnet implizit einen Spannbaum des Netzes
●
Spannbaum (Spanning Tree):
zykelfreier verbundener Sub-Graph der alle Knoten enthält
●
Anwendung
●
Netztechnik: Brücken/Switches berechnen verteilt Spannbaum des Netzes
●
generell: mit Spannbaum effiziente Broad- oder Multicasts möglich
Netz
mit Spannbaum
und Wurzel des
Spannbaums
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
25
Echo-Algorithmus uns Spannbaum
Echo-Algorithmus: Spannbaum-Berechnung
●
Initiator = Wurzel
●
Konten:
●
●
f (Vorgänger) definiert Richtung zur Wurzel
Kante über die Echo kommt definiert Richtung nach außen
Explorer in beide
Richtungen, aber jeweils
nicht die ersten.
erste Explorer-Nachr.
zum Ziel-Knoten
Echo
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
26
Echo-Algorithmus uns Spannbaum
Echo-Algorithmus: Spannbaum-Berechnung
●
●
●
●
f (Vorgänger) definiert Richtung zur Wurzel
Kante über die Echo (grüne Kante) kommt definiert Richtung nach außen
grüne Kanten spannen Baum auf.
Über jede Kante laufen 2 Nachrichten:
Kante mit 2 Explorer-Nachrichten
● Explorer- und Echo- oder
● Zwei Explorer-Nachrichten
Kante mit Explorer- und Echo-Nachricht
Echo
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
27
Echo-Algorithmus und Spannbaum
Echo-Algorithmus: Spannbaum-Berechnung
●
Spannbaum ist optimal
●
Verfahren ist nicht-deterministisch
gesteuert durch Geschwindigkeit der Verbindungen / Knoten
langsamer Weg
schneller Weg
erste Explorer-Nachr.
zum Ziel-Knoten
X
Echo
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
28
Broadcast
Broadcast in speziellen Topologien
●
spezielle Topologien begünstigen spezielle Broadcast-Algorithmen
3
2
3
2
3
3
1
Kreis:
Token kreisen
lassen
Dr. Th. Letschert, FH Gießen
Kubus:
dimensionsweise
im Takt
Verteilte Systeme
29
Broadcast
●
●
Anwendung
Informationsverteilung in Netzen
●
ohne Broadcast-Medium
●
ohne Verwendung von Routing-Algorithmen
Beispiele
– Bestandteil von Link-State Routing-Algorithmen
Verbreitung der Link-State Information
–
Bestandteil von anderen verteilten Algorithmen
Verbreitung von Berechnungs-Ergebnissen
–
Generell: Alle Teilnehmer in einem Nicht-Broadcast-Netz
auf einfache Art informieren
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
30
Broadcast
Modell passt nicht zur Realität
–
–
–
Netztopologie; Modell passt nicht
●
nicht Punkt-zu-Punkt:
Problem existiert nicht
●
nicht stabil:
andere Algorithmen / ignorieren
●
nicht verbunden:
geht nicht
●
nicht beliebig:
spezielle Algor. für spez. Topologien (z.B. Ring)
Kommunikation; Modell passt nicht
●
synchron
um so besser
●
nicht sicher
anderes / weiters Probem: Fehlerkontrollprotokoll
globaler Zustand/Beobachter; Modell passt nicht
●
ein zentraler Knoten
kennt die Topologie
Dr. Th. Letschert, FH Gießen
um so besser,
Zentrale sendet an alle
Verteilte Systeme
31
Routing
Distance-Vector Routing
–
Prinzip:
–
Verteilte Berechnung der Routing-Tabelle eines Netzes
● durch Austausch der jeweiligen lokalen Information
Routing:
●
Routing-Tabelle: Darstellung der Netztopologie
Routing-Algorithmus: verteilte Berechnung der Netztopologie
durch alle Netzknoten
Varianten
Link-State Verfahren
Phase 1: Globale Verteilung der lokalen Information
über die Schnittstellen eines Knotens
Phase 2: lokale Berechnung der Tabelle (der Netztopologie)
Distance-Vector Verfahren
iteratives Verfahren: Austausch der Routingtabellen
mit deren sukzessiver Verbesserung
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
32
Routing
Distance-Vector Routing
Verfahren:
Jeder Knoten (Router) kennt den Weg zu seinen direkt
angeschlossenen Sub-Netzen
Weg = Kosten: Entfernung / Leitungskapazität / ....
Alle Router senden ihr Wissen an alle Nachbarn
Jeder Router speichert die letzte Info von jedem Nachbarn
und berechnet damit seine Routing-Tabelle
Jede Veränderung wird an alle Nachbarn versendet
Geht die Verbindung zum Nachbarn verloren, dann wird die
Tabelle ohne dessen Info neu berechnet
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
33
Distance-Vector Routing
3
B
D
1
4
1
1
C
E
4
A
1
9
Ziel
F
E
D
B
Empfang eines Vektors v über eine Verbindung
mit Distanz d von Knoten n:
Für jede Zeile z im eigenen Vektor t:
Falls v[z].entf + d < t[z].entf:
t[z].entf = v[z].entf + d
t[z].über = n
Falls sich Tabelle t verändert hat:
Sende t an alle Nachbarn außer n
Entf: über
9
4
1
1
-
F
F:9
E:4
D:1
B:1
Distanz-Vektor
wird gesendet
Tabelle
wird berechnet
(hier Init-Konfig.)
Dr. Th. Letschert, FH Gießen
Terminierung ?
Toplogie-Änderungen ?
Verteilte Systeme
34
Distance-Vector Routing
●
Ältestes verteiltes Routing Protokoll im Internet
–
RIP-Protokoll
–
robust, einfach, langsam
–
count-to-infinity Problem
●
nach Topologie-Änderungen eventuell nicht terminierend
A
B:1
C : 2 via B
B:1
C : 4 via B
B
B:1
C:2
B:1
C:3
B:1
C:4
C
Ausfall
B:1
C:1
B:1
C : 3 via C
B:1
C : 5 via C
Lösung:
∞ = 25
etc. bis C: ∞
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
35
Routing: Link-State-Routing
Moderne Routing-Protokolle basieren auf
●
Link-State Protokollen und sind
●
viel komplexer
●
Internet, als es noch dem
DoD gehörte
„Arpanet incident“ 27.10.1980 Totalausfall
wegen eines (!) kaputten Routers
(Fehler in Broadcast-Phase !) mit
●
●
Byzantinischem Fehlverhalten
●
Fehler ohne Ausfall
Byzanz
(ab 29.5.1453) Istambul;
Byzantinismus =
Intrige, allgegenwärtiger
Verrat
Link-State Protokolle heute
●
wichtig, z.B. OSPF
●
basieren auf einem
verbesserten/“bewiesenem“ Algorithmus von
Radia Perlman und Nancy Lynch
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
36
Klasse verteilter Algorithmen: Verteilte Approximation
Verteilte Approximation (Distributed Approximation)
–
Prinzip:
●
●
–
–
Informiere alle Nachbarn
Bei Eintreffen einer Nachricht
● berechne lokal neuen Zustand
● informiere (alle) Nachbarn
falls sich dabei eine Verbesserung
ergeben hat
Beispiel:
●
Verteilter GGT
●
Broadcast-Algorithmus
●
Distance-Vector Routing
Eigenschaften:
●
Nichtdeterministisch
●
Topologie: vollständig verbunden / bidirektionale Kanten
●
Terminierungsproblem
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
37
Klasse verteilter Algorithmen: Wellen-Algorithmen
Wellen-Algorithmen (Wave Algorithms)
–
Definition:
i. Terminierung: Jede Berechnung ist endlich
ii. Entscheidung: Jede Berechnung enthält mindestens eine Entscheidung
iii. Abhängigkeit: Jede Entscheidung ist beeinflusst von einem Ereignis in
jedem Knoten
–
Beispiel:
●
z.B. PIF:
–
–
–
Termination:
Ausführung ist endlich
Entscheidung: und muss mit einer „Grün-Färbung“ der Wurzel enden
Abhängigkeit: dieser geht ein Berechnungsschritt in jedem Knoten
voraus.
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
38
Klasse verteilter Algorithmen: Verteilte Infimum-Berechnung
Infimum-Berechnung (Infimum Computation)
–
Definition:
Infimum-Funktion:
(X, ≤) ist eine halbgeordnete Menge
c = inf(a,b) falls c ≤ a, c ≤ b, ∀d, d ≤ a, d ≤ b: d ≤ c
Wenn das Infimum immer existiert ist es eindeutig und seine
Berechnung kommuntativ und assoziativ
Infimum-Berechnung:
Eine Infimum-Berechnung f startet mit mit einem
Wert xP ε X in jedem Prozess P
Einer / mehrere / alle Prozesse berechnen irgendwann nach endlicher
Zeit
x = f(xP1, xP2, ... xPn)
Diese Prozesse wissen, dass die Berechnung zu Ende ist und geben
das Ergebnis aus.
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
39
Klasse verteilter Algorithmen: Verteilte Infimum-Berechnung
Infimum-Berechnung (Infimum Computation)
Satz 1:
Jeder verteilte Infimum-Algorithmus ist ein Wellen-Algorithmus.
Satz 2:
Jeder Wellenalgorithmus kann benutzt werden, um eine Infimum-Funktion zu
berechnen.
Dr. Th. Letschert, FH Gießen
Verteilte Systeme
40