Verteilte Systeme. Verteilte Architekturen. Prof. Dr. Oliver Haase

Transkript

1 Verteilte Systeme Verteilte Architekturen Prof. Dr. Oliver Haase 1

2 Übersicht Plattformen für verteilte Systeme Softwarearchitekturen Systemarchitekuren Von der Software- zur Systemarchitektur Architekturmuster für verteilte Systeme 2

3 Plattformen für verteilte System 3

4 Verteiltes Betriebssystem (DOS) Lokale Mechanismen implementieren systemweit verfügbare Dienste, z.b. virtueller gemeinsamer Speicher vor allem sinnvoll (einfacher zu realisieren) in homogenen Systemen Ortstransparenz, d.h. Benutzer muss nicht wissen, welcher Rechner welchen Dienst erbringt Machine A Machine B Machine C Distributed applications Distributed operating system services Kernel Kernel Kernel 4 Network

5 Netzwerkbetriebssystem (NOS) Benutzer verwendet explizit Dienste von anderen Rechnern vor allem sinnvoll in heterogenen Systemen keine Ortstransparenz, dafür sklarierbarer und offener Machine A Machine B Machine C Distributed applications Network OS services Network OS services Network OS services Kernel Kernel Kernel Network 5

6 Middleware Einfügen einer weiteren Software-Schicht kombiniert Vorteile von DOS (Transparenz, einfache Benutzung) und NOS (Offenheit, Skalierbarkeit) Machine A Machine B Machine C Distributed applications Middleware services Network OS services Network OS services Network OS services Kernel Kernel Kernel Network 6

7 Von der Software- zur Systemarchitektur 7

8 Entwurf eines verteilten Systems 1.Softwarearchitektur Aufteilung der Funktionalität auf Komponenten: - ersetzbare, wiederverwendbare Einheiten mit definierten Schnittstellen nach außen 2.Systemarchitektur Abbildung der Komponenten auf Rechner konkrete Instantiierung der SW-Architektur 8

9 Softwarearchitekturen 9

10 Softwarearchitekturstile Architekurstil Klasse von Architekturen für verteilte Systeme relevante SW-Architekturstile: geschichtete Architekturen objektbasierte Architekturen datenzentrierte Architekturen ereignisbasierte Architekturen 10

11 geschichtete Architekturen schichtweise Anordnung der Komponenten höhere Schicht komplexere Dienste Komponente der Schicht Li darf nur Komponenten der Schicht Li-1 verwenden Anforderungen von oben nach unten, Antworten von unten nach oben 11 aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen]

12 Dreischichten-Architektur Häufig verwendete SW-Architektur bestehend aus Präsentations-, Anwendungs- und Persistenzschicht: GUI-Elemente Dialogkontrolle Services Geschäftsobjekte DB-Zugriff Datenhaltung Präsentationsschicht Anwendungsschicht Persistenzschicht I.a. weitere, detaillierte Schichtung innerhalb dieser drei Schichten vorhanden. 12

13 objektbasierte Architekturen Objekte entsprechen Komponenten Interaktion in Form von Methodenaufrufen aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen] häufig Kombination von Schichten- und objektbasierter Architektur: Objekte sind Schichten zugeordnet, Aufrufe nur innerhalb derselben oder in nächstniedrigere Schicht. 13

14 datenzentrierte Architekturen Komponenten kommunizieren über gemeinsames Repository miteinander zeitliche Entkopplung der Komponenten voneinander 14

15 ereignisbasierte Architekturen Kommunikation über Weitergabe von Ereignissen Publish/Subscribe: Komponenten können Ereignisse veröffentlichen Middleware (Ereignisbus) sorgt für Weiterleitung an Komponenten, die diese Ereignisse zuvor abonniert haben. Kombinierbar mit datenzentrierter Arch. gemeinsame Datenräume aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen] 15

16 Systemarchitekturen 16

17 Client-Server-Architektur Clients und Server tauschen Anforderung/Antwort (Request/Response) Nachrichtenpaare aus aus: [Tanenbaum, van Steen. Verteilte Systeme: Grundlagen und Paradigmen] jeder Rechner ist bezogen auf einen bestimmten Dienst statisch entweder Client oder Server 17

18 Client-Server-Architektur aus: [Coulouris, Dollimore, Kindberg. Verteilte Systeme: Konzepte und Design] 18

19 Client-Server-Architektur Ein Server kann wiederum einen anderen Dienst als Client beanspruchen: Komponente A Komponente B Komponente C Client request response Server request Client response Server 19

20 Client-Server-Architektur Die Server-Funktionalität kann auf mehrere Rechner verteilt sein: Replizierte Server, oder Verteilte Server (meistens auch verteilte Daten) aus: [Coulouris, Dollimore, Kindberg. Verteilte Systeme: Konzepte und Design] 20

21 Client-Server-Architektur Einsatz von Caches und Proxy-Servern: Cache Zwischenspeicherung Daten (Cache-Kohärenz) bringt Daten näher an Nutzer, entlastet Server Proxy zusätzliche Aufgaben, z.b. Überwinden von Firewalls aus: [Coulouris, Dollimore, Kindberg. Verteilte Systeme: Konzepte und Design] 21

22 Peer-to-Peer-Systeme Peer: engl.: Gleichgestellter, Ebenbürtiger Grundidee: Jeder teilnehmender Knoten übernimmt sowohl Client- als auch Server-Funktionalität ( Servent ) Rolle ändert sich dynamisch pro Kommunikation wesentliches Ziel: dezentrales verteiltes System ohne zentrale Server aus: [Coulouris, Dollimore, Kindberg. Verteilte Systeme: Konzepte und Design] 22

23 Peer-to-Peer-Systeme jeder neue Peer erhöht nicht nur die Last, sondern bringt neue Ressourcen ein gut skalierbar bzgl. Größe Skalierbarkeit bzgl. geograph. Verteilung wie C/S-Arch. Skalierbarkeit bzgl. V.ü.a.D. schwieriger hochdynamisch, d.h. hohe Churn-Rate, d.h. viele Join und Leave Operationen selbstorganisierend große Heterogeneität der Peers bzgl. Bandbreite, Speicherund Rechenkapazitäten 23

24 Peer-to-Peer-Systeme keine zentrale Koordinierung keine zentrale Datenbasis kein Peer hat globales Wissen über das System jeder Peer kennt nur seine direkte Nachbarschaft Peers sind autonom Peers sind unzuverlässig (Ausfallsicherheit, Glaubwürdigkeit) Oft zur verteilten Speicherung von Daten zentrale Aufgabe: Datum zu gegebenem Schlüssel schnell finden Frühe P2P-Systeme: Fluten des Netzes mit Suchanfrage :-( heute: dezentrale Suchalgorithmen, z.b. verteilte Binärsuche in verteilter Hashtabelle 24

25 Peer-to-Peer-Systeme Vollständige Serverlosigkeit kaum erreichbar wegen Discovery-Problem (Finden des ersten Kontaktpunkts) Für Skalierbarkeit des Rendezvous-Servers beachten: kennt nur konstante Anzahl von Peers nur sehr einfacher, kurzer Nachrichtenaustausch mit anfragenden Peers keinerlei Sitzungskonzept nicht am Datenaustausch zwischen den Peers beteiligt 25

26 Softwarearchitektur Systemarchitektur 26

27 Schichtenarchitektur Abbildung auf Client-Server-Systemarchitektur: Schicht Li+1 Client der tieferliegenden Schicht Li in Bezug auf deren Dienst Beispiel: Dreischichten-Softwarearchitektur wird auf sog. Multi-Tier-Architektur abgebildet - tier: engl. Schicht, Ebene - Zwei-Tier-, Drei-Tier- oder N-Tier-Architektur - sehr häufige Systemarchitektur für Webanwendungen 27

28 Zweischichtenarchitektur Klassische Client-Server-Architektur mit Fat Client: GUI-Elemente Dialogkontrolle Services Geschäftsobjekte DB-Zugriff Datenhaltung Präsentationsschicht Anwendungsschicht Persistenzschicht Fat Client DB Server Präsentationsschicht Anwendungsschicht DB-Zugriff DB Zugriffsprotokoll (z.b. JDBC) Datenbank- System Relativ einfach zu realisieren, schwergewichtig auf Klienten leistungsstarke Klienten, hoher Installationsaufwand 28

29 Dreischichtenarchitektur Moderne Nicht-Web-Architektur mit Thin Client: GUI-Elemente Dialogkontrolle Services Geschäftsobjekte DB-Zugriff Datenhaltung Präsentationsschicht Anwendungsschicht Persistenzschicht Thin Client Applikationsserver DB Server RPC Anwendungsschicht DB-Zugriff DB Zugriffsprotokoll (z.b. JDBC) Präsentationsschicht Datenbank- System leichtgewichtig auf Klienten heterogene/mobile Endgeräte, geringerer Installationsaufwand, einfachere Aktualisierung der Anwendungsschicht erfordert zusätzliche Applikationsserver 29

30 N-Tier-Architektur Moderne Web-Architektur mit Thin Client: GUI-Elemente Dialogkontrolle Services Geschäftsobjekte DB-Zugriff Datenhaltung Präsentationsschicht Anwendungsschicht Persistenzschicht Web Client (Ultra Thin Client) Webserver Applikationsserver DB Server Browser HTTP RPC Anwendungsschicht DB-Zugriff DB Zugriffsprotokoll (z.b. JDBC) serverseitige Präsentationsschicht Datenbank- System 30

31 N-Tier-Architektur Web Client (Ultra Thin Client) Webserver Applikationsserver DB Server Browser HTTP RPC Anwendungsschicht DB-Zugriff DB Zugriffsprotokoll (z.b. JDBC) serverseitige Präsentationsschicht Datenbank- System Webbrowser stellt vom Webserver dynamisch generierte Webseiten (Servlets, Java ServerPages, Java ServerFaces, Active Server Pages, PHP,...) dar. sehr leichtgewichtige Klienten, kein Installationsaufwand eingeschränkte Oberflächen alles läuft im Webbrowser ohne Ajax eingeschränktes Antwortverhalten mit Ajax interaktives Antwortverhalten möglich 31

32 Schichtenarchitektur Abbildung auf Peer-To-Peer-Systemarchitektur: - Dienst jeder Schicht Li so partitionieren, dass jeder Client der Schicht Li eine Partition als Server übernehmen kann - Beispiel: verteilte Datenspeicherung: jeder Client stellt Speicherplatz für einen Teil des gesamten Datenraums bereit 32

33 andere Architekturstile objektbasierte Architektur jedes Objekt kann separat in Systemarchitektur platziert werden verteilte objektorientierte Modelle datenzentrierte Architektur gemeinsames Repository als Client-Server- oder Peer-To- Peer-Dienst ereignisbasierte Architektur erfordert unterstützende Middleware, Komponenten können beliebig platziert werden 33

34 Architekturmuster für verteilte Systeme 34

35 Forwarder-Receiver-Muster Das Forwarder Receiver Muster ist ein Verteiltes Architekturmuster mit dem Zweck, die Geschäftslogik von der Kommunikation zu entkoppeln, so dass der Kommunikationsmechanismus austauschbar wird. Aufgaben des Forwarders Abbildung: logische Namen physikalische Namen Parametermarshalling, d.h. konvertieren in Versandformat Versenden über konkreten Kommunikationsmechanismus Aufgaben des Receivers Empfangen über konkreten Kommunikationsmechanismus Parameterunmarshalling, d.h. konvertieren in internes Format 35

36 Forwarder-Receiver-Struktur Nach Buschmann et al.: Pattern-orientierte Software-Architektur Beachte: Der empfangende Peer ruft die empfangenen Nachrichten mit Hilfe von receivemsg aktiv ab blockierendes Empfangen (möglicherweise in separatem Thread) oder Polling 36