Verteilte Systeme
Verteilte Systeme
Verteilte Systeme
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Begriffe<br />
<strong>Verteilte</strong> <strong>Systeme</strong><br />
Jürgen Nehmer, SS 2003<br />
Gruppenkommunikation:<br />
Grundlagen<br />
• Unicast<br />
– Message an genau einen Empfänger<br />
• Multicast<br />
– Message an eine Gruppe von Empfängern<br />
• Broadcast<br />
– Message an alle potentiellen Empfänger<br />
Sender<br />
1<br />
N Empfänger<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 1<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 2<br />
Wozu Multicast/Broadcast?<br />
• In einer verteilten Anwendung muss häufig mehreren<br />
Rechnern/Prozessen dieselbe Information geschickt werden<br />
– Aufforderung an alle Gruppenmitglieder: lokalen Zustand schicken<br />
– Zustand aller Gruppenmitglieder korrigieren (z. B. Uhrzeit)<br />
– neue Erkenntnis an alle Gruppenmitglieder verteilen<br />
• Beispiele für Gruppen<br />
– alle Rechner eines lokalen Netzes<br />
– alle Prozesse einer verteilten Anwendung<br />
• alle Prozesse eines Lastverbundes<br />
• alle Prozesse eines Funktionsverbundes<br />
• alle Prozesse eines Überlebensverbundes<br />
• alle Clients eines Client/Server-Verbundes<br />
• alle Server eines Client/Server-Verbundes<br />
Client<br />
Beispiel: <strong>Verteilte</strong>r Druck-Dienst (1)<br />
Belegen;<br />
Benutzen;<br />
Freigeben;<br />
Gruppe von Druck-Servern<br />
Server<br />
Lastverbund<br />
• Koordinierungsproblem zwischen der Gruppe der Clients und der Gruppe der Server<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 3<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 4
Beispiel: <strong>Verteilte</strong>r Druckdienst (2)<br />
Beispiel: <strong>Verteilte</strong>r Druckdienst (3)<br />
• Zentraler Gruppenkoordinator<br />
Client<br />
zentraler<br />
Koordinator<br />
• Nachteile:<br />
• Koordinator ist potentieller Engpass<br />
• Koordinatorausfall<br />
Gruppe von Druck-Servern<br />
Server<br />
Lastverbund<br />
• Client-basierte Gruppenkoordination<br />
• alle Clients bilden eine Gruppe<br />
• Zugriffskoordinierung z.B. durch verteilten kritischen Abschnitt<br />
Koordination<br />
• Nachteil: potentiell große Anzahl Clients<br />
Gruppe von Druck-Servern<br />
Server<br />
Lastverbund<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 5<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 6<br />
Beispiel: <strong>Verteilte</strong>r Druckdienst (4)<br />
Multicast-Varianten<br />
• Server-basierte Gruppenkoordination<br />
• alle Server bilden eine Gruppe<br />
• Koordination durch Einigungsprotokolle (agreement)<br />
Client<br />
multicast<br />
Anwendung<br />
Koordinator<br />
Anwendung<br />
Gruppe von Druck-Servern<br />
Koordinator<br />
Koordinator<br />
Anwendung<br />
Anwendung<br />
Koordinator<br />
Anwendung<br />
Anwendung<br />
Koordinator<br />
Koordinator<br />
• Sender-gesteuert<br />
– Sender bestimmt die Gruppenzusammensetzung (keine Gruppentransparenz)<br />
– Auflösung des Multicast in N Unicast-Operationen<br />
• Empfänger-gesteuert<br />
– Repräsentation der Gruppe durch eine Gruppenadresse<br />
– die Gruppenzusammensetzung bleibt den Sendern verborgen<br />
(Gruppentransparenz)<br />
– Realisierung durch Broadcast möglich<br />
• Prädikat-gesteuert<br />
– die Message erreicht alle Empfänger, bei denen die lokale Prädikatauswertung<br />
TRUE ergibt<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 7<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 8
API für einen Empfänger-gesteuerten Multicast-<br />
Mechanismus<br />
Zuverlässigkeitsgrade eines Multicast<br />
• groupId createGroup () //Erzeugen einer Gruppe; der Erzeuger wird erstes Mitglied<br />
• deleteGroup(groupId) // Vernichten einer Gruppe durch den Erzeuger<br />
• joinGroup(myPort, groupId) //Beitritt zu einer Gruppe<br />
• leaveGroup(myPort, groupId) //Verlassen einer Gruppe<br />
• sendGroup(groupId, message) //Multicast an eine Gruppe<br />
• receive(myPort, message) //Empfang einer Multicast-Message<br />
• Achtung: der Ausfall (Crash-Fehler) eines Prozesses hat dieselbe Wirkung wie der<br />
Aufruf von leaveGroup()<br />
• Best Effort<br />
– es wird keine Garantie gegeben, wie viele intakte Gruppenmitglieder die<br />
Nachricht erhalten<br />
• k-zuverlässig<br />
– es wird garantiert, daß mindestens k intakte Gruppenmitglieder die<br />
Nachricht erhalten<br />
• zuverlässig<br />
– es wird garantiert, daß alle intakten Gruppenmitglieder die Nachricht<br />
erhalten<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 9<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 10<br />
Ordnungsgrade beim Multicast<br />
• ungeordneter Multicast<br />
– keine Garantie über die Empfangsreihenfolge von Multicast-Nachrichten bei den<br />
Gruppenmitgliedern<br />
• FIFO-geordneter Multicast<br />
– Sendet ein Prozess erst die Multicast-Nachricht m 1<br />
und anschließend die<br />
Multicast-Nachricht m 2<br />
, dann müssen alle Gruppenmitglieder die Nachrichten in<br />
der Reihenfolge m 1<br />
,m 2<br />
empfangen<br />
• kausal geordneter Multicast<br />
– empfängt ein Gruppenmitglied erst die Multicast-Nachricht m 1<br />
und sendet dann<br />
die Multicast-Nachricht m 2<br />
, dann müssen alle Gruppenmitglieder diese in der<br />
Reihenfolge m 1<br />
, m 2<br />
empfangen<br />
• total geordneter Multicast<br />
– empfängt ein Gruppenmitglied eine Multicast-Nachricht m 1<br />
und danach die<br />
Multicast-Nachricht m 2<br />
, dann müssen alle übrigen Gruppenmitglieder diese in<br />
der Reihenfolge m 1<br />
→ m 2<br />
empfangen<br />
Gruppe<br />
Beispiel: FIFO- geordneter Multicast<br />
a) korrekt b) Verletzung<br />
m 1 m 2 m 1 m 2<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 11<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 12
Beispiel: kausal geordneter Multicast<br />
Beispiel: total geordneter Multicast<br />
a) korrekt b) Verletzung<br />
a) korrekt b) Verletzung<br />
m 1<br />
m 2<br />
m 1<br />
m 2<br />
m 1<br />
m 2<br />
m 1<br />
m 2<br />
Gruppe<br />
Gruppe<br />
• Ein total geordneter Multicast ordnet kausal unabhängige Multicast-Nachrichten auf<br />
Empfänger-Seite<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 13<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 14<br />
Offene und geschlossene Gruppen<br />
• Geschlossene Gruppe<br />
– Multicast ist nur innerhalb einer Gruppe definiert und zulässig<br />
• Offene Gruppe<br />
– Die Gruppe kann von außen über eine Multicast-Nachricht angesprochen werden<br />
– inhärentes Problem offener Gruppen:<br />
• wie gewinnt der außerhalb der Gruppe angesiedelte Sender eine konsistente<br />
Gruppensicht?<br />
Sender<br />
Koordinator<br />
offene Gruppe<br />
Einigungsprotokolle<br />
Einigungsprotokolle (Agreement-Protokolle) erzwingen unter gleichberechtigten<br />
Mitgliedern einer Gruppe die Einigung auf eine konsistente Sicht<br />
• Beispiele<br />
– Wer darf als nächster auf eine Ressource zugreifen?<br />
– Wer darf den nächsten Auftrag bearbeiten?<br />
– Wer geht als Sieger aus einem Wettbewerb hervor? (Leader-Election-<br />
Problem)<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 15<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 16
Leader-Election mittels Broadcast<br />
• Jeder Prozess besitzt zwei lokale Variable:<br />
L enthält am Ende die PID des Siegers (initial= undefiniert)<br />
K speichert ein Vergleichskriterium (K i<br />
≠K j<br />
für alle i,j, das größte K gewinnt)<br />
Leader-Election auf logischen Ringen<br />
P 1 P 2 P 3 P n<br />
• Initiator P i<br />
L=i;<br />
broadcast (K,i);<br />
• Empfänger P r<br />
receive (K ext<br />
,L ext<br />
);<br />
if (K>K ext<br />
) {L=r; broadcast (K,r)}<br />
else L=L ext<br />
;<br />
Bei globaler Terminierung enthält L jedes Prozesses den Sieger<br />
• Modellannahmen:<br />
– asynchrones Systemmodell<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 17<br />
• Initiator P i<br />
L=i;<br />
send (K,i) to P i+1 mod n<br />
;<br />
• Empfänger P r<br />
receive (K ext<br />
,L ext<br />
);<br />
if (K>K ext<br />
) {L=r; send(K,r) to P r+1 mod n<br />
}<br />
else if (K
<strong>Verteilte</strong>r Druckdienst mittels Leader-Election:<br />
Der Client<br />
<strong>Verteilte</strong>r Druckdienst mittels Leader-Election:<br />
Auftragsempfang bei einem Server<br />
client {<br />
sendGroup(druckserverGroup, druckTask);<br />
receive (ackNachricht);<br />
}<br />
taskReceive (task) {<br />
if (task ⊂ missing) remove task from missing;<br />
else {<br />
add task to taskQ;<br />
if !busy {<br />
contention-Nachricht mit taskId, MyPID, MyPrio an<br />
rechten Ringnachbarn senden;<br />
}<br />
}<br />
}<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 21<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 22<br />
<strong>Verteilte</strong>r Druckdienst mittels Leader-Election:<br />
Ankunft einer contention-Nachricht beim Server<br />
<strong>Verteilte</strong>r Druckdienst mittels Leader-Election:<br />
Ankunft einer contention-Nachricht beim Server<br />
contentionReceive (c) {<br />
if (c.PID == MyPID) {<br />
busy = true;<br />
activeTask = Top(taskQ);<br />
Druckauftrag(activeTask) bearbeiten;<br />
send (clientId, ACK);<br />
delete activeTask;<br />
busy = false;<br />
{<br />
else { //fremde contention-Nachricht<br />
if (c.taskId ⊄ taskQ) {//task ist unbekannt<br />
add c.taskId zu missing;<br />
c weiterleiten auf Ring;<br />
}<br />
else {//task ist bekannt<br />
if (!Konflikt) {//kein Wettbewerb um diesen Auftrag<br />
remove c.taskId from taskQ;<br />
c weiterleiten auf Ring;<br />
}<br />
else {//Konflikt, d h. Wettbewerb um den Auftrag<br />
if (MyPrio < c.Prio) {//ich bin Verlierer<br />
remove c.taskId from taskQ;<br />
c weiterleiten;<br />
}<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 23<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 24
<strong>Verteilte</strong>r Druckdienst mittels Leader-Election:<br />
Ankunft einer contention-Nachricht beim Server<br />
Nachrichtenkomplexität<br />
}<br />
}<br />
}<br />
}<br />
else {//ich bin der Sieger<br />
//fremde contention-Nachricht wird<br />
//vernichtet<br />
}<br />
}<br />
• Best Case<br />
– exakt ein Server bewirbt sich um einen neu eintreffenden Auftrag<br />
N Nachrichten (1 Umlauf einer contention-Nachricht)<br />
• Worst Case<br />
– alle Server bewerben sich um einen neu eintreffenden Auftrag<br />
P N<br />
bewirkt N contention-Nachrichten (Sieger)<br />
P N-1<br />
bewirkt N-1 contention-Nachrichten<br />
P N-2<br />
bewirkt N-2 contention-Nachrichten<br />
P 1<br />
bewirkt 1 contention-Nachricht<br />
Σ = N(N+1)/2 contention-Nachrichten<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 25<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 26<br />
Literatur<br />
D. Wybranietz: Multicast-Kommunikation in verteilten <strong>Systeme</strong>n, Informatik-<br />
Fachberichte 242, Springer-Verlag 1990<br />
<strong>Verteilte</strong> <strong>Systeme</strong>-VI 27
Change language