Ein weit verbreiteter Algorithmus für die Implementierung verteilter zustandsvoller Systeme ist RAFT. Dieser sieht Lösungen vor, um Probleme des verteilten Rechnens unter einen Hut zu bringen. Doch wie sehen die Probleme der verteilten Systeme in der Praxis aus – und wie werden sie von RAFT gelöst?

Aufgrund von Fehlertoleranz und Datensicherheit wird Software für den Betrieb im Cluster – häufig in der Cloud – entwickelt. Die Software ist damit inhärent verteilt. Während sich Sanierungsaufgaben bei verteilten, zustandslosen Systemen aus Sicht des Entwicklers weitestgehend trivial gestalten, hat eine horizontale Skalierbarkeit zustandsvoller Systeme immer eine Implikation: Die Software muss bestimmte Eigenschaften aufgeben oder Versprechen auflockern.

Viele bekannte zustandsvolle Systeme wie Kubernetes, MongoDB und auch CockroachDB tun es – Software als hochverfügbares verteiltes System betreiben.

Damit diese Systeme eine Hochverfügbarkeit – CockroachDB ist sogar bekannt als „almost impossible to get down“ [1] – sind, ist ein stetiges Replizieren der Daten auf verschiedenen Computern im Verbund Pflicht. Der Zustand wird also auf viele Systeme skaliert.

Was einfach klingt, birgt Schwierigkeiten. Replizieren von Daten in verteilten zustandsvollen Systemen ist dann keine triviale Aufgabe mehr, wenn die Konsistenz der Daten jederzeit gewährleistet werden soll. Und zwar auch dann, wenn sich Rechner des Verbunds z. B. durch Netzwerkstörungen fehlerhaft verhalten.

Die wohl wichtigste Eigenschaft von Datenbanken ist es, Daten eines Endnutzers, menschliche oder maschinelle Programme, nicht zu verlieren. Für verteilte, skalierbare Datenbanken muss deshalb eine Lösung her, um den dynamischen Aspekten in der IT Herr zu werden – RAFT. Das Ziel von RAFT ist es, eine konsistente verteilte Datenhaltung replizierter Daten zu ermöglichen und trotzdem eine hohe Erreichbarkeit und Partitionstoleranz aufrechtzuerhalten. RAFT selbst ist dabei weniger eine konkrete Implementierung als vielmehr ein Algorithmus, um Lösungen für verteilte Datenhaltung zu ermöglichen.

Eine Architektur für replizierte Datenhaltung

Damit ein RAFT-System funktioniert, müssen viele Instanzen, genannt Knoten, in einem Cluster, in den meisten Fällen physisch getrennt, betrieben werden – alles andere ist in den meisten Fällen sinnfrei. Ein RAFT-Cluster besteht immer aus mindestens drei unabhängigen Teilnehmern. Ein Teilnehmer ist dabei eine getrennte Instanz der Datenbank oder Software. Im System übernimmt jeder Knoten eine eigene Rolle. RAFT sieht im System zunächst zwei Rollen vor (wobei im Fehlerfall eine dritte Rolle dazu kommt – doch dazu später mehr):

• Leader

• Follower

Ein Ziel von RAFT ist es, die Erreichbarkeit durch ein Skalieren von Knoten zu erhöhen und die Konsistenz über zu verwaltende Daten zu wahren. Damit die gelesenen Daten jederzeit konsistent bleiben, darf es inhärent nur einen einzigen Punkt geben, der die Daten verwaltet und den wahren Zustand kennt – alles andere ist rein logisch unmöglich. Wie die Daten weiter aufgeteilt werden, z. B. durch Sharding, ist ein anderes Thema. Genau dieser Aspekt der Single Source of Truth wird in RAFT durch die Rolle eines Leaders abgebildet. 

Ein Knoten mit der Rolle eines Leaders verwaltet die Daten. Das bedeutet, dass nur dieser die Daten verändern und den aktuellen Stand der Daten lesen kann. Die Daten werden dabei als ein unendlicher Strom von Logdaten abgebildet. Dieser Strom enthält alle Änderungen am Zustand und wird an die...