Verteiltes System
aus Wikipedia, der freien Enzyklopädie
Ein Verteiltes System ist nach der Definition von Andrew Tanenbaum ein Zusammenschluss unabhängiger Computer, welcher sich für den Benutzer als ein einzelnes System präsentiert. Peter Löhr definiert es etwas grundlegender als „eine Menge interagierender Prozesse (oder Prozessoren), die über keinen gemeinsamen Speicher verfügen und daher über Nachrichten miteinander kommunizieren“.
Inhaltsverzeichnis |
[Bearbeiten] Klassifizierungen
Meist unterscheidet man in
- Client-Server-System: Viele Clients greifen auf einen Server zu.
- Verteilte Anwendung: Durch die Programmierung der Anwendung wird das verteilte System erstellt.
- Verteiltes Betriebssystem: Das Betriebssystem selbst ist verteilt, für Benutzer und Anwendungen ist dies nicht sichtbar.
[Bearbeiten] Gründe
Es gibt unterschiedliche Motivationen dafür, ein Verteiltes System zu realisieren. Ein Grund ist die Realisierung echter Nebenläufigkeit; das heißt, dass mehrere Prozesse echt gleichzeitig ausgeführt werden können. Darüber hinaus ist ein Verteiltes System in der Regel auch besser skalierbar als ein einzelner Computer, da man auf einfache Art und Weise durch Hinzufügen weiterer Rechner die Leistungsfähigkeit erhöhen kann. Zudem ist es auch möglich, ein Verteiltes System so anzulegen, dass brachliegende Rechenleistung von Einzelplatzrechnern zur Lösung eines Problems genutzt werden, wie es beim verteilten Rechnen (Beispiel: SETI@home) geschieht.
Ein häufig anzutreffendes Szenario ist natürlich auch die Bereitstellung von entfernten Ressourcen, wie es bei der Wikipedia der Fall ist. Außerdem werden Verteilte Systeme zur Fehlervermeidung benutzt, indem bestimmte Funktionalitäten von mehreren Rechnern angeboten werden (Redundanz), so dass beim Ausfall eines Rechners die gleiche Funktionalität von einem weiteren Rechner angeboten wird.
In vielen Fällen gibt es auch wirtschaftliche Gründe, um preisgünstige Rechner zu vernetzen, statt einen teuren Supercomputer anzuschaffen.
Weitere Gründe:
- geringere Fehleranfälligkeit (Ereichbarkeit durch redundante/replizierte Server; Ausfallsicherheit durch Backups)
- Fernzugriff auf bestimmte Ressourcen (Drucker, ..)
- Kooperation (siehe CSCW)
- Lastverteilung (Je nach Last kann eine Aufgabe zum größeren Teil auf dem Server oder seinen Klienten ausgeführt werden (siehe AJAX als Beispiel zur Berechnung auf dem Klienten und JSP, CGI, ... als Beispiel zur Berechnung auf dem Server)
[Bearbeiten] Transparenz
Für den Benutzer eines verteilten Systems ist die Art der Verteilung nicht relevant und idealerweise auch nicht ersichtlich. Das System verhält sich transparent, als hätte der Nutzer es mit einem Gesamtsystem zu tun.
Bei dieser Transparenz unterscheidet man:
- Ortstransparenz: Der Ort, an dem sich ein Dienst oder eine Ressource befindet ist dem Benutzer nicht bekannt. Der Zugriff erfolgt über einen bestimmten Namen, der allerdings keine Ortsinformationen enthält.
- Zugriffstransparenz: Der Zugriff auf einen Dienst oder eine Ressource erfolgt immer auf die gleiche Art und Weise, gleich ob diese sich lokal oder entfernt im Netz befindet.
- Nebenläufigkeitstransparenz: Es ist mehreren Benutzer möglich, gleichzeitig auf die Dienste und Ressourcen zuzugreifen. Das System sorgt dafür, dass exklusive Zugriffe möglich sind, und Daten eventuell synchronisiert bzw. repliziert werden.
- Skalierungstransparenz: Das System soll flexibel bei der Erweiterung oder dem Austausch von Komponenten sein. Eine Systempflege oder Erweiterung soll ohne Ausfall möglich sein und ist sehr wichtig für die Verfügbarkeit von Verteilten Systemen.
- Migrationstransparenz: Das Verschieben von Objekten im Verteilten System soll für den Benutzer und die Anwendungen unbemerkt geschehen.
- Prozesstransparenz: Programme können beliebig zwischen den Knoten des Verteilten Systems verschoben werden. Idealerweise sorgt das System selbst für die Verschiebung von Prozessen auf weniger ausgelastete Knoten. Der Name und Ausführungsstatus eines Programmes darf sich dabei nicht ändern.
- Leistungstransparenz: Den Benutzern steht die volle Leistung des Gesamtsystems zur Verfügung. Das System sorgt selbst dafür, dass die Aufgaben auf die verschiedenen Knoten optimal verteilt werden.
- Replikationstransparenz: Aus Performancegründen kann es mehrere Kopien derselben Ressource geben. Das System sorgt für die transparente Replikation der darin vorgenommenen Änderungen.
- Fragmentierungstransparenz: Die Teilbestandteile einer Ressource können auf verschiedenen Orten gespeichert sein
- Fehler- und Ausfalltransparenz: Beim Ausfall eines Systems oder einer Netzwerkverbindung sollte der Anwender weiterarbeiten können, wenn auch mit verminderter Leistung.
- Sprachtransparenz: Die Kommunikation zwischen den Komponenten ist unabhängig von der jeweils verwendeten Programmiersprache.
[Bearbeiten] Probleme
Da es bei Verteilten Systemen zu einem Teilausfall kommen kann, von dem einzelne Rechner oder Teile des Netzwerkes betroffen sind, sollte man darauf achten, dass es keinen single point of failure im System gibt. Dabei ist zu bemerken, dass die Wahrscheinlichkeit eines Absturzes natürlich mit der Anzahl der beteiligten Rechner steigt (siehe Verfügbarkeit).
In Verteilten Systemen ist zwar eine echte Nebenläufigkeit möglich, allerdings können Prozesse in unterschiedlichen Geschwindigkeiten abgearbeitet werden. Zudem können Abläufe in einem Verteilten System oft im Nachhinein nicht genauso nachvollzogen werden.
Verteilte Systeme teilen sich keinen gemeinsamen Speicher und müssen ihre gesamte Kommunikation darum durch das Versenden und Empfangen von Nachrichten realisieren. Eine solche Kommunikation ist sehr fehleranfällig, so dass es zu Problemen durch Verfälschung von Nachrichten, Duplizierung von Nachrichten und den Verlust von Nachrichten kommen kann. Außerdem ist die Nachrichtenlaufzeit unvorhersehbar, so dass man nie mit Sicherheit vorhersehen kann, ob ein System ausgefallen ist oder ob es nur eine lange Antwortzeit hat.
Ein weiteres Problem der Nachrichten ist, dass diese Art der Kommunikation unsicher sein kann, also durch Angreifer abgehört oder bewusst manipuliert werden könnte (siehe Datensicherheit).
[Bearbeiten] Modelle
Bei verteilten Systemen geht man von unterschiedlichen Kommunikationsmodellen aus.
[Bearbeiten] Asynchrones Modell
Prozesse haben im Asynchronen Modell nur den Zustand aktiv und passiv. Nur ein aktiver Prozess versendet Nachrichten. Ein aktiver Prozess kann jederzeit passiv werden, wohingegen ein passiver Prozess nur durch eine Nachricht reaktiviert werden kann.
(siehe auch Asynchrone Kommunikation)
[Bearbeiten] Synchrones Modell
Beim synchronen Modell haben Nachrichten selbst keine Laufzeit. Diese Verhaltensweise wird in der Praxis durch die Synchrone Kommunikation erreicht.
[Bearbeiten] Atommodell
Beim Atommodell haben zwar die Nachrichten eine Laufzeit, allerdings haben die Prozesse selbst keine Laufzeit.
[Bearbeiten] Algorithmen
[Bearbeiten] Broadcastalgorithmen
Das Ziel eines Broadcasts ist die Verteilung einer Information im gesamten Netz.
Beispiele:
[Bearbeiten] Auswahlalgorithmen
Auswahlalgorithmen können in zwei Kategorien unterteilt werden: Algorithmen, die aus einer Menge von identischen Knoten einen eindeutigen Knoten auswählen und Maximumsalgorithmen, die aus einer Menge von Knoten mit eindeutiger ID den Knoten mit der größten ID auswählen.
Beispiele:
- Bullyalgorithmus
- Nachrichtenauslöschung nach Chang und Roberts
- Randomisierte Auswahl in bidirektionalen Ringen
- Las Vegas-Auswahl für anonyme Ringe
- Hirschberg/Sinclair-Auswahlalgorithmus
- Wahlalgorithmus auf Bäumen
- Echo-Algorithmus
- Itai-Rodeh-Algorithmus (Auswahl auf anonymen unidirektionalen Ringen)
- Peterson-Auswahlalgorithmus (Auswahl auf Ringen)
[Bearbeiten] Siehe auch
- Logische Uhren
- Transaktionssystem
- CORBA
- RPC
- Grid-Computing
- Byzantinische Verteilung
- Ricart-Agrawala-Algorithmus
[Bearbeiten] Literatur
- Andrew S. Tanenbaum, Maarten van Steen: Verteilte Systeme. Pearson Studium, 2003, ISBN 3827370574
- Günther Bengel: Verteilte Systeme, 3. Auflage, Vieweg, 2004, ISBN 3528257385
