Taxonomie Verteilter Systeme Jörg Domaschka joerg.domaschka@uni-ulm.de Institute of Distributed Systems Faculty of Computer Science Ulm University Germany Aspectix Research Team http://www.aspectix.org/ Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 1 / 28
Begriffsklärung Taxonomie griech. táxis: griech nomía, nomos: Anordnung, Ordnung, Klasse Gesetzen folgend, Sachkunde, Verwaltung Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 2 / 28
Begriffsklärung (2) Verteiltes System Ein Verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes kohärentes System erscheinen [TAN]. Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 3 / 28
Begriffsklärung (2) Verteiltes System Ein Verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes kohärentes System erscheinen [TAN]. Hardware: Autonome Maschinen Unterschied zu Parallelrechnern Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 3 / 28
Begriffsklärung (2) Verteiltes System Ein Verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes kohärentes System erscheinen [TAN]. Hardware: Autonome Maschinen Unterschied zu Parallelrechnern Software: Benutzer sieht ein System Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 3 / 28
Begriffsklärung (2) Verteiltes System Ein Verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes kohärentes System erscheinen [TAN]. Hardware: Autonome Maschinen Unterschied zu Parallelrechnern Software: Benutzer sieht ein System Wer ist der Benutzer? Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 3 / 28
Begriffsklärung (2) Verteiltes System Ein Verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes kohärentes System erscheinen [TAN]. Hardware: Autonome Maschinen Unterschied zu Parallelrechnern Software: Benutzer sieht ein System Wer ist der Benutzer? Warum Verteilte Systeme? Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 3 / 28
Warum Verteilte Systeme? Nur weil es technisch möglich ist, muss es noch lange keinen Sinn machen! (nach [TAN]) Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 4 / 28
Warum Verteilte Systeme? Nur weil es technisch möglich ist, muss es noch lange keinen Sinn machen! (nach [TAN]) If you do not need a distributed system, do not distribute [VER]. Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 4 / 28
Warum Verteilte Systeme? Nur weil es technisch möglich ist, muss es noch lange keinen Sinn machen! (nach [TAN]) If you do not need a distributed system, do not distribute [VER]. Warum macht es Sinn? Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 4 / 28
Warum Verteilte Systeme? Nur weil es technisch möglich ist, muss es noch lange keinen Sinn machen! (nach [TAN]) If you do not need a distributed system, do not distribute [VER]. Warum macht es Sinn? Zugriff auf entfernte Resourcen (Web Seiten, Spezialhardware, Shop, Datenbank, Rechenleistung,...) Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 4 / 28
Warum Verteilte Systeme? Nur weil es technisch möglich ist, muss es noch lange keinen Sinn machen! (nach [TAN]) If you do not need a distributed system, do not distribute [VER]. Warum macht es Sinn? Zugriff auf entfernte Resourcen (Web Seiten, Spezialhardware, Shop, Datenbank, Rechenleistung,...) Wenn schon verteilt, dann aber bitte einfach... Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 4 / 28
Warum Verteilte Systeme? Nur weil es technisch möglich ist, muss es noch lange keinen Sinn machen! (nach [TAN]) If you do not need a distributed system, do not distribute [VER]. Warum macht es Sinn? Zugriff auf entfernte Resourcen (Web Seiten, Spezialhardware, Shop, Datenbank, Rechenleistung,...) Wenn schon verteilt, dann aber bitte einfach... Transparenz: Benutzer sieht Verteilung nicht/kaum Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 4 / 28
Warum Verteilte Systeme? Nur weil es technisch möglich ist, muss es noch lange keinen Sinn machen! (nach [TAN]) If you do not need a distributed system, do not distribute [VER]. Warum macht es Sinn? Zugriff auf entfernte Resourcen (Web Seiten, Spezialhardware, Shop, Datenbank, Rechenleistung,...) Wenn schon verteilt, dann aber bitte einfach... Transparenz: Benutzer sieht Verteilung nicht/kaum... schnell und zuverlässig wäre auch nicht schlecht... Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 4 / 28
Warum Verteilte Systeme? Nur weil es technisch möglich ist, muss es noch lange keinen Sinn machen! (nach [TAN]) If you do not need a distributed system, do not distribute [VER]. Warum macht es Sinn? Zugriff auf entfernte Resourcen (Web Seiten, Spezialhardware, Shop, Datenbank, Rechenleistung,...) Wenn schon verteilt, dann aber bitte einfach... Transparenz: Benutzer sieht Verteilung nicht/kaum... schnell und zuverlässig wäre auch nicht schlecht... Skalierbarkeit und Fehlertoleranz Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 4 / 28
Warum Verteilte Systeme? Nur weil es technisch möglich ist, muss es noch lange keinen Sinn machen! (nach [TAN]) If you do not need a distributed system, do not distribute [VER]. Warum macht es Sinn? Zugriff auf entfernte Resourcen (Web Seiten, Spezialhardware, Shop, Datenbank, Rechenleistung,...) Wenn schon verteilt, dann aber bitte einfach... Transparenz: Benutzer sieht Verteilung nicht/kaum... schnell und zuverlässig wäre auch nicht schlecht... Skalierbarkeit und Fehlertoleranz... und wie sieht es mit Sicherheit aus? Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 4 / 28
Gliederung 1 Motivation 2 Arten von Verteilte Systeme 3 Ein Modell für Verteilte Systeme 4 Vom Modell zur Implementierung 5 Nicht-funktionale Eigenschaften 6 Abschließende Bemerkungen Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 5 / 28
Verteilung als Anwendungsangelegenheit Kommunizierende Anwendungen Machine A Machine B Machine C Distributed applications Network OS services Network OS services Network OS services Kernel Kernel Kernel Network Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 6 / 28
Verteilung als Anwendungsangelegenheit Kommunizierende Anwendungen PRO: Wenig Overhead Individuell auf Anwendung abgestimmt Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 7 / 28
Verteilung als Anwendungsangelegenheit Kommunizierende Anwendungen PRO: Wenig Overhead Individuell auf Anwendung abgestimmt CONTRA: Proprietär Kaum interoperabel Nicht wiederverwendbar Basisfunktionalität für jede Anwendung neu Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 7 / 28
Verteilung als Anwendungsangelegenheit Kommunizierende Anwendungen PRO: Wenig Overhead Individuell auf Anwendung abgestimmt CONTRA: Proprietär Kaum interoperabel Nicht wiederverwendbar Basisfunktionalität für jede Anwendung neu Beispiele: World Wide Web, FTP,... Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 7 / 28
Verteilung als Middlewareangelegenheit Middlewaresysteme Machine A Machine B Machine C Distributed applications Middleware services Network OS services Network OS services Network OS services Kernel Kernel Kernel Network Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 8 / 28
Verteilung als Middlewareangelegenheit Middlewaresysteme PRO: Middleware von beliebigen Anwendungen benutzbar Interoperabel Darstellungstransparenz Höherwertige Dienste Location Service Name Service Einfach zu programmieren Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 9 / 28
Verteilung als Middlewareangelegenheit Middlewaresysteme PRO: Middleware von beliebigen Anwendungen benutzbar Interoperabel Darstellungstransparenz Höherwertige Dienste Location Service Name Service Einfach zu programmieren CONTRA: Teilweise hoher Overhead teuer Middleware wird auf jeder Maschine benötigt Komplex zu programmieren Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 9 / 28
Verteilung als Middlewareangelegenheit Middlewaresysteme PRO: Middleware von beliebigen Anwendungen benutzbar Interoperabel Darstellungstransparenz Höherwertige Dienste Location Service Name Service Einfach zu programmieren CONTRA: Teilweise hoher Overhead teuer Middleware wird auf jeder Maschine benötigt Komplex zu programmieren Beispiele: CORBA, Java RMI, WebServices [WEB],... Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 9 / 28
Verteilung als Betriebssystemangelegenheit Verteilte Betriebssysteme Machine A Machine B Machine C Distributed applications Distributed operating system services Kernel Kernel Kernel Network Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 10 / 28
Verteilung als Betriebssystemangelegenheit Verteilte Betriebssysteme PRO: Verteilung völlig transparent für Anwender, Programmierer, höhere Betriebssystemdienste Verteilung wird zur Laufzeit festgelegt Geschlossenes System Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 11 / 28
Verteilung als Betriebssystemangelegenheit Verteilte Betriebssysteme PRO: Verteilung völlig transparent für Anwender, Programmierer, höhere Betriebssystemdienste Verteilung wird zur Laufzeit festgelegt Geschlossenes System CONTRA: Geschlossenes System Alle Anwendungen potentiell verteilt Hoher Entwicklungsaufwand (Treiber, Tools, Compiler) Höherer Entwicklungsaufwand bei heterogenen Systemen Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 11 / 28
Verteilung als Betriebssystemangelegenheit Verteilte Betriebssysteme PRO: Verteilung völlig transparent für Anwender, Programmierer, höhere Betriebssystemdienste Verteilung wird zur Laufzeit festgelegt Geschlossenes System CONTRA: Geschlossenes System Alle Anwendungen potentiell verteilt Hoher Entwicklungsaufwand (Treiber, Tools, Compiler) Höherer Entwicklungsaufwand bei heterogenen Systemen Beispiele: Emerald, Amoeba, Plurix/GreenOS [PLURIX],... Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 11 / 28
Verteilungsansätze im Überblick Transp arenz Prog rammiera ufwand Anwendung Middleware Betriebssystem Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 12 / 28
Verteilungsansätze im Überblick Transp arenz Prog rammiera ufwand Anwendung Middleware Betriebssystem S kalierbark eit Effizienz Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 13 / 28
Gliederung 1 Motivation 2 Arten von Verteilte Systeme 3 Ein Modell für Verteilte Systeme 4 Vom Modell zur Implementierung 5 Nicht-funktionale Eigenschaften 6 Abschließende Bemerkungen Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 14 / 28
Verteile Systeme: ein Modell Eine abstrakte Sicht Abstraktion von der Sicht des Anwenders, Programmierers Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 15 / 28
Verteile Systeme: ein Modell Eine abstrakte Sicht Abstraktion von der Sicht des Anwenders, Programmierers Aktivitätsträger auf den einzelnen Knoten Abstrakte Prozesse Kommunikationswege zwischen den Knoten Kanäle Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 15 / 28
Verteile Systeme: ein Modell Eine abstrakte Sicht Abstraktion von der Sicht des Anwenders, Programmierers Aktivitätsträger auf den einzelnen Knoten Abstrakte Prozesse Kommunikationswege zwischen den Knoten Kanäle Verteiltes System A distributed computing system is composed of several autonomous processors without shared main memory, but cooperating by message passing over a communication network [BAL]. Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 15 / 28
Kanäle Kanal Ein Kanal ist eine Verbindung zwischen Prozessen zum Austausch von Nachrichten. Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 16 / 28
Kanäle Kanal Ein Kanal ist eine Verbindung zwischen Prozessen zum Austausch von Nachrichten. Mögliche Eigenschaften: Verlustfrei (lossless) Verlust von endlich vielen Nachrichten (fair lossy) Erfindet keine neuen Nachrichten (no creation) Duplikationsfrei (no duplication) FIFO Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 16 / 28
Kanäle Kanal Ein Kanal ist eine Verbindung zwischen Prozessen zum Austausch von Nachrichten. Mögliche Eigenschaften: Verlustfrei (lossless) Verlust von endlich vielen Nachrichten (fair lossy) Erfindet keine neuen Nachrichten (no creation) Duplikationsfrei (no duplication) FIFO Entsprechung in der Realität: Physikalische Verbindung zwischen Maschinen Protokolle/Komponenten, die zwischen Sender und Empfänger liegen HW-Protokolle, SW-Protokolle, BS Puffer Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 16 / 28
Abstrakte Prozesse Abstrakter Prozess Ein abstrakter Prozess ist ein Vorgang auf einer Maschine, der einen bestimmten Algorithmus realisiert und dabei mit anderen Prozessen Nachrichten austauscht. Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 17 / 28
Abstrakte Prozesse Abstrakter Prozess Ein abstrakter Prozess ist ein Vorgang auf einer Maschine, der einen bestimmten Algorithmus realisiert und dabei mit anderen Prozessen Nachrichten austauscht. Oft: Rundenbasiert: Berechnung Nachricht Berechnung... Idealisierte Annahmen: unendlicher Speicher, Berechnungen kosten nichts,... Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 17 / 28
Abstrakte Prozesse Abstrakter Prozess Ein abstrakter Prozess ist ein Vorgang auf einer Maschine, der einen bestimmten Algorithmus realisiert und dabei mit anderen Prozessen Nachrichten austauscht. Oft: Rundenbasiert: Berechnung Nachricht Berechnung... Idealisierte Annahmen: unendlicher Speicher, Berechnungen kosten nichts,... Entsprechung in der Realität: Thread(s) BS-Prozess Gruppe von BS-Prozessen Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 17 / 28
Abstrakte Prozesse (2) Fehlermodelle: Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 18 / 28
Abstrakte Prozesse (2) Fehlermodelle: Kein Fehler Crash-Stop Crash-Recovery Eingeschränkt Byzantinisch Byzantinisch Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 18 / 28
Abstrakte Prozesse (2) Fehlermodelle: Kein Fehler Crash-Stop Crash-Recovery Eingeschränkt Byzantinisch Byzantinisch Parameter: Anzahl tolerierbare Fehler Fehlerunabhängigkeit Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 18 / 28
Synchronität Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 19 / 28
Synchronität Synchrones Verteiltes System: Nachrichtenlaufzeit und Zeit pro Operation begrenzt Obere Grenzen existieren und sind bekannt Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 19 / 28
Synchronität Synchrones Verteiltes System: Nachrichtenlaufzeit und Zeit pro Operation begrenzt Obere Grenzen existieren und sind bekannt Asynchrones Verteiltes System: Keine physikalische Zeit Nachrichtenlaufzeit und Zeit pro Operation unbegrenzt Unlösbarkeit einiger Probleme z.b. Konsensus und zuverlässige Fehlererkennung [FLP] Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 19 / 28
Synchronität Synchrones Verteiltes System: Nachrichtenlaufzeit und Zeit pro Operation begrenzt Obere Grenzen existieren und sind bekannt Asynchrones Verteiltes System: Keine physikalische Zeit Nachrichtenlaufzeit und Zeit pro Operation unbegrenzt Unlösbarkeit einiger Probleme z.b. Konsensus und zuverlässige Fehlererkennung [FLP] Entsprechung in der Realität: Reale Systeme i.d.r weder synchron noch vollständig asynchron Verwendung von Zwischenmodellen (eventual synchrony, oracles) Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 19 / 28
Gliederung 1 Motivation 2 Arten von Verteilte Systeme 3 Ein Modell für Verteilte Systeme 4 Vom Modell zur Implementierung 5 Nicht-funktionale Eigenschaften 6 Abschließende Bemerkungen Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 20 / 28
Implementierung Verteilter Anwendungen Nicht-verteilte Anwendungen: Programmiersprache Bibliotheken Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 21 / 28
Implementierung Verteilter Anwendungen Nicht-verteilte Anwendungen: Programmiersprache Bibliotheken Verteilte Anwendungen: Programmiersprache Bibliotheken Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 21 / 28
Implementierung Verteilter Anwendungen Nicht-verteilte Anwendungen: Programmiersprache Bibliotheken Verteilte Anwendungen: Programmiersprache Bibliotheken Middleware, Betriebssystem Verteilungseinheit Kommunikationsstrategie Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 21 / 28
Implementierung Verteilter Anwendungen Nicht-verteilte Anwendungen: Programmiersprache Bibliotheken Verteilte Anwendungen: Programmiersprache Bibliotheken Middleware, Betriebssystem Verteilungseinheit Kommunikationsstrategie Verteilte Systeme zu programmieren ist mehr als in einer Programmiersprache denken! Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 21 / 28
Verteiltes Programmiermodell Ein verteiltes Programmiermodell legt fest [HAUCK]: In welche Einzelteile eine Anwendung zerlegt werden kann. Wie die Art der Kommunikation zwischen den Einzelteilen aussieht. Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 22 / 28
Verteiltes Programmiermodell Ein verteiltes Programmiermodell legt fest [HAUCK]: In welche Einzelteile eine Anwendung zerlegt werden kann. Wie die Art der Kommunikation zwischen den Einzelteilen aussieht. Beispiele für Einzelteile: Daten Instruktionen Objekte Dienste Aktivitätsträger... Kombinationen davon Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 22 / 28
Verteiltes Programmiermodell Ein verteiltes Programmiermodell legt fest [HAUCK]: In welche Einzelteile eine Anwendung zerlegt werden kann. Wie die Art der Kommunikation zwischen den Einzelteilen aussieht. Beispiele für Einzelteile: Daten Instruktionen Objekte Dienste Aktivitätsträger... Kombinationen davon Häufige Kommunikationsarten: Nachrichtenbasiert Strombasiert Aufrufbasiert Speicherbasiert Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 22 / 28
Gliederung 1 Motivation 2 Arten von Verteilte Systeme 3 Ein Modell für Verteilte Systeme 4 Vom Modell zur Implementierung 5 Nicht-funktionale Eigenschaften 6 Abschließende Bemerkungen Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 23 / 28
Zuverlässigkeit/Fehlertoleranz Verteiltes System A distributed system is one in which the failure of a computer you did not even know existed can render your own computer unusable. (Leslie Lamport) Zentrale Dienste sollten: Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 24 / 28
Zuverlässigkeit/Fehlertoleranz Verteiltes System A distributed system is one in which the failure of a computer you did not even know existed can render your own computer unusable. (Leslie Lamport) Zentrale Dienste sollten: Nicht ausfallen Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 24 / 28
Zuverlässigkeit/Fehlertoleranz Verteiltes System A distributed system is one in which the failure of a computer you did not even know existed can render your own computer unusable. (Leslie Lamport) Zentrale Dienste sollten: Nicht ausfallen Unrealistisch Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 24 / 28
Zuverlässigkeit/Fehlertoleranz Verteiltes System A distributed system is one in which the failure of a computer you did not even know existed can render your own computer unusable. (Leslie Lamport) Zentrale Dienste sollten: Nicht ausfallen Unrealistisch Dezentral implementiert sein Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 24 / 28
Zuverlässigkeit/Fehlertoleranz Verteiltes System A distributed system is one in which the failure of a computer you did not even know existed can render your own computer unusable. (Leslie Lamport) Zentrale Dienste sollten: Nicht ausfallen Unrealistisch Dezentral implementiert sein Nicht immer machbar Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 24 / 28
Zuverlässigkeit/Fehlertoleranz Verteiltes System A distributed system is one in which the failure of a computer you did not even know existed can render your own computer unusable. (Leslie Lamport) Zentrale Dienste sollten: Nicht ausfallen Unrealistisch Dezentral implementiert sein Nicht immer machbar Replikation mit wenigen Replikaten Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 24 / 28
Zuverlässigkeit/Fehlertoleranz Verteiltes System A distributed system is one in which the failure of a computer you did not even know existed can render your own computer unusable. (Leslie Lamport) Zentrale Dienste sollten: Nicht ausfallen Unrealistisch Dezentral implementiert sein Nicht immer machbar Replikation mit wenigen Replikaten Konsistenz wird zum Problem Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 24 / 28
Skalierbarkeit Benutzersicht: Leistung des Systems nicht von der Zahl der Knoten abhängig Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 25 / 28
Skalierbarkeit Benutzersicht: Leistung des Systems nicht von der Zahl der Knoten abhängig Systemsicht: Hinzunahme von Knoten nicht negative für Gesamtleistung Im besten Fall: Leistung proportional zur Anzahl der Knoten Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 25 / 28
Skalierbarkeit Benutzersicht: Leistung des Systems nicht von der Zahl der Knoten abhängig Systemsicht: Hinzunahme von Knoten nicht negative für Gesamtleistung Im besten Fall: Leistung proportional zur Anzahl der Knoten Herausforderungen: Verzicht auf zentrale Einrichtungen Partitionierung von Daten Dezentrale Algorithmen (z.b. epidemische Algorithmen) Keine globalen Uhren Verzicht auf globale Informationen Ausfall von Maschinen hat keine Auswirkungen Entscheidungsfindung allein auf lokalen Informationen Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 25 / 28
Andere nicht-funktionale Eigenschaften Sicherheit: Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 26 / 28
Andere nicht-funktionale Eigenschaften Sicherheit: Verfügbarkeit Authentizität: Echtheit muss überprüfbar sein Vertraulichkeit: Information ist nur für Befugte zugänglich Integrität: Daten bleiben unverändert (Daten- und Fälschungssicherheit) Nicht-Anfechtbarkeit: Nachricht wurde versendet und empfangen Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 26 / 28
Andere nicht-funktionale Eigenschaften Sicherheit: Verfügbarkeit Authentizität: Echtheit muss überprüfbar sein Vertraulichkeit: Information ist nur für Befugte zugänglich Integrität: Daten bleiben unverändert (Daten- und Fälschungssicherheit) Nicht-Anfechtbarkeit: Nachricht wurde versendet und empfangen Dienstqualität: Anforderungen an Datenübertragung Daten- und Fehlerrate Dauer des Verbindungsaufbaus Anwendung, z.b. Voice-over-IP Video-on-Demand Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 26 / 28
Abschließende Bemerkungen Verteilte Systeme: Eine vielseitige Disziplin Verschiedene Ansätze und Sichten Theorie und Praxis Adressiert Anwender, Programmierer Noch viele offene Fragen Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 27 / 28
Abschließende Bemerkungen Verteilte Systeme: Eine vielseitige Disziplin Verschiedene Ansätze und Sichten Theorie und Praxis Adressiert Anwender, Programmierer Noch viele offene Fragen Vertiefende Veranstaltungen Architektur für verteilte Objekte (WS) Architektur für verteilte Internetdienste (SS) Betriebssysteme (SS) Multimediakommunikation (WS) Verteilte Betriebssysteme (WS) (Individual-)Praktika und Seminare Diplom-/Masterarbeiten Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 27 / 28
Jo rg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 28 / 28
Literatur [TAN] A. S. Tanenbaum and M. van Steen. Verteilte Systeme, Grundlagen und Paradigmen. [WEB] Gustavo Alonso, Fabio Casati, and Harumi Kuno. Web Services. Concepts, Architectures and Applications. [BAL] H. E. Bal. Programming Distributed Systems. [VER] P. Veríssimo and L. Rodrigues. Distributed Systems for System Architects. [FLP] M. J. Fischer, N. A. Lynch, and M. S. Paterson. Impossibility of distributed consensus with one faulty process. [HAUCK] F. J. Hauck. Dienstqualität in objektbasierten Verteilten Systemen. [PLURIX] S. Frenz, M. Schöttner, R. Göckelmann, and P. Schulthess. Transactional Cluster Computing. Jörg Domaschka (Aspectix Research Team) Taxonomie Verteilter Systeme 15. November 2007 29 / 28