Distributed Systems: So funktionieren verteilte Systeme

Fast alles, was digital ist, läuft heute auf verteilten Systemen. Wie diese Distributed Systems funktionieren, was sie leisten und warum Unternehmen zu Recht auf verteiltes Rechnen (Distributed Computing) setzen, erfahren Sie hier.

Verteilte Systeme können ziemlich kompliziert sein. Zum Glück ist die Idee dahinter leicht zu verstehen! Ein verteiltes System ist einfach eine Umgebung, in der mehrere Rechner oder Geräte, die über ein Netzwerk miteinander verbunden sind, an gemeinsamen Aufgaben arbeiten. Die Komponenten in verteilten Systemen teilen sich die Arbeit auf und gehen dabei koordiniert vor, sodass sie eine konkrete Aufgabe effizienter erledigen, als wenn nur ein einziges Gerät sie erledigt.

Es ist nur logisch, dass es immer mehr verteilte Systeme gibt. Das Internet hat es möglich gemacht, dass wir aus der Ferne arbeiten, und viele Rechenaufgaben sind heute ohnehin zu komplex, als dass ein einzelner Rechner sie allein bewältigen könnte. Das ist der große Vorteil verteilter Systeme: effizientes Arbeiten über Länder- und Teamgrenzen hinweg. Ohne Distributed Computing wäre das meiste davon gar nicht machbar.

In diesem Beitrag befassen wir uns mit der Funktionsweise von verteilten Systemen (Distributed Systems), mit den Herausforderungen und Risiken der entsprechenden Plattformen und mit den unzähligen Vorteilen von verteiltem Rechnen (Distributed Computing).

Distributed Systems: Was sind verteilte Systeme? 

In der Vergangenheit war verteiltes Rechnen relativ teuer, komplex in der Konfiguration und schwierig im Management. Dank SaaS-Lösungen ist verteiltes Rechnen aber für Unternehmen jeder Art und Größe machbar und erschwinglich geworden.

Heutzutage findet bei praktisch allen Arten der Datenverarbeitung verteiltes Rechnen statt, vom Datenbank-Management bis hin zu Videospielen. Tatsächlich wären viele Formen von Software, etwa Kryptowährungen, wissenschaftliche Simulationen, Blockchain-Technologien und KI-Lösungen, ohne entsprechende Plattformen überhaupt nicht möglich.

Distributed Systems kommen dann zum Einsatz, wenn eine Workload zu groß für einen einzelnen Rechner oder ein einziges Gerät wäre. Verteilte Systeme sind ein entscheidender Erfolgsfaktor im Umgang mit veränderlichen Workloads, etwa wenn im E-Commerce der Traffic am Cyber Monday ansteigt oder wenn euer Unternehmen plötzlich mediale Aufmerksamkeit bekommt.

Weil sie auf die Fähigkeiten anderer Rechner und Prozesse zurückgreifen, können verteilte Systeme Funktionen bereitstellen, die für einzelne Systeme nur schwer oder gar nicht zu entwickeln wären.

Hierzu gehören auch Dinge wie externe Off-Site-Backups von Servern und Anwendungen. Wenn der Master-Katalog nicht über die Segmente verfügt, die er für eine Wiederherstellung benötigt, kann er einfach einen anderen Knoten von außerhalb bitten, die Segmente zu senden. Praktisch immer, wenn ihr heute einen Rechner etwas tun lasst, funktioniert das mithilfe verteilter Systeme: wenn ihr eine Mail verschickt, wenn ihr ein Game spielt und wenn ihr diesen Beitrag im Internet vor euch habt.

Hier ein paar ganz alltägliche Beispiele für Distributed Systems:

• Telekommunikationsnetze für Mobilfunk und Internet
• Grafik- und Videobearbeitung
• Wissenschaftliche Modellierung, etwa zur Proteinfaltung oder in der Genforschung
• Flug- und Hotelbuchungen
• Videokonferenzen
• Kryptowährungen (wie Bitcoin)
• Dateiaustausch durch Peer-to-Peer-Filesharing
• Citizen-Science- und Volunteer-Computing-Projekte
• Multiplayer-Computerspiele
• Lieferketten und Filialen im Einzelhandel

Beispiele für verteilte Systeme aus der Praxis

Am Anfang eines verteilten Systems steht eine Aufgabe. Nehmen wir an, ihr müsst ein Video rendern, das ihr für ein bestimmtes Produkt braucht.

Die Anwendung oder die verteilten Anwendungen, die diese Aufgabe managen – in diesem Fall ein Video-Editor auf dem Client-Computer – teilt bzw. teilen die Aufgabe in einzelne Portionen auf. In diesem einfachen Beispiel gibt der Algorithmus einem Verbund von zwölf einzelnen Rechnern oder Knoten (Nodes) jeweils einzelne Frames zur Bearbeitung. Wenn ein Einzelbild bearbeitet und abgeliefert ist, teilt die Management-Anwendung dem Knoten einen neuen Frame zu. Das geht so weiter, bis das gesamte Video fertig ist und alle Teile zusammengefügt sind.

Ein solches System muss sich aber keineswegs auf zwölf Knoten beschränken. Aufgaben lassen sich auf Hunderte und Tausende von Knoten verteilen, sodass eine Arbeit, für die ein einzelner Rechner Tage gebraucht hätte, in wenigen Minuten erledigt ist.

Wer die Herausforderungen einer verteilten Rechenplattform verstehen will, wird feststellen, dass der Trick darin besteht, das Ganze als Abfolge miteinander verbundener Muster zu gestalten. Wenn das System so weit vereinfacht ist, dass es aus kleineren Komponenten besteht, die leichter zu handhaben und zu verstehen sind, dann lässt sich daraus eine komplexe Architektur abstrahieren. Diese Muster dienen oft auch dazu, Distributed Systems zu beschreiben. Bekannte Beispiele:

• Command Query Responsibility Segregation (CQRS)
• Zwei-Phasen-Commit-Protokolle (2PC)

Verteilte Systeme werden mit unterschiedlichen Kombinationen von Mustern ausgestaltet, und jeder Ansatz hat spezifische Vor- und Nachteile.

Typische Formen verteilter Systeme

Es gibt heute eine Vielzahl von Modellen und Architekturen verteilter Systeme.

• Client-Server-Systeme sind die klassische und die einfachste Form verteilter Systeme; sie bestehen aus einer Vielzahl vernetzter Rechner, die mit einem zentralen Server interagieren – zur Datenspeicherung, zur Datenverarbeitung oder für andere gemeinsame Zwecke.
• Peer-to-Peer-Netze verteilen die Workloads auf Hunderte oder Tausende von einzelnen Rechnern, auf denen dieselbe Software läuft.
• Mobilfunknetze sind fortgeschrittene verteilte Systeme, die ihre Workloads auf Mobiltelefone, Vermittlungsstellen und Internet-Geräte verteilen.

An diesem Punkt dürfte euch vermutlich schon klar sein: Die gängigsten Formen verteilter Systeme arbeiten heute über das Internet. Sie geben ihre Workloads an Dutzende von virtuellen Cloud-Servern weiter, und diese Instanzen werden flexibel gestartet und wieder beendet, wenn die Aufgabe erledigt ist.

Distributed Systems: Hauptmerkmale verteilter Systeme

Nachdem wir nun eine Vorstellung davon haben, was verteilte Systeme sind, können wir damit beginnen, ihre Hauptmerkmale zu beschreiben. Gute verteilte Systeme haben folgende Eigenschaften gemeinsam:

• Skalierbarkeit – die Fähigkeit, mit dem Umfang der Workloads zu wachsen, ist ein wesentliches Kennzeichen verteilter Systeme. Dabei wird das Netz nach Bedarf um zusätzliche Recheninstanzen oder Knoten erweitert.
• Nebenläufigkeit (Concurrency) – verteilte Systemkomponenten arbeiten gleichzeitig und parallel zueinander. Hierher gehört auch das Fehlen einer „universellen Uhr“, wenn Teilaufgaben unabhängig von der Reihenfolge oder mit unterschiedlicher Geschwindigkeit abgearbeitet werden.
• Verfügbarkeit und Fehlertoleranz – wenn ein Knoten ausfällt, können die übrigen Knoten weiterarbeiten, sodass die Berechnung insgesamt fortgesetzt wird.
• Heterogenität – in den meisten verteilten Systemen haben die Knoten und Komponenten unterschiedliche Hardware, Middleware, Software und Betriebssysteme. Dadurch können Distributed Systems leicht durch neue Komponenten erweitert werden.
• Replikation – verteilte Systeme ermöglichen die gemeinsame Nutzung von Informationen und Nachrichten und gewährleisten die Konsistenz redundanter Ressourcen, etwa von Software- oder Hardwarekomponenten, wodurch sich Fehlertoleranz, Zuverlässigkeit und Verfügbarkeit verbessern.
• Transparenz – für die End-User erscheint ein verteiltes System als eine einzige Recheneinheit und nicht als die Einzelteile, aus denen es besteht. Die User können also praktisch mit einem einzigen logischen Gerät interagieren und müssen sich keine Gedanken über die Systemarchitektur machen.

Vorteile, Herausforderungen und Risiken verteilter Systeme

Verteilte Systeme bieten eine Reihe von Vorteilen gegenüber monolithischen Einzelsystemen:

• Skalierbarkeit und Flexibilität. Wenn der Bedarf an Services steigt, lässt sich die Rechenleistung leichter hochfahren. In den meisten Fällen könnt ihr heutzutage ein verteiltes System im laufenden Betrieb um zusätzliche Server erweitern, damit die Leistung steigern und die Zeit bis zur Fertigstellung weiter verkürzen.
• Fehlertoleranz. Verteilte Systeme sind zuverlässig, fehlertolerant und reduzieren das Risiko eines Ausfalls, der zum Ausfall des gesamten Systems führt (Single Point of Failure).
• Verlässlichkeit. Ein gut konzipiertes verteiltes System verkraftet Ausfälle von einem oder mehreren Knoten, ohne nennenswerte Leistungseinbußen. Im Gegensatz dazu fällt bei monolithischen Systemen die gesamte Anwendung aus, sobald der Server ausfällt.
• Geschwindigkeit. Starker Datenverkehr kann einen einzelnen Server überlasten und so die Performance für alle beeinträchtigen. Bei verteilten Datenbanken und anderen verteilten Systemen ist es einfacher, eine hohe Leistung aufrechtzuerhalten und zu gewährleisten.
• Regionale Verteilung. Die Bereitstellung von Inhalten nach geografischen Regionen ist für Internetnutzer eine Selbstverständlichkeit und für global agierende Unternehmen von entscheidender Bedeutung. 

(Ein eigener Beitrag erklärt den Unterschied zwischen Content Delivery Networks und Load Balancers.)

Distributed systems are considerably more complex than monolithic computing environments, and raise a number of challenges around design, operations and maintenance. These include:

Verteilte Systeme sind jedoch wesentlich komplexer als monolithische Rechenumgebungen und bringen eine ganze Reihe von Herausforderungen in Bezug auf Design, Betrieb und Wartung mit sich. Dazu gehören vor allem die folgenden:

• Erhöhte Fehlerwahrscheinlichkeit: Je mehr Systeme zu einer Rechenumgebung verbunden sind, desto mehr potenzielle Fehlerquellen gibt es. Falls das System nicht ausreichend durchdacht konzipiert ist und ein einzelner Knoten ausfällt, kann dies zum Zusammenbruch des gesamten Systems führen. Distributed Systems sind zwar fehlertolerant ausgelegt, aber diese Fehlertoleranz ist weder selbstverständlich noch narrensicher.
• Anspruchsvolle Prozess-Synchronisation: Verteilte Systeme arbeiten ohne eine universelle Uhr, daher ist eine sorgfältige Programmierung erforderlich, damit sichergestellt ist, dass die Prozesse korrekt synchronisiert werden, da sonst Übertragungsverzögerungen auftreten, die zu Fehlern und inkorrekten Daten führen. In komplexen Systemen, etwa bei einem Multiplayer-Game, kann die Synchronisation eine kritische Herausforderung darstellen, insbesondere in öffentlichen Netzwerken mit hohem Datenverkehr.
• Begrenzte Skalierbarkeit: Eine Verdoppelung der Anzahl der Knoten in einem verteilten System bedeutet nicht unbedingt eine Verdoppelung der Leistung. Die Architektur eines effizienten verteilten Systems mit maximaler Skalierbarkeit ist ein komplexes Unterfangen, bei dem Lastverteilung (Load Balancing), Bandbreitenmanagement und noch weitere Punkte berücksichtigt werden müssen.
• Komplexe Sicherheit: Das Management einer großen Anzahl von Knoten in einer heterogenen oder weltweit verteilten Umgebung bringt zahlreiche Sicherheitsherausforderungen mit sich. Eine einzige Schwachstelle in einem Dateisystem kann das gesamte System angreifbar machen.
• Erhöhte Komplexität: Verteilte Systeme sind generell komplexer als herkömmliche Rechenumgebungen. Entsprechend anspruchsvoll sind Design, Management und Monitoring.

Die Herausforderungen, die verteilte Systeme mit sich bringen, führen zu einer Reihe spezifischer Risiken:

• Sicherheit: Verteilte Systeme sind genauso anfällig für Angriffe wie jedes andere System, aber aus ihrer verteilten Natur ergibt sich eine viel größere Angriffsfläche.
• Netzausfälle: Distributed Systems sind zum Senden und Empfangen von Daten auf öffentliche Netze angewiesen. Falls ein Internet-Netzsegment nicht mehr verfügbar oder überlastet ist, sinkt unter Umständen auch die Performance des verteilten Systems.
• Governance und Kontrolle: Verteilte Systeme sind nicht so leicht steuerbar wie monolithische Systeme, die auf einem zentralen Server laufen. Das führt unter anderem zu Schwierigkeiten bei der Einhaltung von Datenschutzbestimmungen und entsprechenden Audits. Global verteilte Umgebungen stellen eine Herausforderung dar, wenn es darum geht, ein definiertes Maß an Sicherheit zu garantieren und zu überschauen, wo genau die Daten liegen.
• Kosten: Im Gegensatz zu zentralisierten Systemen können Administratoren skalierbare verteilte Systeme bei Bedarf problemlos um zusätzliche Kapazitäten erweitern – was allerdings auch zu kaum kontrollierbaren Mehrkosten führen kann. Die Preise für verteilte Cloud Computing-Systeme richten sich nach der Nutzung, zum Beispiel nach der Anzahl der Speicherressourcen und der CPU-Leistung, die in einem bestimmten Zeitraum in Anspruch genommen werden. Wenn die Nachfrage plötzlich in die Höhe schnellt, kann das eine saftige Rechnung ergeben. (Es gibt hierzu einen eigenen Beitrag über die aktuellen Trends bei den Cloud-Kosten.)

Einrichten eines verteilten Systems – praktische Tipps

Distributed Systems können ganz bescheidene Bereitstellungen einzelner Abteilungen im LAN sein ­– oder groß angelegte Implementierungen mit globaler Reichweite. Neben der Größe und der Gesamtkomplexität sind folgende Kriterien zu berücksichtigen:

• die Größe und Kapazität des Computernetzwerks
• die Menge der zu verarbeitenden Daten
• die Häufigkeit der Prozesse und ob diese geplant oder ad hoc ablaufen
• die Anzahl der Benutzer, die Zugriff auf das System haben
• die Kapazität des Rechenzentrums
• die Anforderungen an die Datenqualität und Verfügbarkeit

Verteilte Bereitstellungen lassen sich in die Kategorien „Abteilung“, „kleines Unternehmen“, „mittleres Unternehmen“ und „Großunternehmen“ einteilen. Diese Sortierung ist keineswegs verbindlich, aber ein guter Ausgangspunkt für die Planung der erforderlichen Ressourcen bei der Implementierung eines verteilten Rechensystems.

Verteilte Systeme können sich außerdem im Laufe der Zeit weiterentwickeln, wenn das Unternehmen wächst und expandiert, sodass etwa aus einer Bereitstellung für die Abteilung eine Bereitstellung der Kategorie „kleines Unternehmen“ wird.

Spuren in verteilten Systemen suchen

Nun ist klar, dass verteilte Systeme trotz all ihrer Vorteile eine komplizierte Angelegenheit sind. Es ist definitiv von Vorteil, wenn ihr wisst, was im System vorgeht – wir sprechen hier von der Beobachtbarkeit oder Observability des Systems. Glücklicherweise ist dies mit dezentralem Tracing (Distributed Tracing) zu schaffen.

Distributed Tracing ermöglicht es, den Weg einer Anfrage oder Transaktion durch die Anwendung zu verfolgen. Dadurch lassen sich Engpässe, Fehler und andere Probleme identifizieren, die sich auf die Anwendungsleistung auswirken können.

Ohne Distributed Tracing wäre ein effektives Monitoring einer global verteilten Systemlandschaft kaum möglich.

Distributed Tracing, auch Distributed Request Tracing genannt, ist eine Methode zum Monitoring von Anwendungen. Meist handelt es sich dabei um Anwendungen in Microservice-Architekturen, die typischerweise in verteilten Systemen bereitgestellt werden. Distributed Tracing ist insofern eine Form von verteiltem Rechnen, als es normalerweise zum Monitoring von Anwendungen auf verteilten Systemen eingesetzt wird.

Tracing ermöglicht es in der Softwareentwicklung und den IT Operations, den Weg einer Transaktion durch eine Anwendung zu verfolgen. So hangelt sich zum Beispiel eine Online-Kreditkartentransaktion vom Kauf durch den Verifizierungs- und Bestätigungsprozess bis zum Transaktionsabschluss. Das Tracing-System überwacht diesen Prozess Schritt für Schritt und ermöglicht es den Entwicklungsteams, Fehler, Engpässe, Latenzen und andere Anwendungsprobleme zu erkennen.

Distributed Tracing ist aufgrund der enormen Komplexität moderner Software-Architekturen notwendig. Distributed-Tracing-Systeme sind darauf ausgelegt, in Infrastrukturen mit verteilten Diensten zu arbeiten und eine Vielzahl von Anwendungen und Prozessen gleichzeitig über zahlreiche Knoten und Rechenumgebungen hinweg zu verfolgen. (Als separaten Beitrag haben wir dazu einen Praxisleitfaden Distributed Tracing.)

Zugangskontrolle in verteilten Systemen einrichten

In der Praxis nutzen Administratoren in verteilten Rechenumgebungen eine Vielzahl von Ansätzen der Zugangskontrolle, die von klassischen Zugriffssteuerungslisten (Access Control List, ACL) bis hin zu rollenbasierten Zugangskontrollen (Role-based Access Control, RBAC) reichen.

Einer der vielversprechendsten Zugangskontrollmechanismen für verteilte Systeme ist die attributbasierte Zugangskontrolle (Attribute-based Access Control, ABAC). Sie kontrolliert den Zugriff auf Objekte und Prozesse mit Hilfe von Regeln, die User-Informationen ebenso enthalten wie Informationen zur angeforderten Aktion und zur Umgebung, aus der die Anfrage kommt. Administratoren können diese Rollen noch weiter verfeinern und beispielsweise den Zugang auf bestimmte Tageszeiten oder bestimmte Standorte beschränken.

Die Welt braucht verteilte Systeme – heute und morgen

Verteilte Systeme haben das Potential, die Datenverarbeitung in absehbarer Zukunft entscheidend zu prägen. Praktisch jede Art von Anwendung oder Dienstleistung wird in irgendeiner Form von verteiltem Rechnen zu tun haben. Und der Bedarf an Datenverarbeitung, die always on und überall verfügbar ist, dürfte noch kräftig steigen.

Dieser Beitrag stellt nicht unbedingt den Standpunkt, die Strategie oder die Meinung von Splunk dar.