Was sind verteilte Systeme?

Verteilte Systeme verteilen Aufgaben und Daten auf mehrere gleichzeitig laufende Geräte, sodass eine Aufgabe, für die eine große Maschine Wochen gebraucht hätte, in Stunden oder sogar Minuten erledigt werden kann. Jede Maschine – oder jeder „Knoten“ – im System verfügt über eine eigene CPU, einen eigenen Arbeitsspeicher und oft auch einen eigenen Datenspeicher. Die Knoten können sich untereinander Nachrichten senden, um den Datenaustausch zu koordinieren, Aufgaben aufteilen und ihre Arbeit auf ein gemeinsames Ziel ausrichten.

In einem verteilten System befinden sich Maschinen oft im selben Server-Rack (eines Rechenzentrums), in verschiedenen Rechenzentren oder in hybriden Cloud-Umgebungen, die auf der ganzen Welt verteilt sind. Unabhängig von der Konfiguration sind verteilte Systeme so konzipiert, dass Benutzer und Client-Anwendungen mit ihnen interagieren, als wären sie ein Dienst („eine Datenbank“, „eine Website“, „ein Speicherdienst“) und nicht eine Gruppe einzelner Server.

Verteilte Systeme bieten Unternehmen eine Lösung für dringende Herausforderungen der modernen Datenverarbeitung. Viele der heutigen Anwendungen sind zu groß, zu ausgelastet oder zu kritisch, um auf einem einzelnen Computer einwandfrei ausgeführt zu werden. Diese Anwendungen verarbeiten häufig riesige Datenmengen und Anfragen, die einen einzelnen Server überfordern könnten. Sie beschäftigen sich mit sprunghaften Verkehrsströmen, die flexible Funktionen zur Lastverteilung erfordern. Sie verwalten geschäftskritische Prozesse, bei denen umfangreiche Ausfallzeiten katastrophal sein können (zum Beispiel Banksysteme).

Verteilte Systeme verteilen Workloads über mehrere Knoten und nehmen automatisch weitere Knoten nach Bedarf ins Netzwerk auf. Diese Skalierbarkeit ermöglicht es dem System, mehr Benutzer und Daten aufzunehmen, selbst wenn der Verkehrsfluss unvorhersehbar ist. Die Skalierbarkeit verteilter Systeme ist der Grund dafür, dass Streaming-Plattformen beispielsweise Millionen von Benutzern auf der ganzen Welt oft gleichzeitig bedienen können.

Verteilte Systeme tragen außerdem dazu bei, die Zuverlässigkeit und Fehlertoleranz einer IT-Architektur zu optimieren. Wenn ein Knoten ausfällt, können andere Knoten dessen Arbeit übernehmen, so dass der Dienst insgesamt weiterläuft. Diese Funktion reduziert einzelne Fehlerpunkte und hilft Unternehmen, hochverfügbare Systeme aufrechtzuerhalten, was für Systeme entscheidend ist, die nahezu 100 % Betriebszeit benötigen.

Außerdem arbeiten in einem verteilten System die einzelnen Knoten eng zusammen, haben aber ihre eigenen Datenbanken und Speichersysteme. Diese Anordnung erleichtert es IT-Teams, modulare Architekturen zu entwickeln, bei denen verschiedene Teile des Systems unabhängig voneinander skalieren und sich weiterentwickeln können.

Verteilte Systeme umfassen eine Reihe unterschiedlicher Architekturen, aber sie alle weisen eine Reihe gemeinsamer Kernmerkmale auf.

Um zu verstehen, wie verteilte Systeme funktionieren, nehmen wir das Beispiel von Massively Multiplayer Online Games (MMOGs).

MMOGs nutzt verteilte Architekturen, bei denen viele Server und Knoten zusammenarbeiten, um ein durchgehendes Spieluniversum aufrechtzuerhalten, sodass Tausende von Spielern gleichzeitig fliegen, handeln, kämpfen und erkunden können.

Da die Spielewelt riesig ist und die Spielerzahl sehr hoch, ist das Backend des Spiels auf einen Cluster von Maschinen verteilt, anstatt von einem einzigen System verwaltet zu werden. Eine Reihe von Servern überwacht die Funktionen des Spieluniversums (Spielerpositionen, Schaden, Bestand), während andere Teile der Infrastruktur für die Benutzeranmeldung, Chatfunktionen und die Beständigkeit des Universums zuständig sind. Die Aufteilung trägt dazu bei, dass das Spiel auch dann reaktionsschnell bleibt, wenn viele Spieler gleichzeitig in derselben Region aktiv sind.

Während jeder Spielsession muss das System den Spielstatus aller Spieler synchronisieren. Wenn ein Spieler handelt (zum Beispiel ein Schiff während einer Flottenschlacht bewegt), sendet der Client die Aktion an den entsprechenden Server für diesen Teil der Spielwelt. Der Server aktualisiert dann den gemeinsamen Spielstatus in Echtzeit und teilt das Ergebnis mit den anderen Spielern.

Darüber hinaus verwendet das verteilte Spielsystem spezielle Protokolle, um sicherzustellen, dass jeder Spieler die gleichen Spielereignisse ungefähr zur gleichen Zeit sieht.

Wenn ein Server während des Spiels ausfällt, sind die anderen Server so konzipiert, dass sie den Ausfall auffangen und den Betrieb normal weiter laufen lassen, damit die Spieler keine Unterbrechung mitbekommen.

Verteilte Systeme sind das funktionale Gegenteil von zentralisierten Systemen. Während verteilte Systeme eine Reihe von Geräten zur Steuerung des Ablaufs verwenden, verlassen sich zentralisierte Systeme auf einen einzigen Hauptserver.

In einem zentralisierten System koordiniert ein zentraler Knoten die meisten oder alle Vorgänge. Normalerweise senden Clients Anfragen an diesen Knoten, und der Knoten entscheidet, wie sie verarbeitet werden. Diese Dynamik macht das System verständlicher, weil die Autorität an einem Ort liegt.

Ein einzelner Knoten bedeutet jedoch auch eine einzige Fehlerquelle. In einem zentralisierten System ist das gesamte System nicht mehr verfügbar, wenn der zentrale Server ausfällt. Daher kann die Zentralisierung in Situationen, in denen hohe Verfügbarkeit wichtig ist, erhebliche Probleme verursachen.

Zentralisierte Systeme skalieren oft vertikal. Wenn ein IT-Team den Hauptserver verbessern möchte, geschieht dies, indem ihm mehr Prozessoren, Arbeitsspeicher oder Speicherplatz zugeteilt werden. Leider ist vertikale Skalierung langfristig keine nachhaltige Vorgehensweise. Mit der Zeit wird sie zu ressourcenintensiv und zu teuer.

Zentralisierte Systeme eignen sich daher am besten für Situationen, in denen die Einfachheit der Architektur und die zentrale Überwachung wichtiger sind als eine extrem hohe Ausfallsicherheit. Zentralisierung wird häufig für kleinere Computernetzwerke, interne Geschäftssysteme, Dateiserver und Client-Server-Anwendungen verwendet, bei denen eine zentrale Instanz eine strenge Kontrolle benötigt.

In einem verteilten System hat keine einzelne Maschine die vollständige Kontrolle. Mehrere Knoten arbeiten zusammen, und jeder Knoten kann einen Teil des Workloads bewältigen oder einen Teil der Daten speichern. Die Struktur ist von Natur aus flexibler, erfordert aber Koordination zwischen den Knoten.

Verteilte Systeme sind fehlertoleranter, da andere Knoten weiter arbeiten können, wenn ein Knoten ausfällt. Auch ein verteiltes System kann ausfallen, aber der Leistungsabfall verläuft in der Regel sanfter als bei einem zentralisierten System.

Verteilte Systeme basieren auf horizontaler Skalierung, bei der das System mehr Maschinen hinzufügt, um dem steigenden Ressourcenbedarf gerecht zu werden.

Daher werden verteilte Umgebungen oft bevorzugt, wenn viele Benutzer, große Datensätze oder geografische Verteilung eine zentrale Maschine unpraktisch machen. Verteilte Systeme werden in der Regel für Webdienste, Cloud-Plattformen, Blockchain-Netzwerke und groß angelegte Dienste eingesetzt, die eine hohe Verfügbarkeit und Skalierbarkeit erfordern.

Verteilte Systeme lassen sich in einige allgemeine Kategorien einteilen, je nachdem, wie die Rechner organisiert sind und wie sie kommunizieren.

In einem Client-Server-System stellt ein zentraler Server (oder eine kleine Gruppe von Servern) die Dienste bereit, während andere Rechner – die „Clients“ – von der Arbeit des zentralen Servers abhängig sind.

Der zentrale Server, in der Regel die leistungsstärkere Maschine in Bezug auf die Hardware, ist für die Verwaltung gemeinsam genutzter Ressourcen (Dateien, Datenbanken, Drucker, Benutzerkonten) zuständig. Clients sind in der Regel Endbenutzergeräte (Laptops, Mobiltelefone, Browser), die sich auf die Interaktion mit dem Benutzer und die Bearbeitung von Anfragen und Antworten konzentrieren.

Da Clients und der zentrale Server auf separaten Computern laufen und über ein Netzwerk kommunizieren, werden Client-Server-Systeme als verteilte Systeme betrachtet. Die Kommunikation zwischen Knoten in einer Client-Server-Architektur erfolgt jedoch zentralisiert.

Jeder Client ist auf den zentralen Server angewiesen, um auf gemeinsam genutzte Ressourcen zugreifen zu können, und die Clients kommunizieren nicht direkt miteinander über diese Ressourcen. Stattdessen folgt die Kommunikation zwischen Clients und dem Server meist einem Anfrage-Antwort-Muster.

Wenn der Benutzer eine Aktion ausführt (z. B. auf eine Schaltfläche klickt), wandelt der Client die Aktion in eine Anfragenachricht um und sendet sie über das Netzwerk an den Server. Der Server empfängt die Anfrage, verarbeitet sie und sendet dann eine Antwort zurück. Der Client interpretiert anschließend die Antwort und zeigt dem Benutzer das Ergebnis in einer für Menschen lesbaren Form an.

Nehmen wir zum Beispiel eine Webanwendung, die einen Browser (Client) verwendet, der HTTP-Anfragen an einen Webserver sendet, der wiederum eine Datenbank liest oder schreibt und dann eine HTML- oder JSON-Antwort zurücksendet.

Eine zentralisierte Kommunikation erleichtert die Aktualisierung von Client-Server-Systemen, die Durchsetzung von Sicherheitsrichtlinien und die Datenverwaltung. Der Nachteil ist jedoch, dass die Zentralisierung zu Engpässen und einzelnen Schwachstellen führen kann.

In Peer-to-Peer-Systemen haben alle Knoten – die sogenannten „Peers“ – annähernd gleichberechtigte Rollen. Jeder Peer bringt eigene Ressourcen ein und nutzt die Ressourcen anderer Peers. Jeder Peer kann Ressourcen anfordern und sie anderen Knoten zur Verfügung stellen.

Daher sind „Client“ und „Server“ in einem P2P-System lediglich Rollen, die ein Knoten vorübergehend einnimmt, keine festen Identitäten.

In einem reinen P2P-System entdecken die Peers sich gegenseitig und kommunizieren über ein Overlay-Netzwerk, ein logisches Netzwerk, das auf physischen Internetverbindungen basiert. Das Overlay-Netzwerk entscheidet, wer mit wem spricht und wie Daten zwischen den Peers weitergeleitet werden.

Wenn ein Peer etwas benötigt (zum Beispiel Teile einer Datei), sendet er Anfragen direkt an andere Peers, die darüber möglicherweise verfügen. Erhält ein anderer Peer die Anfrage, kann er antworten und die angeforderten Daten zurücksenden, sodass er in diesem Moment quasi als Server fungiert. Diese Rollen werden später möglicherweise getauscht und es könnte passieren, dass dieselben Knoten andere Funktionen einnehmen: Wer liefert Daten und wer stellt die Anfrage?

Da alle Peers sowohl Daten senden als auch empfangen können, verteilen sich die Datenverarbeitungslasten tendenziell gleichmäßiger über das Netzwerk. Und je mehr Peers beteiligt sind, desto mehr Kapazitäten bringen sie mit, was die Skalierung des Systems erleichtert.

Klassische Filesharing-Netzwerke sind ein gutes Beispiel für P2P-Systeme. Der Computer jedes Benutzers speichert Dateiteile und lädt sie auf andere Knoten hoch, während er gleichzeitig fehlende Teile herunterlädt.

P2P-Systeme sind gegenüber einzelnen Fehlerquellen robuster als Client-Server-Systeme. Wenn ein Peer offline geht, funktioniert das gesamte System in der Regel weiter, da andere Peers Kopien der Daten besitzen oder die Daten um den ausgefallenen Knoten herumleiten können.

Mehrstufige Systeme erweitern das grundlegende Client-Server-Modell und organisieren es in mehrere klar getrennte Ebenen, von denen jede ihre eigene Aufgabe hat. Die gängigsten Formen sind zweistufig, dreistufig und n-stufig.

Ein zweistufiges System ist eine Client-Server-Architektur unter einem anderen Namen. Der Client enthält den Großteil der Anwendungslogik und kommuniziert direkt mit der Serverdatenbank, um Abfragen und Updates durchzuführen. Der Prozess ist einfach, koppelt die Benutzeroberfläche eng an die Daten. Jede Änderung der Datenstruktur kann Änderungen bei vielen anderen Clients erzwingen.

Dreistufige Architekturen verwenden drei Ebenen. Die Präsentationsebene ist für die Benutzeroberfläche zuständig (Webseiten, mobile Benutzeroberflächen, Desktop-Benutzeroberflächen). Die Anwendung- oder „Business Logic“-Ebene implementiert Regeln und Workflows (Validierungen, Berechnungen, Entscheidungen). Die Datenebene speichert und ruft Daten aus verteilten Datenbanken oder anderen Speichersystemen ab.

N-stufige Systeme erweitern das dreistufige Konzept durch das Hinzufügen weiterer spezialisierter Ebenen. Zum Beispiel könnten sich IT-Teams entscheiden, eine separate Programmierschnittstelle (API) oder eine Service-Ebene zu erstellen, die REST oder GraphQL Endgeräte bereitstellt. Oder sie trennen eine Authentifizierungs- und Verschlüsselungsebene, um Benutzeranmeldungen und Token zu verwalten.

Die zusätzlichen Stufen folgen demselben Prinzip wie die ersten drei. Jede Ebene hat eine Hauptverantwortung, und die Ebenen kommunizieren über klar definierte Schnittstellen. Durch diese Modularität können Teams unterschiedliche Ebenen unabhängig voneinander bearbeiten, aktualisieren oder ersetzen und dabei gegebenenfalls sogar unterschiedliche Technologien für jede Ebene verwenden.

Mehrstufige Systeme werden in der Regel für den Betrieb von E-Commerce-Websites und Bankanwendungen verwendet.

Ein Cluster ist eine Gruppe von Computern, die nahe beieinander liegen und so funktionieren, als wären sie eine einzige, leistungsfähigere Maschine. Die Knoten in einem Cluster sind eng gekoppelt, weshalb meistens Folgendes gilt:

• Sie befinden sich physisch am gleichen Ort (im gleichen Raum oder Rechenzentrum).
  
  
• Sie sind per Hochgeschwindigkeitsverbindungen verknüpft, zum Beispiel lokale Netzwerke (LANs) mit hoher Bandbreite oder spezielle Verbindungen.
  
  
• Sie verwenden ähnliche oder identische Hardware und Betriebssysteme.

Da die Knoten ähnlich und effektiv verbunden sind, kann das Cluster eine große Aufgabe in kleinere Teile für die parallele Verarbeitung auf verschiedenen Knoten aufteilen und dann die Ergebnisse kombinieren.

Cluster werden durch spezielle Software wie Cluster-Middleware, einen Scheduler oder einen Resource Manager verwaltet. Die Software entscheidet, welche Knoten welche Jobs ausführen, überwacht den Zustand der Knoten, verwaltet das Datenrouting und verteilt die Workloads auf die Knoten. Diese Managementebene macht aus „einer Reihe von Computern in einem Netzwerk“ ein Cluster. Sie ermöglicht Benutzern, einen Job an das Cluster als Ganzes abzusenden, anstatt sich bei jedem Computer manuell anzumelden.

Clustersysteme sind nützlich für Situationen, die leistungsstarke Berechnungen erfordern, wie Big-Data-Analysen, KI-Modelltraining und wissenschaftliche Simulationen.

Beim Grid-Computing geht es darum, viele unabhängige Computer – oft über verschiedene Städte und Länder verstreut – zusammenzuschließen und sie bei einer einzigen großen Berechnungsaufgabe zusammenarbeiten zu lassen.

Jede teilnehmende Maschine in einem Grid könnte einem anderen Unternehmen oder einer Einzelperson angehören. Es kann sein, dass sie unterschiedliche CPUs, Speichergrößen, Betriebssysteme und lokale Richtlinien haben. Dennoch einigen sie sich darauf, einen Teil ihrer freien Ressourcen für gemeinsame Probleme zu teilen.

Da ein Grid mehrere Verwaltungsbereiche umfasst, befinden sich nicht alle Maschinen im gleichen Besitz oder unter der vollständigen Kontrolle eines Unternehmens. Dies ist ein wesentlicher Unterschied zwischen Grids und Clustern, bei denen eine Institution Server besitzt und verwaltet, die sich in einem Rechenzentrum befinden.

In einem Grid-System bleibt jeder Knoten autonom. Er kann dem Grid beitreten oder es verlassen, hat seinen eigenen lokalen Ressourcenmanager und kann unterschiedliche Sicherheitsregeln oder Prioritäten haben. Grid-Middleware bietet eine gemeinsame Ebene für das Einreichen von Aufträgen, das Ermitteln verfügbarer Ressourcen, das Planen von Aufgaben, das Verschieben von Daten und das Sammeln von Ergebnissen. Diese Middleware ermöglicht es dem gesamten Grid, für die Endbenutzer wie ein virtueller Supercomputer zu funktionieren.

Wenn ein Benutzer einen großen Auftrag absendet (z. B. eine Simulation einer Proteinfaltung oder eine Berechnung des finanziellen Risikos), teilt die Middleware den Auftrag automatisch in viele kleinere Aufgaben auf. Anschließend sucht es im gesamten Netzwerk nach ungenutzten oder nicht ausgelasteten Maschinen, um ihnen Teile der Arbeit zuzuweisen. Jede Maschine arbeitet eigenständig und sendet dann Ergebnisse zurück, die zur endgültigen Antwort zusammengefasst werden.

Wichtig ist, dass Grid-Knoten nicht ausschließlich dem Grid zugewisen sind. Dabei kann es sich um normale Desktops oder Server handeln, die freie CPU-Zyklen zur Verfügung stellen, wenn sie nicht mit ihrer primären lokalen Arbeit beschäftigt sind.

Cloudbasierte verteilte Systeme basieren auf großen, von Cloud-Providern betriebenen Rechenzentren.

Anstatt physische Server zu besitzen, mieten Unternehmen verteilte Rechenressourcen über das Internet. Diese Ressourcen werden als virtuelle Maschinen (VMs), Container, Datenbanken, Warteschlangen und andere verwaltete Dienste bereitgestellt.

Cloud-Systeme sind vor allem elastisch. Unternehmen können mehr Rechen-, Speicher- oder Netzwerkkapazität anfordern, wenn die Workload steigt, und Ressourcen freigeben, wenn die Last abnimmt. Sie ermöglichen es Unternehmen außerdem, nur für die Ressourcen zu zahlen, die sie nutzen, anstatt Hardware im Voraus zu kaufen.

Mit Cloud-Systemen können IT-Teams dynamische horizontale Skalierungsprozesse implementieren. Auto-Scaling-Gruppen – logische Gruppen identischer Serverinstanzen – überwachen die Workload-Metriken in Bezug auf Schwankungen. Wenn eine Last festgelegte Schwellenwerte überschreitet, starten Automatisierungstools weitere Instanzen des Services. Wenn die Auslastung sinkt, werden zusätzliche Instanzen automatisch heruntergefahren, um Geld zu sparen.

Microservices sind anwendungsnahe verteilte Systeme, die mehrere unabhängige Komponenten auf verschiedenen Maschinen verwenden, um Anwendungen zu erstellen.

Im Gegensatz zu monolithischen Anwendungen enthält kein einzelner Microservice in einer Microservices-Architektur die gesamte App. Stattdessen ist jeder Microservice ein eigener kleiner Dienst (mit eigenem Code und in der Regel einem eigenen Datenspeicher), der für eine bestimmte Funktion zuständig ist und unabhängig von anderen Containern läuft.

Da sie unabhängig voneinander sind, können Microservices eigenständig entwickelt, bereitgestellt und skaliert werden, die wahren Vorteile des Systems ergeben sich jedoch aus der Zusammenarbeit der Microservices.

Wenn Benutzer eine Anfrage absenden, erstellt der Client eine Nachricht und sendet sie an ein Edge-Gerät (zum Beispiel einen Load Balancer oder ein API Gateway). Das Edge-Gerät sendet die Anfrage an den entsprechenden Microservice. Der empfangende Microservice liest die Nachricht, führt seine eigene Geschäftslogik aus und sendet dann eine Antwort zurück an das Edge-Gerät, das die Antwort an den Benutzer weiterleitet.

Verteilte Systeme sind in der realen Welt allgegenwärtig. Viele der Tools und Dienste, die Menschen für Unterhaltung, Geschäfts- und Finanzmanagement nutzen, basieren auf verteilten Systemen.

• Skalierbarkeit: Verteilte Computersysteme zeichnen sich durch eine horizontale Skalierung aus, die es Unternehmen ermöglicht, bei wachsenden Workloads einfach weitere Knoten hinzuzufügen, anstatt in teure Upgrades einzelner Server zu investieren.

• Zuverlässigkeit und Fehlertoleranz: Durch die Eliminierung von einzelnen Fehlerquellen bieten verteilte Systeme eine integrierte Redundanz, die dafür sorgt, dass Anwendungen für die Benutzer auch dann weiterlaufen, wenn einzelne Knoten ausfallen.

• Ressourceneffizienz und Kosteneinsparungen: Verteilte Architekturen ermöglichen es Unternehmen, leistungsstarke Rechenumgebungen aufzubauen, indem sie Cluster aus standardisierter, kostengünstiger Hardware anstelle teurer spezialisierter Supercomputer verwenden.

• Globale Verteilung und Zugänglichkeit: Verteilte Systeme können Anwendungen weltweit in der Nähe der Benutzer bereitstellen und so die Latenz verringern, indem Anfragen von geografisch näher gelegenen Knoten bedient werden.