Commit 7dced376 authored by Blanke, Daniela's avatar Blanke, Daniela
Browse files

Update distributed-communication.html

parent 21e2a847
Pipeline #8040 passed with stage
in 1 minute and 10 seconds
......@@ -17,7 +17,7 @@ appears to its users as a single coherent system." (Andrew Tanenbaum)</div>
<p>Es existiert eine Vielzahl von Protokollen zur Kommunikation in einem verteilten System, d.h. zum Austausch von Nachrichten/Daten zwischen Software-Komponenten, die in Prozessen auf verschiedenen Computern ausgeführt werden und über ein Netzwerk miteinander verbunden sind. Entsprechend den Anforderungen eines konkreten Anwendungsfalls ist ein geeignetes Protokoll als Grundlage für diese Interprozesskommunikation auszuwählen. Eine erste Orientierung bietet das <a href="https://de.wikipedia.org/wiki/Internetprotokollfamilie">TCP/IP-Modell</a>, das die Kommunikationsprotokolle gemäß der folgenden Abbildung in 4 Schichten untergliedert.</p>
<img src="media/distributed_tcp_ip_model.png" style="width:900px">
<label>Protokolle zur Remote-Kommunikation und das TCP/IP-Schichtenmodell</a></label>
<label>Protokolle zur Remote-Kommunikation und das TCP/IP-Schichtenmodell</label>
<p>Aus der Perspektive eines Anwendungsentwicklers möchten wir uns auf die Protokolle der unteren Schichten (Transport-, Internet-, Netzzugangsschicht im TCP/IP-Modell) verlassen und ein adäquates Protokoll auf Ebene der Anwendungsschicht nutzen. Wir verfolgen grundsätzlich das Ziel, dass eine lokale Client-Komponente eine Kommunikationsverbindung zu einer entfernten (engl. <i>remote</i>) Server-Komponente aufbaut und anschließend anwendungsspezifische Daten austauschen kann. In den nächsten Kapiteln werden dazu folgende alternative Ansätze zur sogenannten Remote-Kommunikation am Beispiel von Java-Anwendungen vorgestellt:</p>
<ul>
......@@ -53,7 +53,7 @@ appears to its users as a single coherent system." (Andrew Tanenbaum)</div>
<p>Es ergeben sich folgende Einflussfaktoren auf die Performance einer Komponente zur Laufzeit:</p>
<img src="media/distributed_performance_drivers.png" style="width:600px">
<label>Einflussfaktoren auf die Antwortzeit einer Komponente</a></label>
<label>Einflussfaktoren auf die Antwortzeit einer Komponente</label>
<ul>
<li><b>Implementierung</b>: In Abhängigkeit der verwendeten Datenstrukturen und Algorithmen kann eine Komponente unterschiedlich effizient implementiert werden.</li>
......@@ -66,18 +66,18 @@ appears to its users as a single coherent system." (Andrew Tanenbaum)</div>
<p>Skalierbarkeit drückt das Verhältnis zwischen der Steigerung der Problemgröße (z.B. mehr Workload) und den zur Lösung zusätzlich benötigten Ressourcen aus. Antwortzeiten und Durchsatz skalieren bei steigendem Workload und beschränkter Ressourcen-Kapazität bis zum Erreichen der Kapazitätsgrenze etwa linear. Anschließend steigen die Antwortzeiten exponentiell, da eine bestimmte Ressource (z.B. CPU, RAM, I/O) aufgrund von Überlastung zum Engpass wird. Dieser typische Effekt ist in der folgenden Abbildung dargestellt. Gleichermaßen erreicht auch der Durchsatz einen Sättigungspunkt, an dem die Komponente oder das System einfach nicht mehr Anfragen pro Zeitintervall verarbeiten kann. In automatisch skalierenden Cloud-Plattformen kann dieser Sättigungspunkt soweit hinausgezögert werden, das er praktisch nicht erreicht wird. Allgemein ist es aus Gründen der Wirtschaftlichkeit zu empfehlen, die bereitgestellten Hardware-Ressourcen nicht zu stark überzudimensionieren.</p>
<img src="media/distributed_scalability.png" style="width:600px">
<label>Skalierbarkeit von Antwortzeit und Durchsatz bei beschränkter Ressourcen-Kapazität</a></label>
<label>Skalierbarkeit von Antwortzeit und Durchsatz bei beschränkter Ressourcen-Kapazität</label>
<p>Um die Ressourcen-Kapazität eines Systems auszubauen, gibt es zwei grundlegende Ansätze: die vertikale Skalierung (<i>Scale Up</i>) und die horizontale Skalierung (<i>Scale Out</i>). Bei der vertikalen Skalierung wird ein leistungsstarker Großrechner angestrebt, der sukzessiv ausgebaut wird. Dieser Ansatz gilt als vergleichsweise teuer. Außerdem stellt der Großrechner einen möglichen <i>Single Point of Failure</i> dar. Daher wird heute horizontale Skalierung durch ein verteiltes System von vielen gleichartigen Knoten favorisiert. In einem derartigen <i>Cluster</i> wird der Ausfall von wenigen Knoten als Normalzustand angenommen, der die Verfügbarkeit und die Konsistenz der Daten nicht gefährden darf. Zwar ist ein Cluster komplexer zu beherrschen als ein einzelner Großrechner, kann dafür aber skalierbare Performance und Datensicherheit gleichermaßen gewährleisten.</p>
<img src="media/distributed_scale_out.png" style="width:700px">
<label>Vertikale und horizontale Skalierung</a></label>
<label>Vertikale und horizontale Skalierung</label>
<h4>Datensicherheit durch Replikation</h4>
<p>Nehmen wir an, dass wie oben dargestellt ein Cluster von gleichartigen Knoten aufgebaut worden ist, um auch bei hohem Workload die geforderte Performance des Systems zu gewährleisten. Eine Komponente wird innerhalb des Clusters nun mehrfach instantiiert, damit der Dienst, den sie anbietet, ebenso skaliert. Jede Instanz dieser Komponente wird nur einen Ausschnitt der gesamten Datenbasis verarbeiten und auf dem Knoten, auf dem sie ausgeführt wird, speichern. Die Daten werden in einem verteilten Datei- oder Datenbanksystem in sogenannte Partitionen (oder auch <i>Shards</i>) zerlegt. Einzelne Datenobjekte/Datensätze werden i.d.R. über eine Hashfunktion einer Partition zugeordnet. Die folgende Abbildung zeigt ein Cluster mit 4 Knoten, auf denen jeweils eine Instanz der gleichen Komponente ausgeführt wird. Die Datenbasis wurde in 6 Partitionen (A-F) unterteilt. Da das System keine Daten verlieren darf, wenn ein Knoten ausfällt, werden die Partitionen repliziert. Im dargestellten Beispiel ist der Replikationsfaktor 3, d.h. von jeder Partition gibt 3 identische Replikate, so dass das abgebildete System den Ausfall beliebiger 2 Knoten tolerieren kann. Die Anzahl der Knoten und insbesondere der Partitionen ist in der Praxis häufig deutlich größer. Eine größere Anzahl an Partitionen als Knoten vereinfacht die Umverteilung der Partitionen, wenn ein neuer Knoten in den Cluster aufgenommen wird oder ein Knoten ausscheidet.</p>
<img src="media/distributed_replication.png" style="width:700px">
<label>Partitionierung und Replikation von Daten im verteilten System</a></label>
<label>Partitionierung und Replikation von Daten im verteilten System</label>
<p>Ein Kompromiss zwischen Verfügbarkeit und Konsistenz der Daten ergibt sich dadurch, dass die Replikate nach einem Schreibzugriff synchronisiert werden müssen. Es stellt sich in einem verteilten System die Frage, ob während der Synchronisation bedingt durch einen Schreibzugriff entweder ein veralteter Zustand gelesen werden darf (d.h. Verfügbarkeit nicht eingeschränkt, aber Konsistenz eingeschränkt) oder das Lesen bis zum Ende der Synchronisation verzögert wird (d.h. Konsistenz nicht eingeschränkt, aber Verfügbarkeit eingeschränkt). In einem verteilten System ist grundsätzlich mit dem Ausfall einzelner Knoten oder der vorübergehenden Unterbrechung der Netzwerkverbindungen zu rechnen, was zu Verzögerungen in der Synchronisation führt. Der Begriff Partitionstoleranz beschreibt, dass das System bis zu einem gewissen Grad tolerant gegenüber einem kurzzeitigen Verfall des Systems in unverbundene Teile sein muss. Der Kompromiss zwischen der Konsistenz (engl. <i><u>C</u>onsistency</i>), der Verfügbarkeit (engl. <i><u>A</u>vailability</i>) und der Partitionstoleranz (engl. <i><u>P</u>artition Tolerance</i>) in einem verteilten System ist als <a href="https://en.wikipedia.org/wiki/CAP_theorem">CAP-Theorem</a> bekannt. Verteilte Datenbanken werden in diesem Model nicht weiter behandelt. Einen fundierten Überblick liefert das populäre Buch "Designing Data-Intensive Applications" von Martin Kleppmann <a href="#cite-Kle17">[Kle17]</a>.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment