18 Entwicklung verteilter Systeme

1. 18 Entwicklung verteilter Systeme 18.0 Einführung • Lernziele • Verteilte Systeme 18.1 Charakteristika verteilter Systeme • Entwurfsfragen • Kommunikationsmodelle • Middleware 18.2 Client-Server-Systeme • Prozesse in Client-Server-Systemen • Schichtenarchitektur

2. 18 Entwicklung verteilter Systeme 18.3 Architekturmuster für verteilte Systeme Master-Slave-Architektur zweischichtige Client-Server Architektur mehrschichtige Client-Server Architektur verteilte Komponentenarchitektur Peer-to-Peer-Architektur 18.4 Software als Service

3. 18.0 Lernziele die Hauptprobleme bei Entwurf und Implementation verteilter Softwaresysteme kennen das Client-Server-Modell und die Schichtenarchitektur von Client-Server-Systemen verstehen häufig genutzte Muster für verteilte Systemarchitekturen kennen und ihre Eignung für bestimmte Anwendungs-systeme beurteilen können das Konzept der Software als Service verstehen

4. 18.0 Verteilte Systeme mehrere voneinander unabhängige Computer, die dem Benutzer als ein einzelnes kohärentes System erscheinen Ressourcenteilung gemeinsame Hardware-Nutzung: Massenspeicher, Drucker, etc. gemeinsame Software-Nutzung: Dateien, Compiler, etc. Offenheit Standardprotokolle Hard- und Software verschiedener Hersteller Nebenläufigkeit verschiedene Prozesse gleichzeitig auf verschiedenen Rechnern Kommunikation zwischen den Prozessen möglich

5. 18.0 Verteilte Systeme Skalierbarkeit Kapazitätserweiterung durch neue Ressourcen begrenzt durch das Netzwerk Fehlertoleranz Möglichkeit der Replizierung von Information bei Ausfällen oft eingeschränkter Dienst weiter möglich komplexer als zentrale Systeme Entwicklung, Implementierung und Testen schwieriger Verhalten schwerer vorhersagbar Leistung von vielen verschiedenen Faktoren abhängig keine zentrale Steuerung

6. 18.1 Entwurfsfragen Transparenz Was soll der Benutzer über die Verteilung wissen? Offenheit Sollen nur Standardprotokolle verwendet werden? Skalierbarkeit Kann die Systemkapazität leicht erweitert werden? Informationssicherheit Gibt es gemeinsame Sicherheitsrichtlinien? Dienstgüte (QoS – Quality of Service) Wie wird eine akzeptabele Dienstgüte spezifiziert? Fehlermanagement Wie werden Fehler entdeckt, eingedämmt und behoben?

7. 18.1 Transparenz Verteilung bleibt für Benutzer verborgen System wird als Einheit wahrgenommen Verhalten ist unabhängig von der Verteilung Voraussetzungen Abstraktionen der Ressourcen Abbildung von logischen Ressourcen auf physikalische Realisierungen durch Middleware Beeinträchtigung durch fehlende zentrale Steuerung unterschiedliches Verhalten der einzelnen Rechner Verzögerungen im Netz Information der Benutzer über Verteilung bessere Einstellung auf Folgewirkungen der Verteilung

8. 18.1 Offenheit Offene verteilte Systeme erstellt nach allgemeingültigen Standards Zusammenarbeit von Komponenten aller Anbieter Offenheit auf verschiedenen Layern auf Netzwerkebene üblich (Internetprotokolle) auf Komponentenebene seltener Offene Standards CORBA (Common Object Request Broker Architecture):in der Praxis nicht durchgesetzt Webservicestandards:wegen Performanzproblemen stattdessen oft REST-Protokolle(Representational State Transfer)

9. 18.1 Skalierbarkeit hohe Dienstgüte auch bei steigenden Anforderungen vertikale Skalierung durch stärkere Ressourcen horizontale Skalierung durch zusätzliche Ressourcen Skalierungsdimensionen Umfang bei zunehmender Zahl von Benutzern weitere Ressourcen hinzufügen Verteilung geografische Verteilung der Komponenten ohne Leistungsverlust Verwaltbarkeit auch bei wachsendem System mit Verteilung der Komponenten in unabhängigen Institutionen

10. 18.1 Sicherheit Verteilte System leichter angreifbar als zentrale schwächste Komponente als Hintertür (Back door)in andere Teile des Systems Angriffsarten mithören (interception) unterbrechen (interruption) modifizieren (modification) Informationen einspielen (fabrication) Sicherheitsrichtlinien meist nicht für alle Teile des Systems gleich untereinander nicht immer kompatibel

11. 18.1 Dienstgüte Fähigkeit zur Dienstleistung verlässlich mit akzeptabler Antwortzeit und akzeptablem Durchsatz Spezifizierung der Dienstgüte im Voraus nicht kosteneffizient, wenn hohe Güte bei Spitzenbelastung verlangt wird schwierig bei unvereinbaren Parameternwie Zuverlässigkeit und Durchsatz wichtig bei zeitkritischen Daten Audio und Video ggf. Verhandlung der Dienstgüte

12. 18.1 Fehlermanagement Robustheit gegen Ausfälle einzelner Teile “You know that you have a distributed system when the crash of a system that you’ve never heard of stops you getting any work done.” Mechanismen für Fehlertoleranz nötig Entdeckung von Ausfällen weitere Bereitstellung der noch möglichen Dienste möglichst automatische Fehlerbehebung

13. 18.1.1 Prozedurale Kommunikation Kellner Gast Was darf es sein? Als Vorspeise bitte eine Spargelcremesuppe. Und als Hauptgang? Ein großes Steak, bitte. Wie möchten Sie Ihr Steak? Medium, bitte. Mit Folienkartoffel oder Pommes frites? Ach, bringen Sie mir doch einfach Menü 1! etc.

14. 18.1.1 Nachrichtenbasierte Kommunikation • Kellner an Küche <vorspeise> <gericht = "Suppe" typ = "Spargelcreme" /> <gericht = "Suppe" typ = "Kürbis" /> <gericht = "Krabbencocktail" /> </vorspeise> <hauptgericht> <gericht = "Steak" typ = "Lende" garstufe = "medium"/> <gericht = "Steak" typ = "Filet" garstufe = "durch"/> <gericht = "Zander" /> </hauptgericht> <beilage> <gericht = "Folienkartoffel" portionen = "2" /> <gericht = "Salat" typ = "Feld" /> </beilage>

15. 18.1.1 Prozedurale Kommunikation Remote Procedure Calls (RPCs) Aufruf zwischen Komponenten wie bei lokalen Methoden Middleware fängt Aufruf ab und leitet ihn weiter entfernte Komponente führt Methode aus liefert Ergebnis über Middleware zurück Nachteile des RPC-Ansatzes beide Komponenten müssen gleichzeitig verfügbar sein beide Komponenten müssen sich gegenseitig referenzieren können

16. 18.1.1 Nachrichtenbasierte Kommunikation Senden von Nachrichten Komponenten sendet Nachricht über benötigten Service Middleware leitet die Nachricht an den Empfänger weiter Empfänger parst die Nachricht, führt Berechnung aus und sendet Nachricht mit dem Ergebnis Middleware leitet die Nachricht an den ersten Sender Vorteile des nachrichtenbasierten Ansatzes Komponenten müssen sich nicht gegenseitig kennen Komponenten müssen nicht gleichzeitig verfügbar sein

17. 18.1.2 Middleware koordinierte Operation Anwendungskomponenten Anwendungskomponenten Informationsaustausch und allgemeine Dienste Middleware Middleware logische Interaktion Betriebssystem Betriebssystem physikalische Konnektivität Netzwerk Netzwerk System 1 System 2

18. 18.1.2 Aufgaben der Middleware Unterstützung für Interaktionen verbirgt physikalischen Standort von Komponenten wandelt Parameter um Bereitstellung allgemeiner Dienste wiederverwendbare Implementierung von Diensten erleichtert Zusammenarbeit bietet konsistente Benutzerdienste => Kapitel 17

19. 18.2 Client-Server-Systeme Verteilte Systeme im Internet meist Client-Server-Systeme Benutzer arbeitet mit Programm auf lokalem Rechner Client, z.B. Webbrowser Lokales Programm interagiert mit Programm auf entferntem Rechner Server, z.B. Webserver Server bietet Dienste für viele Clients an Clients greifen auf Dienste zu Clients präsentieren die Ergebnisse dieser Dienste Clients müssen die Server kennen Clients brauchen andere Clients nicht zu kennen

20. 18.2 Client-Server-Interaktion c2 c1 c12 c3 c11 s4 c4 s1 c10 c5 s3 s2 c9 c6 c7 c8

21. 18.2 Clients und Server auf Computern CC1 SC1 CC2 CC3 c1 c2 c3 c4 s2 s1 Netzwerk SC2 CC4 CC5 CC6 c5 c6 c7 c8 c9 c10 c11 c12 s3 s4

22. 18.2 Schichtenarchitektur bei Client-Server-Anw. C C C Präsentationsschicht S S1 Datenverwaltungsschicht S Anwendungsverarbeitungsschicht S2 Datenbankschicht

23. 18.3 Architekturmuster für verteilte Systeme Master-Slave-Architektur garantierte Antwortzeiten in Echtzeitsystemen Zweischichtige Client-Server-Architektur einfache Client-Server-Systeme Zentralisierung aus Sicherheitsgründen Mehrschichtige Client-Server-Architektur bei großen Mengen von Transaktionen Verteilte Komponentenarchitektur Kombination von Ressourcen aus verschiedenen Systemen Implementierungsmodell für mehrschichtige Client-Server-Syst. Peer-to-Peer-Architektur (P2P) direkter Austausch lokaler Information Server nur zur Bekanntmachung der Clients untereinander

24. 18.3.1 Master-Slave-Architekturen Echtzeitsysteme Prozesse zur Datenerfassung von Sensoren Prozesse zur Datenverarbeitung und Berechnung Prozesse zur Steuerung von Aktuatoren Master-Prozess MCI (Darstellung und Interaktion) Berechnung Koordination und Kommunikation der Slave-Prozesse Slave-Prozesse aufgabenspezifisch z.B. Messwerterfassung aus einer Sensoren-Gruppe z.B. Steuerung einer Aktuatoren-Gruppe

25. 18.3.1 Master-Slave-Architekturen Master Leitwarten-prozessor Sensor-steuerungs-prozess Ampel-steuerungs-prozess Koordinations- und Anzeige-prozess Slave Sensordaten-prozessor Slave Ampelsteuerungs-prozessor Sensoren und Kameras der Verkehrsüberwachung Operator-Terminals Ampeln (WLZA) und Wechselzeichen

26. 18.3.2 Zweischichtige Client-Server-Architekturen ein einziger logischer Server und beliebig viele Clients Thin Clients: nur Präsentationsschicht Fat Clients: auch weitere Schichten der Anwendung -> Schichtenmodell 18.2 (inkonsistent zu 18.3.2) Client Thin Fat Präsentationsschicht Datenverwaltungsschicht Anwendungsverarbeitungsschicht Datenbankschicht Server

27. 18.3.2 Zweischichtige Client-Server-Architekturen Thin Clients einfache Verwaltung der Clients Nutzung von Standard-Clients (z.B. Webbrowser) oft als GUI für Altsysteme hohe Belastung von Netz und Server Fat Clients mehr Verarbeitung auf dem Client-Prozessor senkt Belastung von Netz und Server kann Fähigkeiten der Clients optimal nutzen aufwendigere Verwaltung z.B. bei neuer Funktionalität Beispiel: Geldautomaten

28. 18.3.3 Mehrschichtige Client-Server-Architekturen Verteilung der Schichten auf verschiedene Prozessoren oft dreischichtig: Client, Webanwendungsserver, Datenbankserver bessere Skalierbarkeit z.B. zusätzliche Webanwendungsserver leichtere Verwaltung Anwendungslogik zentriert in einer Schicht Beispiel: Kontoführung im Web

29. 18.3.3 Client-Server-Architekturen

30. 18.3.4 Verteilte Komponentenarchitekturen Keine Differenzierung nach Schichten / Clients / Servern Komponenten nutzen Dienste und stellen Dienste bereit Kommunikation erfolgt über Middleware (remote procedure calls) komplexer als Client-Server-Architektur Komp. 1 verfügbare Dienste Komp. 2 verfügbare Dienste Komp. 3 verfügbare Dienste Komp. 4 verfügbare Dienste Kommunikations-Middleware Client Client Client Client

31. 18.3.4 Verteilte Komponentenarchitekturen Anwendungen mit starker Verteilung(z.B. Data Mining mit mehreren Datenbanken) in der Praxis selten wegen zwei Hauptnachteilen: hohe Komplexität => Verständnis-, Darstellungs- und Designprobleme Middleware-Standards nicht durchgesetzt=> unterschiedliche Middleware unterschiedlicher Anbieter Ablösung durch serviceorientierte Architektur vgl. Kapitel 19

32. 18.3.5 Peer-to-Peer-Architekturen gleichberechtigte Teilnehmer keine Unterscheidung zwischen Client und Server bessere Verteilung der Rechenlast jeder Knoten im Netzwerk kann benutzt werden bessere Verteilung der Netzlast keine Umwege erforderlich dezentralisiert hoher Aufwand bei Suche über viele Peers halbzentralisiert „Super-Peer“ als Vermittlung und zur Aufgabenverteilung Anwendung meist im PC-Bereich Informationsaustausch: Filesharing, VoIP, ... Verteiltes Rechnen: SETI@home, ...

33. 18.4 Software als Service (SaaS) Software bereitgestellt auf Server(n) Zugriff über Web-Browser keine lokale Installation keine Bindung an bestimmte Rechner / Mobilgeräte Software verwaltet durch Anbieter keine Kosten beim Anwender kein Einfluss des Anwenders mögliche Probleme mit Datenschutz und Datensicherheit Verschiedene Finanzierungsmodelle Werbung Abonnement pay per use

34. 18.4 SaaS und SOA SaaS: Bereitstellung von Funktionalität auf Servern Zugriff über das Web Server verwaltet Benutzerdaten Server verwaltet Sitzungsdaten lange Transaktionen (z.B. Dokumentbearbeitung) SOA: Struktur für Softwaresysteme Menge zustandsloser Dienste mehrere Anbieter möglich Verteilung möglich kurze Transaktionen (z.B. Aufruf und Rückgabe eines Dienstes) SaaS kann mit SOA implementiert werden, muss aber nicht

35. 18.4 Implementationsfaktoren für SaaS Konfigurierbarkeit Berücksichtigung spezifischer Bedürfnisse der Anwender Mandantenfähigkeit virtuelle eigene Software für Anwender saubere Trennung der Daten effiziente Nutzung der Ressourcen Skalierbarkeit Anpassung an schwer vorhersagbare Anzahl von Nutzern Änderbarkeit Annahmen über Benutzerbedürfnisse möglicherweise falsch agile Entwicklungsmethoden sinnvoll

36. 18.4 Konfigurierung von Services Corporate Design des Anwenders im UI und bei Dokumentausgabe (Branding) Geschäftsregeln und Arbeitsabläufe bezüglich der Daten (z.B. Validierung) bezüglich der Nutzung (z.B. Reihenfolge der Bearbeitung) Datenbanken Erweiterung des generischen Datenmodells des Serviceum unternehmensspezifische Anteile Berechtigungen individuelle Konten für Mitarbeiter / Mitarbeitergruppen des Anwenders Regelungen für Zugriff auf Funktionen und Ressourcen

37. 18.4 Unterstützung der Skalierbarkeit bei SaaS jede Komponente als einfacher zustandsloser Service kann auf jedem Server laufen Benutzer kann mit mehreren Instanzen arbeiten asynchrone Kommunikation kein Warten auf Ergebnisse einer Interaktion Benutzer kann weiterarbeiten Poolbildung für Ressourcen kein Ausfall von Servern wegen fehlender Ressourcen detailliertes Sperren in der Datenbank unterhalb Datensatzebene