Raft Konsens Algorithmus

Raft-Konsensalgorithmus: Konsens in verteilten Systemen einfach erklärt

Der Raft-Konsensalgorithmus ist eine clevere Methode mit einem leaderbasierten Mechanismus für verteilte Systeme wie Cluster in einem Service-Mesh. Der Algorithmus sorgt dafür, dass mehrere Nodes in einem Kubernetes Cluster dieselben Zustandsänderungen in derselben Reihenfolge übernehmen. Dazu schlägt ein Node sich als Candidate für die Rolle des Leaders vor und alle Nodes wählen nach einem algorithmisch definierten einen Leader, replizieren Logeinträge und bestätigen neue Einträge über eine Mehrheit des Clusters.

In fünf Minuten verstehst du:

Raft wurde bewusst in die weitgehend getrennten Bereiche Leader Election, Log Replication und Safety zerlegt, um das Konsensproblem verständlicher und praktisch beherrschbar zu machen.

Wer verteilte Systeme baut oder betreibt, sollte den Raft Konsens-Algorithmus verstanden haben. Für Entwickler*innen veranschaulicht Raft, wie mehrere Nodes zuverlässig einen gemeinsamen Zustand halten. IT-Architekten hilft es, Quorum, Konsistenz und Hochverfügbarkeit in Kubernetes Clustern zu optimieren und in einer Systemarchitektur von Anbeginn zu berücksichtigen. DevOps- und Platform-Teams begegnen Raft direkt in etcd, Kubernetes und Consul.

Kurz gesagt: Wer Kubernetes Cluster verantwortet, sollte unbedingt wissen, was bei Leader-Ausfall und verlorener Mehrheit passiert und warum.

1. Welches Problem löst der Raft-Konsensalgorithmus?

Verteilte Systeme sind einfach – solange nichts ausfällt, das Netzwerk immer zuverlässig ist und alle Server jederzeit exakt denselben Wissensstand besitzen.

Also praktisch nie.

Sobald mehrere Server gemeinsam einen Zustand verwalten, entsteht ein grundlegendes Architekturproblem:

Welcher Zustand ist der gültige?

Nehmen wir einen Cluster aus drei Servern. Alle drei speichern dieselben Konfigurationsdaten.

Nun kommt eine Änderung herein:

feature.payment.enabled = true

Server A verarbeitet die Änderung sofort. Server B erhält sie einige Millisekunden später. Server C ist gerade nicht erreichbar.

Jetzt stellen sich mehrere Fragen:

• Darf die Änderung bereits als erfolgreich gelten?
• Was passiert, wenn Server A direkt danach ausfällt?
• Welcher Server übernimmt?
• Woher weiß der neue Leader, ob die Änderung verbindlich war?
• Was passiert, wenn Server C mit einem älteren Zustand zurückkehrt?

Eine Datenkopie allein beantwortet keine dieser Fragen.

Raft repliziert nicht einfach Daten. Raft legt verbindlich fest, welche Zustandsänderungen in welcher Reihenfolge gelten.

Das eigentliche Problem: mehrere Knoten, eine Wahrheit

In einem verteilten System besitzt jeder Knoten zunächst nur seine eigene lokale Sicht auf die Welt.

Mehrere Server können Kopien desselben Zustands speichern. Diese Kopien müssen aber nicht zu jedem Zeitpunkt identisch sein:

• Nachrichten können verspätet eintreffen.
• Nachrichten können mehrfach übertragen werden.
• Verbindungen können abbrechen.
• Knoten können ausfallen.
• Knoten können später mit einem veralteten Zustand zurückkehren.
• Zwei Teile eines Clusters können zeitweise nicht miteinander kommunizieren.

Das Netzwerk ist damit kein perfekter Datenbus, sondern eine potenzielle Fehlerquelle.

Trotzdem muss das System entscheiden können:

• Welche Änderung wird akzeptiert?
• In welcher Reihenfolge werden Änderungen ausgeführt?
• Ab welchem Zeitpunkt gilt eine Änderung als verbindlich?
• Welcher Knoten darf diese Entscheidung koordinieren?

Genau dafür wird ein Konsensalgorithmus benötigt.

Raft Konsens Algorithmus – Konsens für verteilte Systeme und Kubernetes Cluster

Eine Kopie ist noch kein Konsens

Angenommen, der Leader hat einen neuen Wert lokal gespeichert:

activeRelease = "2026.07"

Das bedeutet zunächst nur:

Ein Knoten kennt diesen Wert.

Es bedeutet jedoch nicht:

Der Cluster hat diesen Wert verbindlich akzeptiert.

Das ist ein wichtiger Unterschied.

Ein Logeintrag kann auf einem einzelnen Knoten bereits vorhanden sein, ohne dass er als committed gilt. Fällt dieser Knoten aus, bevor ausreichend weitere Cluster-Mitglieder den Eintrag bestätigt haben, darf das System nicht einfach so tun, als sei die Änderung erfolgreich abgeschlossen worden.

Raft trennt deshalb zwischen verschiedenen Zuständen eines Eintrags:

empfangen → lokal gespeichert → repliziert → committed → angewendet

Erst ein committed Eintrag gehört zum verbindlichen Zustand des verteilten Systems.

Kopiert bedeutet vorhanden.

Committed bedeutet entschieden.

Replizierte State Machine

Das Architekturmodell hinter Raft ist die replizierte State Machine.

Eine State Machine verarbeitet Eingaben und erzeugt daraus einen neuen Zustand.

Vereinfacht:

alter Zustand + Befehl = neuer Zustand

Beispiel:

Kontostand: 100 EUR
Befehl:     +25 EUR
Ergebnis:   125 EUR

In einem verteilten System läuft dieselbe State Machine auf mehreren Knoten. Damit alle Knoten zum gleichen Ergebnis gelangen, müssen sie dieselben Befehle in derselben Reihenfolge verarbeiten.

Knoten A: Befehl 1 → Befehl 2 → Befehl 3
Knoten B: Befehl 1 → Befehl 2 → Befehl 3
Knoten C: Befehl 1 → Befehl 2 → Befehl 3

Die Reihenfolge ist entscheidend. Folgende Befehle liefern nicht zwingend dasselbe Ergebnis, wenn ihre Reihenfolge vertauscht wird:

1. Setze Wert auf 10
2. Erhöhe Wert um 5

Ergebnis:

15

Vertauschen wir die Reihenfolge:

1. Erhöhe Wert um 5
2. Setze Wert auf 10

Ergebnis:

10

Raft sorgt dafür, dass die Knoten eine gemeinsame, verbindliche Reihenfolge dieser Befehle erhalten.

Diese Reihenfolge wird im replizierten Log festgehalten.

Index 1: Benutzer anlegen
Index 2: Rolle zuweisen
Index 3: Benutzer aktivieren

Verarbeiten alle Knoten dieselben committed Logeinträge in derselben Reihenfolge, erreichen ihre State Machines denselben Zustand.

Konsens

Konsens bedeutet in diesem Zusammenhang, dass alle Knoten voten wer Leader eines Clusters wird.

Raft arbeitet also mit einer Mehrheit der stimmberechtigten Knoten, einem sogenannten Quorum.

In einem Cluster mit drei Knoten besteht die Mehrheit aus zwei Knoten:

3 Knoten → Mehrheit 2

In einem Cluster mit fünf Knoten:

5 Knoten → Mehrheit 3

Deshalb ist die Anzahl von Nodes in einem Kubernetes Cluster immer ungerade, damit immer eine Mehrheit zustande kommt.

Der Leader koordiniert die Verarbeitung neuer Logeinträge. Er verteilt einen Eintrag an die Follower und wartet auf ausreichend Bestätigungen.

Vereinfacht:

Client
│
▼
Leader
├──▶ Follower A
└──▶ Follower B

Bestätigt eine ausreichende Mehrheit der Nodes den Eintrag, kann er committed werden.

Konsens bedeutet im Raft Konsens Algorithmus also:

Eine definierte Mehrheit der Nodes in einem Cluster hat eine gemeinsame Entscheidung über die verbindliche Reihenfolge der Zustandsänderungen getroffen. Damit ist ein vertrauensvolles Verfahren etabliert, wie Daten in einem Service Mesh sicher repliziert werden um im Cluster unverzichtbare Eigenschaften wie Integrität und Robustheit zu gewährleisten.

Fehler in einem Netzwerk, Paketverluste beim Transport von Daten oder vertauschte Netzpakete sind Fehlerkonstellationen, die der Raft Konsens Algorithmus innerhalb eines Netzwerks sicher handeln kann. Der Algorithmus ist also darauf optimiert, dass jeder Knoten in einem Netzwerkverbund jederzeit ausfallen darf und trotzdem keine Daten verloren gehen oder asynchron sind. Der Ralf Konsens Algorithmus stellt also sicher, dass das System jederzeit weiterarbeiten, solange ein Quorum im Cluster verfügbar bleibt.

Wir erwarten heute zu Recht von Cloud-Services dass Neustarts, Updates und sogar Stromausfälle folgenlos für unsere Daten bleiben.  Eine verteilte Datenbank wie etcd in einem Kubernetes Cluster muss ihre Daten jederzeit zuverlässig in einem definierten Service Mesh verteilen können. Genau diese Single Source of Truth ist die Super-Power des Raft Konsens Algorithmus.