Wie verteilte Systeme dank Raft-Algorithmus zusammenarbeiten
Computer in einem Cluster brauchen stets eine gemeinsame Wahrheit. Der Raft-Consensus-Algorithmus funktioniert mit Mehrheitswahlen und vermeidet so Konflikte.
- Verteilte Systeme können ihre Arbeit nur dann zuverlässig erledigen, wenn sich alle Server jederzeit auf eine gemeinsame Wahrheit einigen können.
- Der Raft-Consensus-Algorithmus stellt Konsens unter Maschinen her, die ihren Anführer demokratisch selbst wählen.
- Server im Cluster können ausfallen, im Netzwerk können Pakete verloren gehen – Raft ist auf solche Probleme vorbereitet.
Wenn Menschen in einer Gruppe zusammenarbeiten sollen, wird es gern mal anstrengend – und es fallen die typischen Sätze, die in jedem Büro zum Alltag gehören: "Das hatte ich doch rumgeschickt!", "Du hast noch die alte Version, die neue liegt doch im Ordner!" und "Ach, da warst du im Urlaub, als wir das geändert haben." All diese Symptome gehören zu einem großen Problem: Wie stellt man sicher, dass sich alle Mitglieder eines Teams eine gemeinsame Wahrheit, also einen Datenstand als Arbeitsgrundlage teilen?
Säule des Internets
Dieses Problem ist nicht uns Menschen vorbehalten; auch für Computer ist es keine triviale Aufgabe, reibungslos im Team zu arbeiten und sich auf eine gemeinsame Wahrheit zu einigen. Dabei haben es Computer untereinander doch vergleichsweise leicht: Sie funktionieren deterministisch, bringen unter identischen Bedingungen also identische Ergebnisse hervor. Auch kennen sie keine Emotionen und menschliche Schwächen wie Neid, Missgunst und krankhaften Ehrgeiz. Einer emotionsfreien Maschine fiele es nicht ein, sich vorzudrängeln oder in fremde Arbeitsbereiche einzumischen.
[1]Es könnte daher so einfach sein, einen Algorithmus zu entwickeln, der eine gemeinsame Wahrheit unter Computern herstellt – und doch hat es Jahrzehnte gedauert, bis sich ein Verfahren durchsetzte, das funktional, robust und leicht zu implementieren ist: der Raft-Konsens-Algorithmus [2], der heute in vielen verteilten Systemen steckt. Dieser unscheinbare Algorithmus ist zu einer wichtigen Säule des Internets geworden: Die Schlüssel-Werte-Datenbank etcd zum Beispiel arbeitet mit Raft und ist selbst das Fundament für den Container-Orchestrator Kubernetes – und auf dieser Säule wiederum stehen viele große und sehr große Anwendungen. Ohne Raft gäbe es Spotify, Netflix oder Zalando nicht in dieser Form.
Warum ein Konsens-Algorithmus?
Solange ein Computer allein arbeitet, ist alles einfach: Er nimmt Anfragen oder Aufgaben entgegen, beschafft sich die nötigen Daten aus seinem Datenspeicher, nutzt sie für die Bearbeitung und gibt ein Ergebnis zurück. Ein alleinstehender SQL-Datenbankserver zum Beispiel kann lesende und schreibende Anfragen gleichermaßen schnell beantworten und muss sich mit niemandem absprechen. Was er wissen muss, liegt auf seiner Festplatte oder für häufige Fragen im Arbeitsspeicher. Doch ein einzelner Datenbankserver als Rückgrat einer Anwendung hat auch seine Schwächen. Fällt er aus, geht nichts mehr. Und bei höheren Lese- und Schreiblasten bleibt dem Admin nur, immer mehr Hardware in den Einzelgänger zu stecken.
Da wäre es doch schön, wenn man die Daten einem Verbund aus Datenbankservern anvertrauen könnte. Dafür gibt es zwei unterschiedlich komplexe Vorgehensweisen: Im einfachsten Fall ernennt ein Mensch einen Server zum Verantwortlichen (in vielen Anwendungen Master genannt) für alle schreibenden Zugriffe, nur dieser nimmt Schreibaufträge an. Jede Änderung schickt der Master anschließend an weitere replizierende Server, die eine Kopie der Daten pflegen und ausschließlich lesende Zugriffe beantworten oder sogar nur als Reserve für Notfälle bereitstehen. Verteilt man die Lesezugriffe, entlastet das den Master und auch die Stabilität nimmt zu, unter unglücklichen Umständen kann ein Server aber mal veraltete Daten zurückgeben. Außerdem gibt es in einem solchen System eine klare Hierarchie, die ein Mensch erschaffen hat, indem er einen Server zum Anführer und die anderen zu Kopienverwaltern ernannt hat. Hat der Anführer schwerwiegende Probleme, könnte und müsste ein Mensch eingreifen und die Rolle auf einen anderen Server übertragen.
Geteilte gemeinsame Wahrheit
Die Königsdisziplin ist ein Cluster, in dem kein Mensch mehr nötig ist, um Server mit Rollen zu versehen. In einem solchen System sind alle Maschinen gleichberechtigt, und als Anwender kann man sicher sein, dass bei jeder Anfrage die zuletzt gültige Wahrheit in die Bearbeitung einfließt. Eine SQL-Datenbank, die ein solches Konzept umsetzt, ist CockroachDB [3], die auch in einer quelloffenen Lizenz angeboten wird und die wir bereits ausführlich vorgestellt haben [4]. CockroachDB nutzt im Kern den Raft-Algorithmus fürs Herstellen einer gemeinsamen Wahrheit und baut darauf all die Funktionen auf, die man von einem SQL-Datenbankserver erwartet.
Dass sich verteilte SQL-Datenbanken eine gemeinsame Wahrheit teilen müssen, leuchtet schnell ein. Einen Konsensalgorithmus brauchen aber nicht nur Systeme, auf denen ein verteilter Datenbestand liegen soll, sondern auch solche, die sich Arbeitsaufträge teilen sollen. Angenommen, Sie möchten eine Umgebung bauen, in der man Rechenaufgaben zur Bearbeitung abwirft – zum Beispiel rechenintensive wissenschaftliche Modelle. Ein großes Heer aus leistungsstarken Maschinen (sogenannten Worker-Nodes) soll sich immer eine Aufgabe schnappen und erledigen.
Auch für ein solches System braucht man eine gemeinsame Datenbasis: Sie enthält eine Liste an Aufgaben (sortiert zum Beispiel nach Eingangsdatum oder nach einer Priorität). In dieser Liste muss zuverlässig für jede Aufgabe stehen, ob sie schon ein Worker-Node in Bearbeitung hat und ob sie eventuell schon bearbeitet ist. Nur so ist sichergestellt, dass eine Aufgabe nicht mehrmals bearbeitet wird. Stellen Sie sich das Chaos vor, das in einer Bank entstehen würde, wenn eine Überweisungsaufgabe von mehreren Workern ausgeführt würde, nur weil die Aufgabenliste nicht perfekt synchronisiert wurde.
Was der Algorithmus leisten muss
Ob gemeinsame Datenbank oder System für verteiltes Rechnen, die Anforderungen an ein Verfahren, das die gemeinsame Wahrheit koordiniert, sind in beiden Fällen identisch: Gesucht wird ein Ansatz, der zu jeder Zeit sicherstellt, dass eine Anfrage nur mit der zuletzt geschriebenen Wahrheit beantwortet werden kann. Umgehen muss das System mit den Widrigkeiten, die in jedem verteilten System auftreten können. Verzögerungen im Netzwerk, Paketverluste auf dem Weg sowie doppelte oder vertauschte Netzwerkpakete gehören zum Alltag. Die verteilte Datenbank darf also nicht an Schluckauf im Netzwerk scheitern – bestenfalls muss man die einzelnen Server über Rechenzentren verteilen können, die über das Internet miteinander verbunden sind.
Außerdem sollte der Algorithmus sicherstellen, dass temporäre oder dauerhafte Ausfälle einzelner Cluster-Mitglieder nicht dazu führen, dass das Gesamtsystem keine Anfragen mehr bearbeiten kann oder gar falsche Ergebnisse liefert. Neustarts, Updates oder Stromausfälle kommen vor und müssen folgenlos bleiben. Wären solche Ausfälle ein Problem, hätte man lediglich die Komplexität skaliert, in Sachen Hochverfügbarkeit und Fehlertoleranz aber gar nichts gewonnen. Unschön wäre es auch, wenn alle Server bei jeder lesenden Anfrage all ihre Kollegen im Cluster nach der aktuellen Wahrheit fragen müssten – dann hätte man ein ziemlich lahmes System geplant.
Eine Bedingung versucht Raft ausdrücklich nicht zu erfüllen: den Umgang mit sogenannten byzantinischen Fehlern. So nennt die Forschung in Anlehnung an eine Anekdote mit Generälen aus Byzanz alle Probleme, die durch böswillige Cluster-Mitglieder ausgelöst werden – wenn ein Server im Cluster die anderen anlügt oder Nachrichten mutwillig zurückhält, könnte er die gemeinsame Wahrheit gefährden. Das ist aber in der Praxis kein Problem: Ein Cluster wird für gewöhnlich von einem Administrator aufgesetzt und alle Server werden mit derselben Software ausgestattet.
Eine technische Lösung für byzantinische Umgebungen gibt es abseits von Raft: Blockchains. Auch wenn die Bedingungen in den allermeisten Unternehmensnetzwerken nicht-byzantinisch sind, ist die fixe Idee von Blockchains im Unternehmen bis heute präsent, weil findige Verkäufer erkannt haben, dass Software mit Blockchain interessanter und attraktiver wirkt als Software mit einem vergleichsweise langweiligen Konsens-Algorithmus.
Auftritt von Raft
Erfunden und veröffentlicht haben den Raft-Algorithmus Diego Ongaro und John Ousterhout von der Stanford-University im Jahr 2014. Bemerkenswert ist ihre Herangehensweise, die sie in ihrem wissenschaftlichen Paper "In Search of an Understandable Consensus Algorithm" [7] beschreiben. Schon im Titel taucht die Verständlichkeit als Ziel erstmals auf – und das Thema zieht sich durch den gesamten Artikel. Die zentrale Überzeugung der Autoren bestand darin, dass ein guter Konsens-Algorithmus leicht zu erklären sein muss. Nur dann könne man ihn auch gut und stabil implementieren, verteilte Systeme anständig warten und bei Problemen reagieren. Verständlichkeit soll also Entwicklern und Admins von Raft-Systemen gleichermaßen helfen.
Zu dieser Erkenntnis kamen die beiden Forscher durch schlechte Erfahrungen mit dem damals dominierenden Konsensverfahren namens Paxos oder genauer Multi-Paxos. Das sei, so die Autoren, so vertrackt, dass sie nach zahlreichen Interviews niemanden finden konnten, der Multi-Paxos vollständig und richtig erklären konnte. Die meisten Erklärungsansätze bezögen sich auf den Unterbau Single-Decree-Paxos, der allein schon nicht intuitiv zu verstehen sei – Multi-Paxos legt noch Komplexitätsstufen obendrauf. Kurzum: 2014 war der Stand der Technik ein undurchdringliches Konstrukt, das zu allem Überfluss auch noch immer etwas anders implementiert wurde, gern auch in proprietärer Software ohne öffentlichen Quellcode. Und nicht überall, wo Paxos draufstand, war auch die reine akademische Paxos-Lehre drin.
Anstatt an Paxos herumzudoktern und es zu entschlacken, wie es andere Forscher zuvor versucht hatten, entschieden sich Ongaro und Ousterhout für einen radikalen Neuanfang mit erfrischend wenigen Komponenten. In einem Raft-Cluster kann jeder Server nur einen von drei Zuständen einnehmen: Anführer (Leader), Untertan (Follower) oder Kandidat (Candidate). Im Normalzustand sind diese Rollen klar aufgeteilt: Es gibt immer nur einen Leader, alle anderen Server sind Follower und es gibt keine Candidates. In diesem Zustand arbeitet ein Cluster die meiste Zeit des Tages und kann Lese- und Schreibaufgaben von Clients entgegennehmen.
Wie ein Raft-Cluster arbeitet
Um in diesen Grundzustand zu kommen, ist kein menschliches Eingreifen nötig – beim Einrichten eines Raft-Clusters startet der Administrator einfach mehrere absolut gleichwertige Maschinen und übergibt jeder Maschine eine Liste an Adressen aller anderen Mitspieler. Die wichtigste Bedingung fürs Gelingen: Die Server müssen in einem Netzwerk stecken und einander darüber erreichen, außerdem sollten sie alle dieselbe Uhrzeit haben. Im Original-Paper kommunizieren die Systeme über Remote-Procedure-Calls (RPC), theoretisch könnte man Raft aber auch mit jedem anderen Mechanismus implementieren.
Beim Start erklärt sich jeder Server zunächst zum Follower und wartet auf Anweisungen eines Leaders, genauer auf das sogenannte Heartbeat-Signal, das nur Leader abgeben – das würde aber ewig dauern, weil ein frischer Cluster anfangs führungslos ist. Damit jetzt nicht alle Server dauerhaft warten, erzeugt jeder Server beim Start eine zufällige Wartezeit (Election Timeout genannt), die innerhalb einer in der Implementierung festgelegten Zeitspanne liegt (die Autoren schlagen zwischen 150 und 300 Millisekunden vor). Jedes Mitglied ist also – per Zufall festgelegt – unterschiedlich geduldig.
Wahlverfahren
Derjenige Server, dem zuerst der Geduldsfaden reißt, eröffnet eine neue Wahl, wechselt in die Rolle Candidate und stimmt selbstbewusst schon mal für sich selbst. Dann erhöht er in seinem Speicher die Nummer der Wahlperiode (die sogenannte Term) und sendet allen anderen Cluster-Mitgliedern eine Wahlbenachrichtigung (mit einem RPC vom Typ RequestVote). Einen Wahlkampf gibt es nicht – alle anderen Server, die gerade führungslos vor sich hin warten, nehmen das Angebot dankend an und stimmen umgehend für den ersten Kollegen, der eine Wahl ausgerufen hat, indem sie ihm mit Zustimmung antworten.
Sobald der Candidate die Mehrheit der möglichen Stimmen als Antwort erhalten hat, ernennt er sich zum Leader und beginnt mit seinen Amtsgeschäften: Er versendet Heartbeat-Nachrichten per RPC, alle anderen Server erkennen ihn schlagartig als Leader an und wechseln in den Follower-Zustand. Sollten andere Server durch unglücklichen Zufall parallel eine Wahl angezettelt haben, brechen sie diese bei Erhalt einer Heartbeat-Nachricht sofort ab und folgen ab sofort dem Leader.
Jetzt ist der Cluster bereit, Anfragen von Clients entgegenzunehmen. Beantworten wird solche Anfragen immer nur der Leader, ein unbedarfter Client kennt den aber nicht und beginnt deshalb immer damit, einen zufällig ausgewählten Server zu fragen – der Client braucht also eine Liste aller Server im Cluster. Ist der befragte Server aktuell nicht Leader, muss er die Adresse seines Leaders verraten. Die kann sich der Client erst mal merken und dort künftig nachfragen. Sollte der befragte Server aktuell vom Rest des Clusters getrennt sein, muss der Client sich einen anderen Server zufällig aussuchen und dort anklopfen.
Anführer und Untertanen
Hat der Client den Leader gefunden, darf er ihn befragen. Noch ist der frische Cluster aber leer, es gibt also nicht viel zu erfahren. Als einfaches Beispiel soll das System eine einzige Zahl verwalten – angenommen, es handelt sich um eine Art Kontostand. In diesem fiktiven System kommt nach erfolgreicher Wahl der erste schreibende Befehl beim Leader an: Die Zahl soll auf 100 geändert werden. In einem Raft-System führt jeder Server zwei Datenstrukturen, einmal ein Log, das alle Schreibbefehle enthält, außerdem die State-Machine, die immer die aktuelle Wahrheit verwaltet.
Zunächst schreibt der Leader den eingegangenen Änderungsbefehl in sein Log, dann schickt er einen RPC vom Typ AppendEntries parallel an alle Follower. Die schreiben die Änderung ebenfalls in ihr Log und bestätigen dem Leader den Empfang. Hat dieser Bestätigungen von mehr als der Hälfte der Server, betrachtet er den Befehl als committed, führt den Änderungswunsch (erhöhe die Zahl auf 100) in seiner State-Machine aus und schickt dem Client die Antwort: Neuer Wert ist 100. Erst dann sagt er allen Followern Bescheid, dass die Änderung committed ist und auch sie die Änderung in ihren State-Machines ausführen können. Mit diesem einfachen Abgleich ist schon einmal sichergestellt, dass die State-Machines aller Server meistens denselben Wert enthalten.
Umgang mit Problemen
Im Kern ist das auch schon das Geheimnis von Raft. In einer perfekten Welt könnte das System für immer so weiterarbeiten – spannend wird es erst, weil die Welt eben nicht perfekt ist und allerhand schiefgehen kann. Das gefühlt schwerste Problem ist in einem Raft-Cluster am schnellsten gelöst: der Ausfall eines Leaders. Angenommen, der Admin schaltet den Server für ein Update aus. Die Follower werden diesen Zustand schnell bemerken, weil die regelmäßigen Heartbeat-Nachrichten ausbleiben. Wie schon beim Einrichten des Clusters wird einem Server zuerst der Geduldsfaden reißen und er wird eine Wahl veranstalten. Dafür macht er sich wieder zum Candidate und eröffnet eine neue Term – ob diese Wahl erfolgreich sein kann, ist abhängig von der Größe des Clusters.
Ein typischer Raft-Cluster besteht aus drei oder fünf Servern. Wichtig für das Verständnis: Alle Server haben eine Liste mit allen Beteiligten, kennen also auch die Gesamtgröße des Clusters und wissen somit, wo die Grenze für eine Mehrheit bei Wahlen liegt. In einer Umgebung mit drei Servern ist es kein Problem, wenn mal einer ausfällt, selbst wenn es der Leader ist. Einer der anderen stellt sich zur Wahl, der andere stimmt für ihn und die Wahl endet mit zwei von drei Stimmen, also einer Mehrheit.
Zwei Server gleichzeitig dürfen aber nicht ausfallen, dann könnte der verbliebene keine Mehrheit mehr erzielen. Wirkungslos ist es, einen Dreier-Cluster auf vier Mitglieder zu verstärken. Für eine absolute Mehrheit bräuchten die Server in dem Fall drei Stimmen, es darf also wie im Dreier-Cluster nur einer ausfallen. Aus diesem Grund empfehlen alle Dokumentationen von auf Raft basierender Software ungerade Clustergrößen. Bei fünf Mitspielern dürfen schon zwei gleichzeitig ausfallen, die verbliebenen drei können problemlos wählen. Von Clustern mit mehr als sieben Servern raten Raft-Experten eher ab – dann wird das System nur noch träger und nicht mehr stabiler.
Fehlende Untertanen
Aus einem Zustand ohne Leader kann sich der Cluster in wenigen Millisekunden selbst befreien und mit neuem Leader weiter Clients bedienen. Doch wie sieht es mit dem Ausfall eines Followers aus? Steigt ein solcher aus, fällt das dem Leader spätestens beim nächsten Schreibbefehl auf – und dafür muss man nicht einmal auf einen schreibenden Client warten, denn technisch sind die Heartbeat-Nachrichten auch nur Schreibbefehle (AppendEntries) ohne Inhalt.
Der Leader wird also sehr bald versuchen, eine Bestätigung für eine AppendEntries-Nachricht zu erhalten. Bleibt diese aus, wird er es immer wieder versuchen – ein anfragender Client muss auf diese Zeremonie aber nicht warten, er bekommt seine Antwort, sobald die Hälfte der Follower geantwortet hat. Ist ein Follower also mal wegen Netzwerkstörungen oder Neustart ein paar Minuten weg, wird er am Ende eine Liste an Änderungsaufträgen bekommen und diese der Reihe nach abarbeiten. Damit es dabei kein Durcheinander gibt, sind alle Schreibaufträge an die Follower nummeriert und enthalten auch immer die Nummer des zuletzt als committed markierten Auftrags sowie die Nummer der Wahlperiode.
Bevor ein Follower seinem Leader eine Bestätigung schickt, prüft er, ob er die vorangegangene Nachricht erhalten hat. Durch diese Prüfung und die Bestätigung kann jeder Leader eine Liste führen, auf welchem Stand seine Follower sind. Kommt es durch Widrigkeiten des Netzes mal zu einer Abweichung, greift der Leader ein: Er schaut in seiner Liste, bis zu welcher Nachricht der Follower den richtigen Stand kennt, befiehlt dann die Löschung aller späteren Log-Einträge und schickt ihm die Änderungen noch einmal in richtiger Reihenfolge. Sobald er für den letzten Eintrag eine Bestätigung hat, ist der Follower wieder auf Kurs.
Zusätzliche Regeln
Für den Fall von Neuwahlen haben sich die Raft-Autoren einen weiteren Schutzmechanismus einfallen lassen: Bisher hatte jeder Kandidat, der eine Neuwahl ausgerufen hat, die Stimmen seiner Kollegen sicher. Doch eine Einschränkung (die Leader-Completeness-Property) ist nötig, damit nur ein Server zum Leader wird, der den zuletzt als committed bekannten Stand kennt. Dafür schickt jeder Kandidat im Rahmen der RequestVote-Nachricht die fortlaufende Nummer und die Term-Nummer seines letzten Log-Eintrags mit. Die anderen würden ihm die Stimme verwehren, wenn sie selbst einen Eintrag mit höherer Nummer hätten.
Zwei wesentliche Komponenten von Raft, die Wahl des Leaders und auch das Commit von neuen Log-Einträgen, funktionieren nur mit einer Mehrheit. So verhindert Raft einen Zustand, der in anderen Konsens-Algorithmen durchaus möglich und bei Administratoren gefürchtet ist: das Split-Brain-Szenario, bei dem ein Cluster in zwei Teile zerfällt (zum Beispiel durch eine fehlende Netzwerkverbindung) und in dem beide Teile von sich behaupten, die Wahrheit zu verwalten.
»Durch konsequente Mehrheitswahlen verhindert Raft das bei Clustern gefürchtete Split-Brain-Szenario.«
Beitritte und Austritte
Die letzte große Baustelle, mit der sich die Raft-Autoren befasst haben, ist die Mitgliederverwaltung: Unpraktikabel wäre es, einen Cluster bei Änderungen herunterzufahren und mit neuer Mitgliederliste wieder zu starten – Server soll man im laufenden Betrieb hinzufügen und entfernen können. Um das zu gewährleisten, haben sich Ongaro und Ousterhout dazu entschieden, auch die Mitgliederverwaltung wie die Nutzdaten zu behandeln und mit den Raft-Mechanismen zu replizieren. Sobald eine Änderung der Konfiguration (Hinzufügen oder Entfernen eines Mitglieds) verbreitet ist, beginnen alle Follower damit zu arbeiten.
Für neue Server gibt es aber noch eine sinnvolle Ausnahmeregelung: Sie können in den ersten Minuten noch nicht sinnvoll am Cluster mitwirken, weil sie mit einer komplett leeren State-Machine und leerem Log einsteigen und zunächst vom Leader mit alten Logs bombardiert werden. In dieser Phase sind sie weder aktiv noch passiv wahlberechtigt und dürfen in Ruhe die Daten verarbeiten. Sobald sie den letzten Log-Eintrag verarbeitet haben, steigen sie als wahlberechtigtes Vollmitglied ein.
Log-Bereinigung
Mit diesen überschaubaren Komponenten erfüllt Raft bereits alle Anforderungen in Bezug auf Stabilität und gemeinsame Wahrheit – ein nicht nur kosmetisches Problem bleibt aber: Die Liste an Log-Einträgen wird länger und länger und verbraucht immer mehr Speicherplatz. Zur Verwaltung einer einzigen Zahl in der State-Machine können nach wochenlangem Betrieb gigabyteweise Logs anfallen, zusätzlich aufgebläht mit Milliarden leerer Heartbeat-Nachrichten.
Damit Raft praktikabel bleibt, haben die Autoren Snapshots erfunden, die regelmäßig (abhängig von der Implementierung) angefertigt werden. Ein Snapshot fügt alte Logeinträge zusammen, und anstatt Tausende Änderungswünsche mitzuschleppen, bleibt ein Befehl übrig, der nur das letzte Ergebnis enthält. Die komprimierten Logs werden entsorgt. Die Snapshots entlasten nicht nur die Festplatte, sie machen auch neuen Servern den Einstieg leichter – die bekommen Snapshots vom Leader und sind somit schneller einsatzbereit.
In der Praxis
In freier Wildbahn findet man den Raft-Algorithmus besonders oft in vergleichsweise neuen Anwendungen, die einen Modus für Hochverfügbarkeit mitbringen. Wenn in der Dokumentation einer neuen Datenbank von mindestens drei Servern die Rede ist, ist das ein gutes Indiz für Raft. Neben den schon genannten etcd [8] und CockroachDB [9] sind das häufig Anwendungen aus dem Cloud-Native-Umfeld, also solche, die redundant und skalierbar in Containern laufen sollen: Docker Swarm nutzt Raft, ebenso das Nachrichtenverteilsystem NATS [10] und die populäre Datenbank MongoDB [11].
Für Administratoren ist Raft vergleichsweise pflegeleicht. Man startet eine ungerade Anzahl an Servern und überlässt alles Weitere dem Algorithmus – achten sollte man noch darauf, dass sie alle ihre Uhrzeit beim selben NTP-Server beziehen und dass die Latenzen im Netzwerk klein sind. Aussetzer von Maschinen steckt Raft gut weg, theoretisch auch über Stunden und Tage. Es gibt also keine magische Grenze, ab der ein ausgefallener Server nicht wieder hochgefahren werden dürfte – der Leader würde ihm nach kurzem oder langem Ausfall eine Liste mit Aufträgen zuspielen, sodass er sich wieder berappeln kann.
Dennoch sind Admins von auf Raft basierender Software gut beraten, die Abschnitte über "Disaster Recovery" in der Dokumentation ausführlich zu lesen und die Szenarien einmal in einer vorbereiteten Testumgebung durchzuspielen. Die Anwendungen, die auf Raft aufbauen, führen teils eigene zeitliche Grenzen für ausgeschaltete Server ein und bringen auch Befehle mit, um einen Server sauber für einige Zeit vom Netz zu nehmen (sogenanntes Draining). Und ganz wichtig: Nur weil Raft die Daten auf mehreren Maschinen speichert, heißt das nicht, dass Backups entfallen dürfen. Auch ein Raft-Cluster kann sich mal so verabschieden, dass er sich nicht aus eigener Kraft befreien kann. Regelmäßige Sicherungen sind also Pflicht, und das Einspielen der Backups in einen frischen Cluster sollte man vor dem Einsatz mal ausprobiert haben.
Wenn Sie als Entwickler mit dem Gedanken spielen, Raft in eigene Software einzubauen, die hochverfügbar laufen soll, finden Sie fertig implementierte Raft-Bibliotheken in verschiedenen Programmiersprachen. In vielen Fällen kann man sich das Leben aber einfacher machen und eine auf Raft basierende Datenbank wie etcd oder CockroachDB nutzen. Dann sparen Sie sich zum Beispiel das Implementieren eines Backup-Mechanismus.
Fazit
Einfachheit als Schlüssel zum Erfolg: Die Autoren des Raft-Papers Diego Ongaro und John Ousterhout haben einen für neue Algorithmen ungewöhnlichen Weg gewählt und mit Methoden wie Nutzerumfragen ein Verfahren entwickelt, das primär einfach zu erklären und zu verstehen ist und auf der anderen Seite alle wesentlichen Anforderungen erfüllt. Einen mathematischen Beweis, dass Raft funktioniert, bleibt das Original-Paper schuldig, doch den Beweis hat die Praxis erbracht: Raft machte schnell Karriere, wurde zu einem Quasi-Standard für neu entwickelte verteilte Systeme und beweist seitdem etwa als Teil von Kubernetes jeden Tag, dass es sehr reibungsarm funktioniert.
(jam [12])
URL dieses Artikels:
https://www.heise.de/-7269322
Links in diesem Artikel:
[1] https://www.heise.de/ct/
[2] https://raft.github.io/
[3] https://www.heise.de/news/CockroachDB-Neues-Serverless-Angebot-fuer-gemietete-Datenbank-7271970.html
[4] https://www.heise.de/ratgeber/Verteilte-Datenbanken-mit-CockroachDB-4603245.html
[5] https://www.heise.de/select/ct
[6] https://shop.heise.de/magazine/ct-magazin/
[7] https://raft.github.io/raft.pdf
[8] https://etcd.io/
[9] https://www.cockroachlabs.com/
[10] https://docs.nats.io/
[11] https://www.mongodb.com/de-de
[12] mailto:jam@ct.de
Copyright © 2022 Heise Medien