Literatur. Verteilte Systeme Hochschule Regensburg Vorlesung 1, Universitätsstraße 31, Regensburg. 1. VS: Einführung und Motivation

Transkript

1 Literatur Hochschule Regensburg Vorlesung 1, Universitätsstraße 31, Regensburg Prof. Dr. Jan Dünnweber Als Haupttext in allen Übungsstunden und Vorlesungen wird das Buch von Tanenbaum und van Steen (ISBN ) benutzt Dazu wird noch das Buch Grundkurs: von Günther Bengel empfohlen (ISBN ) Weitere Quellen sind die Vorlesungen meiner Kollegen 1 Prof. Jobst (HS.R) 2 Prof. Mattern (ETH Zürich) 3 Prof. Gorlatch (WWU Münster, Quelle der meisten Vorlesungsfolien) Die empfohlenen Bücher sind in der Bibliothek vorhanden Prof. Dr. Jan Dünnweber, Folie 2 von VS: Einführung und Motivation - Ergebnis der Revolution in der Computer-Welt: Bis ca waren Computer groß und teuer Seit Mitte der 80er zwei prinzipielle Technologiefortschritte: Prozessoren sind günstiger und leistungsfähiger geworden (Preis/Leistungs-Steigerung in 50 Jahren von ca , Analogie: Rolls-Royce für 1$ und 10 6 km pro Liter Benzin) Einführung und Verbreitung von Hochgeschwindigkeits-Netzwerken (LANs, WANs, Internet) Es ist einfach geworden, Systeme aus sehr vielen Computern mit einem Hochgeschwindigkeitsnetzwerk zusammenzusetzen Paradigmenwechsel: Zentralisierte Systeme Verteilte Systeme Prof. Dr. Jan Dünnweber, Folie 3 von 29 Verteiltes System: Erste Definition Eine erste (etwas lockere) Charakterisierung: Ein verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes, kohärentes System erscheinen Zwei wichtige Aspekte der Definition: Hardware: die Computer sind autonom Software: der Benutzer glaubt, mit einem einzigen System zu tun zu haben Einige erwünschte Eigenschaften verteilter Systeme: Dem Benutzer bleiben die Unterschiede einzelner Computer und wie sie verbunden sind, verborgen Ein System soll erweiterbar sein einfach und für den Benutzer unsichtbar und ununterbrochen zur Verfügung stehen Prof. Dr. Jan Dünnweber, Folie 4 von 29

2 Heterogenität und Middleware Aufgabe: heterogene Computer und Netzwerke nach außen hin als einziges System präsentieren Ansatz: Eine Softwareschicht wird zwischen den Benutzern/Applikationen und den Betriebssystemen/Computern angesiedelt Diese Schicht bezeichnet man oft als Middleware: Beispiele verteilter Systeme Bsp. 1: Netzwerk aus Workstations an der Hochschule Regensburg: Persönliche Workstations + Pool Einheitliches Dateisystem Dynamisches Zuweisen von Aufgaben auf freie Rechner, transparent für den Benutzer Bsp. 2: Informationssystem für Arbeitsabläufe: Unterstützt automatische Auftragsverarbeitung Aufträge kommen von Laptops, Handys, etc. Anschein einer zentralen Datenbank Bsp. 3: World Wide Web: Ein einheitliches Modell verteilter Dokumente (durch Links) Z.Zt. einzelne Server erkennbar, die Weiterentwicklung führt jedoch zu einem (virtuell) zentralen Dateisystem Prof. Dr. Jan Dünnweber, Folie 5 von 29 Prof. Dr. Jan Dünnweber, Folie 6 von 29 Ziele und Motivationen für verteilte Systeme Ziel 1: Benutzer und Ressourcen zu verbinden Zugriff auf entfernte Ressourcen gemeinsam mit anderen Benutzern (konkurrierend oder kooperierend) Vereinfachung der Zusammenarbeit: virtuelle Organisationen, Arbeiten mithilfe von Groupware, E-Commerce Neue Aspekte werden wegen verstärkter Kommunikation wichtig: Sicherheit, Autorisierung, Spam-Abwehr Ziel 2: Transparenz Ein transparentes System präsentiert sich Benutzern und Applikationen so, als handelte es sich um ein einziges Computersystem, obwohl die Prozesse und Ressourcen physisch über mehrere Computer verteilt sind Das Transparenz-Konzept wird auf verschiedene Aspekte eines verteilten Systems angewendet, sog. Transparenzarten: Transparenzart Zugriff Position Migration Relokation Replikation Nebenläufigkeit Fehler Persistenz Verbirgt... Unterschiede in der Datendarstellung und wie der Zugriff auf eine Ressource erfolgt wo sich eine Ressource befindet dass eine Ressource an eine andere Position verschoben werden kann die Verschiebung einer Ressource an eine andere Position während ihrer Benutzung dass eine Ressource repliziert ist dass eine Ressource von mehreren Benutzern gleichzeitig genutzt werden kann den Ausfall und die Wiederherstellung einer Ressource ob eine (Software-)Ressource sich im Arbeitspeicher oder auf einer Festplatte befindet Tabelle: Transparenzarten nach ISO Prof. Dr. Jan Dünnweber, Folie 7 von 29 Prof. Dr. Jan Dünnweber, Folie 8 von 29

3 Transparenzgrad Transparenz ist zwar meistens wünschenswert, aber doch nicht immer notwendig bzw. vorteilhaft: Eine deutsche Morgenzeitung muss bei Aufenthalt in Kanada nicht unbedingt vor 7:00 Uhr vorliegen Zeitverlust bei Signal übertragung muss nicht verborgen bleiben Vollständige Transparenz kann zu Leistungsverlusten führen, z.b. mehrmalige Zugriffsversuche bei ausgefallenem Server, vollständige Konsistenz über mehrere Repliken, etc. Aufwand und Nutzen sollen abgewogen werden Ziel 3: Offenheit Ein offenes System bietet standardisierte Dienste an: Dienste werden i.a. durch Schnittstellen spezifiziert, häufig mithilfe einer IDL (Interface Definition Language) Saubere (d.h. vollständige und implementierungsneutrale) Schnittstellendefinitionen erlauben Kommunikation zwischen Prozessen sowie unabhängige Implementierungen von Diensten Interoperabilitä: In welchem Ausmaß die Implementierungen unterschiedlicher Hersteller zusammen arbeiten können, indem sie sich auf Dienste der anderen verlassen, die nach einem gemeinsamen Standard spezifiziert sind Portabilität: In welchem Ausmaß eine Applikation, für System A entwickelt, ohne Veränderungen auf dem System B laufen kann, das dieselbe Schnittstelle wie A implementiert Flexibilität: neue Komponenten (auch von verschiedenen Entwicklern) hinzufügen, bestehende ersetzen, etc. Prof. Dr. Jan Dünnweber, Folie 9 von 29 Prof. Dr. Jan Dünnweber, Folie 10 von 29 Ziel 4: Skalierbarkeit Probleme bei Skalierbarkeit Dimensionen der Skalierbarkeit: Größenmäßig: weitere Benutzer und Ressourcen hinzufügen Geographisch: über weitere Entfernungen Administrativ: über unabhängige administrative Organisationen Probleme bei der Skalierbarkeit: Zentraler Server (für Dienste, Daten, etc.) ist manchmal unvermeidbar, z.b. wegen Sicherheit, und stellt einen Flaschenhals dar. Beispiele der Beschränkungen (Tabelle): Konzept Beispiel Zentrale Dienste Ein einziger Server für alle Benutzer Zentrale Daten Ein einziges Online-Telefonbuch Zentrale Algorithmen Routing (Weiterleitung) basierend auf vollständigen Informationen Ausweg: z.b. Dezentrale/Verteilte Algorithmen: keine Maschine besitzt vollständige Informationen über den Status des ganzen Systems Maschinen treffen Entscheidungen basierend auf lokalen Informationen Ausfall einer Maschine zerstört nicht den Algorithmus Es wird keine globale Uhr vorausgesetzt Probleme bei geographischer Skalierbarkeit: synchrone Kommunikation: OK in LANs, zu langsam in WANs kollektive Kommunikation (Broadcast) ist in WANs problematisch, spezielle Suchdienste nötig Prof. Dr. Jan Dünnweber, Folie 11 von 29 Prof. Dr. Jan Dünnweber, Folie 12 von 29

4 Skalierungstechniken Skalierbarkeit ist ein Leistungsproblem, verursacht durch begrenzte Kapazität von Servern und Netzwerken. Grundsätzlich gibt es drei Techniken der Skalierung: 1. Verbergen der Kommunikationslatenzzeiten, durch: asynchrone Kommunikation oder Verlagerung der Berechnungen vom Server auf den Client (z.b. mit Java-Applets) Skalierungstechniken 2. Verteilung: eine Komponente in mehrere zerlegen und über das System verteilen, z.b. WWW, DNS (Domain Name System): 3. Replikation, z.b. Caching (beachte: Konsistenzprobleme, strenge oder schwächere Konsistenz, wird später behandelt) Prof. Dr. Jan Dünnweber, Folie 13 von 29 Prof. Dr. Jan Dünnweber, Folie 14 von 29 Hardware-Konzepte Mehrere Möglichkeiten, Computer zusammenzuschalten: werden zunehmend heterogen, so z.b. sog. Grids, die mehrere Hochleistungsrechner weltweit verbinden und als ein System zur Verfügung stellen Grid vom engl. Power Grid Rechenkapazitäten werden wie Strom transparent angeboten und abgerechnet Softwarekonzepte für verteilte Systeme verglichen mit Betriebssystemen: Beide managen multiple Ressourcen Beide verbergen Konflikte und Heterogenität, indem sie eine virtuelle Maschine bereitstellen Moderne verteilte Systeme sind i.d.r. eine Kombination von: Distributed Operating System (DOS) Network Operating System (NOS) Middleware System Beschreibung Wichtigstes Ziel DOS Streng gekoppeltes Betriebssystem für Multiprozessoren Hardware-Ressourcen verber- und homogene Multicomputer gen und verwalten NOS Locker gekoppeltes Betriebssystem für heterogene Anbieten lokaler Dienste für Multicomputer (LAN und WAN) entfernte Clients Middleware Zusätzliche Schicht über dem NOS, die allgemeine Verteilungstransparenz erzielen Dienste implementiert Prof. Dr. Jan Dünnweber, Folie 15 von 29 Prof. Dr. Jan Dünnweber, Folie 16 von 29

5 Rolle der Middleware Rolle der Middleware Ziel: Beste Eigenschaften der beiden Welten: Skalierbarkeit und Offenheit von NOS Transparenz von DOS Lösung: Middleware als zusätzliche Software-Schicht für NOS, um die Heterogenität und Verteilung zu verbergen: In NOS verwenden Anwendungen NOS-Dienste, z.b. Sockets, die jedoch keine Transparenz bieten Einzelne Knoten werden weiterhin von lokalen BS verwaltet Middleware-Systeme bieten Dienstsammlungen, die dem Benutzer zur ausschließlichen Benutzung (ohne Umgehen ) empfohlen werden Middleware-Konzept ist nicht aus Forschung, sondern aus der Industrie entstanden Prof. Dr. Jan Dünnweber, Folie 17 von 29 Prof. Dr. Jan Dünnweber, Folie 18 von 29 Middleware-Modelle Middleware-Dienste Die wichtigsten Middleware-Modelle: Alles ist eine Datei z.b. in frühen Unix-Versionen Verteilte Dateisysteme weniger streng, Prozesse werden explizit auf bestimmten Maschinen gestartet RPC (Remote Procedure Call): eine Prozedur wird lokal aufgerufen obwohl ihre Ausführung tatsächlich entfernt stattfindet Verteilte Objekte und RMI: Weiterentwicklung des RPC in der OO-Welt Verteilte Dokumente in WWW Kommunikationsfunktionen, die low-level Nachrichtenaustausch verbergen Namensgebung, zum gemeinsamen Nutzen und Suchen, z.b. URL in WWW. Persistenz, zum verteilten Speichern, auch in verteilten Datenbanken Verteilte Transaktionen, um mehrere Lese- und Schreiboperationen atomar auszuführen Sicherheitsdienste Prof. Dr. Jan Dünnweber, Folie 19 von 29 Prof. Dr. Jan Dünnweber, Folie 20 von 29

6 Interne Organisation eines VS: Client-Server-Modell Kommunikation zwischen Client und Server Client-Server ist das momentan am häufigsten benutzte Modell, ein anderes ist z.b. p2p (peer-to-peer) Motivation: Viele Systeme bestehen aus Clients, die von Servern bestimmte Dienste anfordern Clients und Server können sich überlappen, d.h., ein Rechner kann beide Rollen übernehmen Die Zusammenarbeit wird als Anforderungs-Antwort-Verhalten (Request-Reply) bezeichnet Zwei wesentliche Möglichkeiten: Verbindungsloses Protokoll Einfach und schnell, gut für LANs Unzuverlässig, d.h. Nachrichten können verloren gehen Bsp.: Wird auf Nachricht überweise 1.000,- Euro aufs Konto X keine Antwort erhalten, so darf die Nachricht nicht einfach wiederholt werden, anders als bei der Nachricht Kontostand mitteilen Verbindungsorientiertes Protokoll Zuverlässig aber langsam, gut für WANs So arbeiten fast alle Internet-Dienste Prof. Dr. Jan Dünnweber, Folie 21 von 29 Prof. Dr. Jan Dünnweber, Folie 22 von 29 Client-Server: Anwendungsebenen Client-Server-Architekturen Ein Problem vom Client-Server-Modell: in vielen Anwendungen ist keine klare Unterscheidung zw. Client und Server möglich Für Client-Server-Anwendungen mit Datenbanken unterscheidet man deshalb drei vertikale Ebenen: Ebene der Benutzeroberfläche: wird i.d.r. von Clients implementiert Verarbeitungsebene: hier wird die Kernfunktionalität implementiert, oft auf Server, manchmal auf dem Client Datenebene: Dateisystem + evtl. Datenbank, wird i.d.r. auf der Server-Seite implementiert Die drei logischen Ebenen (vgl. vorige Folie) ermöglichen verschiedene Verteilungen einer Anwendung über mehrere Maschinen eines verteilten Systems Einfachste Variante: ein Client (implementiert die Benutzeroberfläche) und ein Server (implementiert Verarbeitungs- und Datenebene) Nachteil: Server übernimmt alles, keine richtige Verteilung Nächster Schritt: Two-Tier Architektur mit verschiedenen Anordnungen Prof. Dr. Jan Dünnweber, Folie 23 von 29 Prof. Dr. Jan Dünnweber, Folie 24 von 29

7 Client-Server-Architekturen Multitier Architektur Man muss berücksichtigen, dass ein Server als Client eines anderen Servers arbeiten kann: Man unterscheidet zwei Arten der Verteilung: Vertikale Verteilung: logisch unterschiedliche Komponenten werden auf unterschiedlichen Maschinen angeordnet Prof. Dr. Jan Dünnweber, Folie 25 von 29 Prof. Dr. Jan Dünnweber, Folie 26 von 29 Multitier Architektur (Forts.) Zusammenfassung und Ausblick Horizontale Verteilung (zunehmend in modernen Systemen): ein Server oder Client wird in logisch äquivalente Teile unterteilt, jeder arbeitet mit einem Anteil der Datenmenge: Was haben wir heute gelernt bestehen aus zusammenarbeitenden, autonomen Computern, die sich als ein einziges System nach außen präsentieren Vorteile: vereinfachte Integration unterschiedlicher Anwendungen gute Skalierbarkeit Diese Vorteile müssen oft erkauft werden, durch: komplexere Software verschlechterte Leistung schwächere Sicherheit Prof. Dr. Jan Dünnweber, Folie 27 von 29 Prof. Dr. Jan Dünnweber, Folie 28 von 29

8 Zusammenfassung und Ausblick Ausblick der gesamten Vorlesung Moderne VS werden oft mithilfe einer Extra-Softwareschicht Middleware über dem Netzwerkbetriebssystem aufgebaut: verbirgt Heterogenität und Verteiltheit Programmiermodell: RPC, verteilte Objekte, etc. Wichtiges Modell für interne Anordnung eines VS: Client-Server: Clients benutzen Dienste von Servern (Analogie zur traditionellen Programmierung, mit Diensten in Prozeduren) Vertikale Anordnung in drei Ebenen: Benutzeroberfläche-, Verarbeitungs- und Datenebene Horizontale Anordnung: Clients und Server werden über mehrere Computer verteilt und repliziert, wie z.b. im WWW Kommunikation: spezielle Mechanismen für große Systeme, Middleware-Modelle und Programmierung Prozesse: effiziente Organisation, Zusammenarbeit und Migration Namensgebung: Aufbau und effiziente Implementierung, sowie Garbage Collection Synchronisierung: Zeitbegriff, wechselseitige Ausschluss, verteilte Transaktionen, Korrektheit Konsistenz und Replikation: Begriffe und Implementierungen, Korrektheit und Skalierbarkeit Fehlertoleranz: Techniken und Protokolle Sicherheit: Authentifizierung, Integrität, Vertraulichkeit Prof. Dr. Jan Dünnweber, Folie 29 von 29 Prof. Dr. Jan Dünnweber, Folie 30 von 29