Verteilte Systeme mit Etcd in der Praxis
Seite 5: Exkurs
Exkurs: Ein kurzer Ausflug in den Konsens
Konsensprotokolle sind hoch komplex, aber zum Verständnis von Key-Value-Stores unvermeidlich. Das Ziel eines verteilten Key-Value-Stores ist, dass Schreiboperationen innerhalb eines bestimmten Zeitintervalls auf allen Knoten des Clusters durchgeführt werden und einen konsistenten Zustand hinterlassen. Gleichzeitig müssen sie den Wegfall eines oder mehrerer Knoten verkraften und auch im Fehlerfall ein deterministisches Verhalten zeigen.
Es gibt zwei Typen von Knoten, die für die Algorithmen zum Einsatz kommen: Der Koordinator, der auch Leader genannt wird, ist zuständig für die Zuweisung von Schreiboperation im Cluster. Die Slave-Knoten führen Schreiboperationen unter der Koordination des Leaders durch.
Die wohl bekannteste Variante eines Konsens-Algorithmus ist der 2-Phase-Commit: In der ersten Phase, die Commit-Request heißt, informiert der Koordinator die Knoten über die anstehende Operation. Er wartet, bis alle Knoten ihre Bereitschaft zur Durchführung signalisiert haben, und startet dann die zweite, die Commit Phase.
Der Koordinator wartet dann auf die Antworten seiner Slaves. Antwortet auch nur ein einzelner Teilnehmer mit abort, sendet der Koordinator rollback an alle Knoten, um wieder einen konsistenten Zustand herzustellen. Erhält er dagegen von allen ein acknowledge, schickt er commit an die Teilnehmer und sorgt dafür, dass der neue konsistente Zustand in alle Knoten persistiert wird. Problematisch wird diese Vorgehensweise beim Ausfall eines Teilnehmers oder dem Verlust einzelner Nachrichten auf dem Transportweg. Beispielsweise stellt sich die Frage, was passiert, wenn einzelne Knoten die commit-Nachricht nicht erhalten. Wie soll sich das System erholen?
Mit den Erfahrungen aus 2-Phase-Commit-basierten Systemen wurde eine ganze Reihe neuer Algorithmen entwickelt. Sie sollten besser mit Ausfällen umgehen können und eine möglichst geringe Zahl an Nachrichten zum Herstellen eines konsistenten Zustands benötigen.
RAFT-Protokoll
Bis vor etwa zwei Jahren stellte die Familie der Paxos-Protokolle den Höhepunkt dieser Entwicklung dar. Allerdings erwarben sie sich schnell den Ruf, schwer verständlich und umsetzbar zu sein. Vor allem die Analyse von Fehlverhalten stellte Anwender vor einige Probleme.
Im Jahr 2013 wurde ein Paper zu einem neuen Konsens-Protokoll mit dem Namen RAFT veröffentlicht. Sein Ziel war es, ein einfach zu verstehendes Protokoll mit ähnlicher Ausfallsicherheit und Performance wie Paxos zu entwickeln. Und dabei sollte Etcd den Konsens bilden.
Zum besseren Verständnis von Etcd ist ein Blick auf RAFT unverzichtbar. Glücklicherweise gibt es bereits eine ausgezeichnete visuelle Erklärung zu dem Thema. (rme)
