Verteiltes System

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Dieser Artikel oder Abschnitt bedarf einer Überarbeitung. Näheres ist auf der Diskussionsseite angegeben. Hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

Ein Verteiltes System ist nach der Definition von Andrew Tanenbaum ein Zusammenschluss unabhängiger Computer, die sich für den Benutzer als ein einziges System präsentieren. 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“.

Klassifizierungen[Bearbeiten]

Meist unterscheidet man in

Gründe[Bearbeiten]

Mit verteilten Systemen kann eine echte Nebenläufigkeit realisiert werden; 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 wird, 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 Erhöhung der Ausfallsicherheit 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:[1]

Transparenz[Bearbeiten]

Für den Benutzer sowie für die Applikation eines verteilten Systems ist die Art der Verteilung nicht relevant und idealerweise auch nicht ersichtlich. Das System verhält sich transparent (i.S.v. durchsichtig), als hätte der Nutzer es mit einem Gesamtsystem zu tun.

Probleme[Bearbeiten]

Da es bei verteilten Systemen zu einem Teilausfall kommen kann, von dem einzelne Rechner oder Teile des Netzwerkes betroffen sind, sollte darauf geachtet werden, dass es keinen Single Point of Failure im System gibt. Dabei ist zu bemerken, dass die Wahrscheinlichkeit eines Fehlverhaltens eines Prozesses mit der Anzahl der beteiligten Prozesse steigt (siehe Verfügbarkeit).

Ein wichtiges Teilproblem davon ist, einen Teilausfall erst zu bemerken. Es existieren keine voll zufriedenstellenden Methoden, die einen Teilausfall erkennen und beheben können. Eine Möglichkeit wäre der Heartbeat oder ein regelmäßiges Anpingen der beteiligten Systeme. Diese Möglichkeiten sind jedoch nicht perfekt.

In verteilten Systemen ist zwar eine echte Nebenläufigkeit möglich, allerdings können Prozesse in unterschiedlichen Geschwindigkeiten abgearbeitet werden. Eine hierdurch bedingte starke Form von Nicht-Determinismus erhöht die Anforderungen zur Synchronisierung von Prozessen. Aus diesem Grunde ist eine Nebenläufigkeitskontrolle meist sehr wichtig: Zum einen im Bezug auf Transaktionen und zum anderen beim Zugriff auf gemeinsame Ressourcen (Mutex). Außerdem kann es in verteilten Systemen immer Deadlocks geben.

Gesamtzustände (Summe der Zustände aller beteiligten Prozesse) und Abläufe können in einem verteilten System oft im Nachhinein nicht nachvollzogen werden. Eine Diagnose im Fehlerfall wird hierdurch erschwert.

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 kann, und über eine Infrastruktur laufen muss, die (wie das Internet) vielleicht nicht vollständig für Gruppen-basierte Kommunikation geeignet ist

Bei komplexen Prozessen ist es oft notwendig, einen gemeinsamen Zeitbegriff in der Datenverarbeitung zu realisieren (Synchronisierung ohne Prozess-Kommunikation). Hierfür muss sichergestellt werden, dass die jedem Prozess bekannte Zeit nur mit kleinen Abweichungen übereinstimmt. So lassen sich verteilte Transaktionen sicher durchführen, da hier mit Hilfe von Timeouts eine Veralterung ausgesendeter Nachrichten vermieden wird. (Siehe auch „Algorithmen zur Uhren-Synchronisation“ unten).

Außerdem erschweren verteilte Systeme die (zentrale) Administration sehr, besonders bei nicht-strukturierten Topologien. Je nach Anwendung (SETI@home) treffen Millionen unterschiedlich konfigurierter Rechner aufeinander, die außerdem noch völlig fremden Personen gehören, die "bei Laune" gehalten werden müssen. Eine Administration einer zentralen Anwendung ist deutlich einfacher als die einer verteilten Anwendung.[2][3]

Modelle[Bearbeiten]

Bei verteilten Systemen geht man von unterschiedlichen Kommunikationsmodellen aus.

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.
Synchrones Modell
Beim synchronen Modell haben Nachrichten selbst keine Laufzeit. Diese Verhaltensweise wird in der Praxis durch die Synchrone Kommunikation erreicht.
Atommodell
Beim Atommodell haben zwar die Nachrichten eine Laufzeit, allerdings haben die Prozesse selbst keine Laufzeit.

Algorithmen[Bearbeiten]

Algorithmen zur Uhren-Synchronisation[Bearbeiten]

Logische Uhren
Logische Uhren geben Ereignissen eindeutige Zeitstempel. Anders als bei Echtzeituhren ist der Anspruch hier nicht das Messen der physikalischen Zeit, sondern allein ein monoton steigender Zeitwert, um eine Kausalordnung der Ereignisse erkennbar zu machen.
Physikalische Uhren-Synchronisation

Broadcastalgorithmen[Bearbeiten]

Das Ziel eines Broadcasts ist die Verteilung einer Information im gesamten Netz.

Beispiele:

Auswahlalgorithmen[Bearbeiten]

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:

Nebenläufigkeitskontrolle[Bearbeiten]

Siehe auch[Bearbeiten]

Literatur[Bearbeiten]

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Distributed Systems Principles (PDF; 78 kB)
  2. Andrew Warfield, Yvonne Coady, and Norm Hutchinson: Identifying Open Problems In Distributed Systems (PDF; 40 kB)
  3. Security Engineering: A Guide to Building Dependable Distributed Systems, Kapitel 6 (PDF; 568 kB)