Verteilte Systeme Sommersemester 2007 - Zusammenfassung - Karsten Otto.

Präsentation zum Thema: "Verteilte Systeme Sommersemester 2007 - Zusammenfassung - Karsten Otto."—  Präsentation transkript:

1 Verteilte Systeme Sommersemester 2007 - Zusammenfassung - Karsten Otto

2 Kapitel 1: Einführung und Übersicht
Def.: Verteiltes System (distributed system) : ( = nichtsequentielles System ) Prozessoren bzw. Prozesse haben keinen gemeinsamen Speicher und müssen daher über Nachrichten kommunizieren Eventuelle weitere charakteristische Eigenschaften der Teilsysteme:  Fehlerunabhängigkeit  Autarkie, d.h. Teilsysteme sind isoliert funktionsfähig  Autonomie, d.h. getrennte Verwaltung 

3 Kapitel 1: Einführung und Übersicht
Beherrschung verteilter Systeme durch: Verbergen der schwierigen Problembehandlung durch Bereitstellung geeigneter Abstraktionen für komfortable Anwendungsprogrammierung

4 Kapitel 2: Kommunikationssysteme
Stern Punkt-zu-Punkt Bus Ring

5 Actual data transmission path Presentation layer
Sender Receiver Data AH Data Application layer Actual data transmission path PH Data Presentation layer SH Data Session layer TH Data Transport layer NH Data Network layer DH Data DT Data link layer Bits Physical layer

6 Kapitel 2.3: Nachrichtensemantik
Pseudocode für Senden und Empfangen: send MsgExpr [ to DestExpr ] Typ T Typ D<T> recv MsgVar [ from SourceExpr | SourceVar ] Typ T Typ S<T> Pufferung: keine, begrenzt, ungebrenzt Empfangsfolge: permutiertes Präfix, FCFS, Strom Zuverlässigkeit: Duplizierung, Verlust, Verstümmelung Flußsteuerung/ blockierend, nicht blockierend Synchronisation: synchron, asynchron

7 Kapitel 2.3.2: Adressierung
Beachte: Kommunikation ist nicht beschränkt auf das Szenario „2 miteinander verbundene Kommunikationspartner“ 4 Varianten:  ohne Adressierung  prozessbezogen  prozessgruppenbezogen  kanalbezogen

8 Kapitel 2.3.4: Disjunktives Warten
Besser: nichtdeterministisch disjunktives Warten for(;;) { ... select recv request from client; send subrequest to server; | recv subresult from server; send result to client; | timeout t do cleanup endselect; ... } t = 0 wirkt wie ein otherwise/else-Konstrukt t = wirkt wie fehlende Timeout-Klausel

9 Kapitel 2.4: Kommunikationsdienste des Betriebssystems
Interprozesskommunikation (inter-process communication, IPC) am Beispiel Unix Threads Prozesse Kommunizierende Threads Kommunizierende Prozesse Netzkommunikation BS BS HW HW è IPC: Pipes è Netz: Sockets (DGRAM, STREAM, ...)

10 Kapitel 2.4.3: Nichtsequentielle Server
Server kann auch mehrere Dienste anbieten, z.B. für jeden Dienst ein eigener Port ! Realisierung: a) sequentiell: disjunktives Warten auf Verbindungswünsche über alle angebotenen Ports b) nichtsequentiell: je Port ein (statischer) Thread, darin sequentielle Bearbeitung c) nichtsequentiell: disjunktives Warten + (dynamische) Threads, ein Thread (aus Pool) pro Verbindung d) nichtsequentiell: disjunktives Warten + Prozesse, neu erzeugter Prozess pro Verbindung

11 Kapitel 3: Netzdienste Klient Dienst Port Prot. Socket Login Programm
daytime daytime tcp/udp stream root daytimed ftp ftp 21 tcp stream root ftpd ssh ssh 22 tcp stream root sshd mailtool smtp 25 tcp stream root sendmail browser http 80 tcp stream root httpd rlogin login 513 tcp stream root rlogind rsh rsh 514 tcp stream root rshd rcp (meist in /usr/sbin) tcp/udp: ZWEI Sockets mit GLEICHER Portnummer

12 Kapitel 3.2.1: Fernerzeugung und Internet Superserver
Internet Superserver (auch „Internet Daemon“, Programm inetd ) bedient alle wohlbekannten Ports (gemäß 2.4.3), erzeugt Prozesse (gemäß 2.4.3d), die jeweils portspezifisches Programm ausführen (gemäß 3.1) Typische Arbeitsweise nach dem fork : - erzeugten Socket auf Standard-E/A 0, 1, 2 legen, - exec für erforderliches Programm (z.B. ftpd) ausführen - Programm arbeitet wie bei lokaler IPC

13 Kapitel 4: Kommunikationsplattformen, PVM, MPI
Kommunikationsplattformen (middleware) - einsetzbar in heterogenen Rechnernetzen - in Java, C, Fortran, ... über Bibliotheken benutzbar Ziele: Nachrichtendienst unabhängig von Betriebssystem und Netz automatische Typkonversion für übertragene Daten komfortable Prozessverwaltung und damit Eignung für Parallelprogrammierung im Netz Plattform BS1 BS2 BSn HW1

14 Kapitel 5: Verteilte Algorithmen
Def.: Verteilter Algorithmus Prozesse kooperieren zwecks Erreichung eines gemeinsamen Ziels  in verschiedenen oder gleichen Rollen, mit bestimmten, vereinbarten Interaktionsmustern = "Protokoll"  Meist in Pseudocode formuliert, mit prozessbezogener Adressierung  Behandelt häufig Fehlertoleranz bei unzuverlässigen Prozessen oder unzuverlässiger Kommunikation

15 Kapitel 5.1: Zeit und Kausalität
Def.: Kausale Abhängigkeit Zwei Ereignisse a,b  E stehen in der Beziehung a  b („a vor b“, „a happened before b“, „b ist kausal abhängig von a“) zueinander, wenn gilt: entweder 1) a und b gehören zum selben Prozess und geschehen in dieser Reihenfolge oder 2) a ist das Senden einer Nachricht, b ist das Empfangen dieser Nachricht oder 3) es gibt ein Ereignis c mit a  c und c  b (Transitivität von )

16 Kapitel 5.1.2: Logische Uhren
1. Versuch: Skalare Zeit [Lamport 1978] T = natürliche Zahlen Jeder Prozess - führt in einer lokalen Uhr eine lokale Zeit c (anfangs 0) - versieht jede versendete Nachricht mit Zeitstempel (timestamp) t = c.  Vor jedem Ereignis wird c um 1 erhöht.  Nach recv mit Zeitstempel t wird c auf max(c,t+1) gesetzt. Bemerkung: Hängt man an die Skalarzeit noch die Prozessnummer an, so kann man die Ereignisse gemäß dieses Schlüssels linear anordnen – verträglich mit ihrer Kausalordnung („topologisches Sortieren“). 5B < 5C

17 Kapitel 5.1.2: Logische Uhren
2. Versuch: Vektorzeit [Fidge, Mattern 1988] T = n-Tupel natürlicher Zahlen (bei n Prozessen 1,..,n) t  s : ti  si für alle i=1,..,n  Halbordnung ! Jeder Prozess p - führt in einer lokalen Uhr eine lokale Vektorzeit c (anfangs (0,0,..) ), - versieht jede versendete Nachricht mit Zeitstempel t = c.  Vor jedem Ereignis wird cp um 1 erhöht.  Nach recv mit Zeitstempel t werden für alle i=1,..,n die ci auf max(ci,ti) gesetzt.

18 Kapitel 5.2: Gruppenkommunikation
In welcher Reihenfolge treffen Rundrufe bei den Empfängern ein? ungeordnet: keine Anforderung (d.h. nicht unbedingt FIFO)  FIFO: mehrere Nachrichten eines Senders kommen in der Reihenfolge ihres Absendens bei allen Empfängern an. (Wie bei Unicast leicht durch Folgenumerierung zu gewährleisten.)  Kausalordnung (causally ordered, virtually synchronous) : FIFO bei allen Nachrichten, die in einer Kausalitätskette gesendet werden.  Totale Ordnung (loosely synchronous) : Alle Nachrichten kommen überall in der gleichen Reihenfolge an.

19 FIFO ungeordnet total (a,b oder b,a) kausal a b a a b b b b a b a b a

20 Kapitel 5.2.2: Kausalordnung mit CBCAST
Vor.: Zuverlässige Nachrichtenübertragung (!)  Prozess p erhöht in seiner „Vektorzeit“ P vor dem Senden Pp um 1 und heftet dann P als Zeitstempel t an die Nachricht an.  Eine von p bei q eintreffende Nachricht mit Zeitstempel t wird vom Nachrichtensystem solange zurückgestellt (d.h. nicht abgeliefert), bis gilt: tp = Qp + 1 (garantiert FIFO-Ordnung) und ∀ i ≠ p: ti ≤ Qi (garantiert Kausalordnung: alle Nachrichten, die p gesehen hat, hat auch q gesehen) Bei Rundruf ist „zuverlässige Nachrichtenübertragung“ eine starke Forderung! „Vektorzeit“: nicht ganz identisch mit Vektorzeit nach ! hier weiter  Beim Abliefern einer Nachricht von p bei q wird Qp um 1 erhöht. (realisiert im System ISIS, Birman/Joseph 1987, Cornell Univ.)

21 Kapitel 5.2.3: Totalordung durch künstliche Serialisierung unabhängiger Rundrufe entweder mittels Sequencer, d.i. zusätzliche Station, über die alle Rundrufe vermittelt werden oder mittels Prozeßring mit kreisender Marke (vgl. Token Ring in Hardware,  5.2.4), die die Sendeberechtigung gibt Garantiert werden typischerweise zuverlässige totalgeordnete Rundrufe auch bei Nachrichtenverlust, evtl. sogar Stationsausfall 3. Alternative: mit Skalarzeit, ähnlich dem Protokoll für wechselseitigen Ausschluß – voll verteilt (aber nicht gut skalierend) (Tanenbaum/van Steen 4.5.2)

22 Kapitel 5.3: Auswahlalgorithmen, Bully, Virtueller Ring
Auswahlalgorithmen (election algorithms) dienen der Wahl eines Koordinators („Gruppenleiters“) einer Gruppe bei „halbverteilten“ Algorithmen – die ausgewählte Station hat koordinierende Aufgaben (Beispiel: der Sequencer aus 5.2.3) Nach Ausfall des Koordinators Inbetriebnahme eines neuen Koordinators typischerweise in 3 Phasen: 1. Feststellung des Ausfalls durch andere Station(en) 2. Neuwahl – Einigung auf einen neuen Koordinator 3. Amtsübernahme des Neugewählten (komplexer, falls Zustand der ausgefallenen Station relevant!)

23 Kapitel 5.4: Sperrsynchronisation
Kommunikationsaufwand für Eintritt in den kritischen Abschnitt Nachrichtenanzahl mit Rundruf Zentraler Koordinator 2 Virtueller Token Ring 0 bis n-1 Verteilte Warteschlange 2(n-1) n Beachte: In der Praxis kommt meist nur die zentralisierte Lösung in Frage (eventuell mit Ersatz-Koordinator – siehe Kap. 6)

24 Kapitel 5.5: Verteilte Hashtabellen, Chord
finger table N8+1 N14 N8+2 N14 N8+4 N14 N8+8 N21 N8+16 N32 N8+32 N42 N42+1 N48 N42+2 N48 N42+4 N48 N42+8 N51 N42+16 N1 N42+32 N14 N51+1 N56 N51+2 N56 N51+4 N56 N51+8 N1 N51+16 N8 N51+32 N21 N8+32 N42 N42+8 N51 N51+2 N56 K54 lookup(K54) N56 N8 N51 N14 N48 N21 N42 N38 N32

25 Kapitel 5.6: Echo-Algorithmen
monitor Station(Set<Station> neighbours) boolean visited := false; Station pred := nil; int replies := 0; proc broadcast(Message m) visited := true; foreach n in neighbours do n.probe(this,m); await replies = |neighbours|; port probe(Station s, Message m) if !visited then // bei Zyklen probe als echo werten consume(m); visited := true; pred := s; foreach n in neighbours-pred do n.probe(this); replies := replies + 1; if replies = |neigbours| then visited := false; if pred ≠ nil then pred.echo(); // kein pred bei // initiator port echo() if pred ≠ nil then pred.echo(); Bestätigter Rundruf mit probe/echo

26 Kapitel 6: Verteilte Datenverwaltung
Ziel: Zusammengehöriger Datenbestand soll über mehrere Stationen verteilt werden, z.B.  Fragmentierung: in mehrere Fragmente aufgeteilt  Replikation: in mehreren Kopien gespeichert  Mischformen von Fragmentierung und Replikation „zusammengehörig“: gewisse Konsistenz-Eigenschaften, beschrieben durch Invariante, z.B. bei Replikation: „alle Kopien gleich“ Motivation: (Fragmentierung:) Lastverteilung, Parallelarbeit u.a. (Replikation:) Verfügbarkeit – schnell und ausfallsicher (z.B. verteilte Datenbank, verteiltes Dateisystem, verteilter Namensdienst, ...) u.a.: für verteilte Transaktionen

27 Kapitel 6.1: Replikation Konsistenz replizierter Objekte
Sinnvolle Definition: unter Berücksichtigung von Datenabstraktion: Objekt verhält sich so, als sei es nicht repliziert Wünschenswerte Eigenschaft 1: Kausalitätstreue: Eine Folge kausal abhängiger Operationsaufrufe auf einem replizierten Objekt x hat die gleichen Effekte/Ergebnisse wie eine entsprechende sequentielle Ausführung auf einem nichtreplizierten x (wenn sonst keine weiteren Aufrufe im Spiel sind) Wünschenswerte Eigenschaft 2: Unabhängigkeitstreue: Effekt und Ergebnisse von kausal unabhängigen Operationsaufrufen auf einem replizierten Objekt x sind die gleichen wie bei einer nebenläufigen Ausführung auf einem nichtreplizierten x

28 Kapitel 6.1.2: Konsistenzmodelle
PRAM-Konsistenz Kausale Konsistenz Sequentielle Konsistenz Schwache Konsistenz (~ sequentiell !) eager release consistency lazy release consistency

29 Objektpufferung (caching)
Kapitel 6.2: Caching Objektpufferung (caching) = dynamische, ad-hoc-Replikation einer Primärkopie: Zugriffswilliger beschafft sich temporär eine lokale Kopie cache oder Pufferspeicher = Bereich zum Unterbringen lokaler Kopien im Prozessor: Register, z.B. für Teil des Kellers im Prozessor: Hauptspeicherpuffer für Speicherblöcke im Arbeitsspeicher: Rahmen für Seiten aus Externspeicher im Dateisystem: Text- und Bilddateien von Webserver

30 Kapitel 7: Fehlertoleranz
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 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

31 Kapitel 7.2: Voting Replikation mit Abstimmung (voting)
toleriert Stations- und Netzausfälle, erhöht die Verfügbarkeit von Daten Ansatz: Verwendung von Lese- und Schreib-Quorum (vgl b) 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, < r  n b: Verteilte Transaktionen -> Serialisierbarkeit durch Ausschlusssynchronisation -> verteilter Leser-Schreiber-Ausschluss

32 Kapitel 8: Verteilungsabstraktion, Fernaufrufe
= tatsächliche Aufruf- und Antwortbeziehungen Aufruf res = x.op(arg) Vertreter (proxy, client stub) A d a p t e r Treiber (skeleton, server stub) Aufgerufener (Modul, Objekt, . . .) Aufrufer Bibliothek Fernaufrufdienst Fernaufrufdienst Transportdienst accept BS Transportdienst Netz Hardware

33 Kapitel 8.1.4: Fernaufruf-Semantik
Übergabe zweier Variablenparameter i,k an die Funktion void inc2(var int x, var int y) { x := x + 1; y := y + 1 } zentralisiert verteilt x y i 4 6 3 i 3 x y 4 6 3 x 5 y x 4 6 k 5 k 5 y 3 x y i,k 3 x y x y 4 4! 4 x y 4 5

34 Kapitel 8.1.4: Fernaufruf-Semantik
Fernaufrufdienst hat bestimmte Fehlersemantik (failure semantics) höchstens-einmal-Semantik (at-most-once semantics): Fernaufrufdienst gibt auf. mindestens-einmal-Semantik (at-least-once semantics): Fernaufrufdienst macht permanent neue Versuche (nur akzeptabel bei idempotenten Operationen, bei denen wiederholte Ausführung den gleichen Effekt wie eine einzelne Ausführung hat). genau-einmal-Semantik (exactly-once semantics): Fernaufrufdienst führt Historie getätigter und bestätigter Operationen (aufwendig; nur möglich, wenn Anbieter-Station nicht permanent funktionsunfähig ist).

35 Kapitel 8.1.5+6: Beispiele Java RMI .NET Remoting
class Server extends UnicastRemoteObject implements RemoteService { public Server() throws RemoteException { } nötig! private String memory = ""; public String echo(String s) // throws entbehrlich! { return memory += s; } } .NET Remoting class Server : MarshalByRefObject { private string memory = ""; public string echo(string s) { return memory += s; }

36 Kapitel 8.2: Mobile Objekte
Verteilungsabstraktion (distribution transparency) ist Sammelbegriff für verschiedene Eigenschaften eines Programmiersystems, die von den Verteilungsspezifika der Implementierung zu abstrahieren erlauben: Zugriffs- Abstraktion (access transparency) Lage/Orts- Abstraktion (location transparency) Migrations- Abstraktion (migration transparency) Replikations- Abstraktion (replication transparency) und weitere . . .

37 Klassifikation: Steuerung der Migration explizit implizit imperativ deklarativ Migrationsabstraktion passiv: weak mobility Objekt ist während der Migration aktiv: strong mobility

38 Kapitel 9: Middleware Middleware, Verteilte Plattform (auch Verteilungsplattform*)  bietet Verteilungsabstraktion für verteilte Anwendungsprogramme,  bietet Standarddienste (Transaktionen, Sicherheit, ...),  unabhängig von unterliegenden Betriebssystemen und Hardware,  oft unabhängig von den verwendeten Programmiersprachen (stattdessen Schnittstellen-Beschreibungssprache, „IDL“)  aber orientiert an einem bestimmten Modell für Interaktion, Architektur, Komponenten * ältere Bezeichnung: network operating system (vs. distributed operating system)

39 CORBA – Common Object Request Broker Architecture
(Open Management Group [OMG] ) ist Standard, nicht Produkt Architektur: objektorientiert/Fernaufrufe + Komponenten IDL: C++ -ähnlich Dienste: sehr reichhaltig Einsatz: Anwendungen, speziell Einbinden von Altsoftware EJB – Enterprise Java Beans (Sun 1998 …) Architektur: objektorientiert/Fernaufrufe (RMI) + Komponenten + Nachrichten IDL: (Java) Dienste: reichhaltig Einsatz: vielseitig, insbesondere Datenbank-Anwendungen

40 Kapitel 9.6: World Wide Web
REST - Representational State Transfer "what the web got right and why it works" Architekturstil und Prinzipien des WWW, informell in HTTP 1.1, beschrieben von Roy Fielding 2000 Eigenschaften des WWW:  Skalierbarkeit: extrem hoher Verteilungsgrad (weltweit)  Heterogenität: sehr unterschiedliche Informationen (Bilder, Texte, ...) und Informationsquellen (Dateien, Datenbanken, ...) Kernideen von REST: j Zustandslose Klient/Server-Architektur mit Zwischenstationen k Repräsentationen von Ressourcen (resource representations) l Einheitliche Schnittstelle (uniform interface)

41 Kapitel 9.6.1.ff: Eingebette Programme
client machines server machine prog.cgi Browser httpd http pipe . . Web Server fungiert als Prozesserzeuger: wenn statt .html-Dokument eine .cgi-Ressource angefordert wird, wird Prozeß erzeugt, der das dort vorliegende Programm ausführt und über den Web Server mit dem Browser kommuniziert.

42 Kapitel 9.7: Web-Dienste SOAP
Dave Winer et al. (Userland, Microsoft) 1998 : XML-RPC weiterentwickelt zu SOAP (W3C) 2000 Idee: Transport von XML-Dokumenten als Nachrichten entlang eines Transport-Pfads XML XML XML XML binding A binding B initial sender ultimate receiver intermediary protocol A protocol B initial sender ultimate receiver intermediary

43 WSDL - Web Services Description Language
Kapitel 9.7.2: WSDL WSDL - Web Services Description Language XML-Sprache zur Beschreibung aller Aspekte von Web-Diensten: Was beinhaltet der Dienst - Typen, Nachrichten Wie wird der Dienst angeboten - Bindung Wo wird der Dienst bereitgestellt - Service Signatur in Java wäre etwa: float checkAvailability (Date checkin, Date checkout, String roomtype) throws InvalidDataError Beispiel: Prüfen, ob im Hotel "GreatH" Zimmer verfügbar sind. Angabe von Check-In-Tag, Check-Out-Tag und Zimmer-Typ liefert Preis in Euro, oder meldet ParameterFehler.

44 Kapitel 10: MOM Erzeuger Dienst Verbraucher (producers) (consumers) .
Kanäle, Schlangen, mailboxes, topics, subjects, ... Nachrichtendienst (message service) – Nachrichtenmenge Ereignisdienst (event service) – publish / subscribe

45 Klassifikation entsprechend dem Initiator des Informationsflusses:
Push mode: Informationsfluss wird durch Quelle angestoßen Pull mode: Informationsfluss wird durch Senke angestoßen : Wirkungsrichtung Quelle Senke put (Push) handle (Push) generate (Pull) get (Pull) grün: Pufferung erforderlich rot: permanentes Polling

46 Kapitel 10.2.ff: MOM-Beispiele
... MQ Series, CORBA Notifications, JMS, Siena, ... string type = alarm int level > 0 string type = quote string type = alarm int level = 3 string type = alarm string type = quote int level > 0 string type any string type = quote string type = alarm int level > 1 string type = alarm int level > 2 string type = alarm int level = 2

47 Kapitel 11: Verteilte Betriebssysteme
Verteilungsabstraktion kann auf verschiedenen Ebenen der funktionalen Hierarchie praktiziert werden:  Middleware   Verteilte Programmiersprache 8.1, 9.2  (Anwendungssysteme) (Betriebssystem)  Verteilte Verzeichnisdienste  11.3  Verteiltes Dateisystem  11.2  Verteilter Virtueller Speicher (DSM) ,  11.1

48 Kapitel 11.2: Verteilte Dateisysteme
Unix United - entfernte Systemaufrufe RFS - entfernte Systemaufrufe NFS - Ferzugriff auf Datei-Blöcke AFS - Caching ganzer Dateien

49 Kapitel 11.3: Verteilte Verzeichnisse
ypserv master (Primärkopie) ypserv ypserv slaves (Sekundärkopien)    ypbind  Klientenstationen  Klientenprozesse "" A.ROOT-SERVERS.NET DNS "de" f.nic.de "uk" ns1.nic.uk "org" tld1.ultradns.net

50 Vielen Dank für Euer Interesse!
Verteilte Systeme Sommersemester 2007 - ENDE - Vielen Dank für Euer Interesse! Karsten Otto