Verteilte Systeme Sommersemester 2007 - Zusammenfassung - Karsten Otto

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  . . . . .

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

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

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

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

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

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

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, ...)

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

Kapitel 3: Netzdienste Klient Dienst Port Prot. Socket Login Programm daytime daytime 13 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

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

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

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

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 )

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

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.

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.

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

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 4.1.2 ! 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.)

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)

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!)

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)

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

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

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

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

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

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

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

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. 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

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

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

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).

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; }

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 . . .

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

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)

CORBA – Common Object Request Broker Architecture (Open Management Group [OMG] 1991 ...) http://www.corba.org 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

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 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 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)

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.

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

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.

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

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

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

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

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

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

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