Fragen zu RAFT als Consensus Algorithmus

[Wolly300]

Hallo zusammen,

ich bin gerade dabei ein wenig RAFT zu lernen, habe aber noch so ein paar Fragen, auch die ich bisher keine wirkliche Antwort finden konnte.

RAFT ist ja dazu da, in verteilten System die Information auf verschiedene Server zu verteilen.

1. Wie werden die Daten verteilt? Hat jeder Follower eine volle Replikation der Daten, oder nur einen Teil?
2. Wird RAFT nur lokal innerhalb eines Rechenzentrums verwendet, oder wie funktioniert das, wenn man die Daten zwischen verschiedenen Rechenzentren synchron halten will?
3. Was macht man, wenn man mehr als 7 Rechner in einem RAFT System hat? RAFT ist ja so wie ich es herausgelesen habe, nur bis zu 7 Server geeignet.
4. Auf dieser Webseite kann man das System von RAFT noch einmal testen: http://play.etcd.io/play
Mir ist jedoch unklar, warum die DB Größe auf den einzelnen Clients nicht gleich ist?
5. Das System ist ja dazu da, um alle Server Synchron zu halten, aber laut Architektur Beschreibung gehen alle Anfragen ja über den Leader und werden dann an die Follower verteilt. Ist das nicht ein großes Bottleneck?

Danke schon einmal zum teilen eurer Informationen.

 

[crvn075]

1. Wie werden die Daten verteilt? Hat jeder Follower eine volle Replikation der Daten, oder nur einen Teil?

Das Ziel ist, dass jeder Follower letztlich eine vollständige Replikation des Logs hat.
Es gibt verschiedene Gründe, warum dies zu einem Zeitpunkt nicht der Fall sein könnte:

• es ist alles in Ordnung, aber die Replikation ist noch on-going (verteiltes System)
• ein oder mehrere Follower sind nicht verfügbar. Der Leader versucht diese durch Retries wieder auf den aktuellen Stand zu bringen
• der Leader schmiert ab. Der neue Leader muss erstmal einen konsistenten Stand herstellen

2. Wird RAFT nur lokal innerhalb eines Rechenzentrums verwendet, oder wie funktioniert das, wenn man die Daten zwischen verschiedenen Rechenzentren synchron halten will?

Raft selbst wäre das eigentlich egal.
Aber: umso weniger stabil die Verbindung zwischen den Knoten ist, umso höher ist die Gefahr, dass die Replikation fehlschlägt. Bestätigen nicht die Mehrheit der Follower einen vom Leader gesendeten Log-Eintrag, so kann er diesen bei sich selbst nicht comitten und es wird kein Fortschritt mehr erzielt.

In der Praxis heißt das, dass Raft in erster Linie für Cluster im selben RZ geeignet ist, oder auch zwischen RZs, wenn diese geographisch nah sind und eine hochwertige Verbindung haben (Beispiel: die Standorte einer Zone in AWS. Ein Cluster hingegen zwischen Regions aufzuspannen, wäre schon mit einem höheren Risiko verbunden).

3. Was macht man, wenn man mehr als 7 Rechner in einem RAFT System hat? RAFT ist ja so wie ich es herausgelesen habe, nur bis zu 7 Server geeignet.

Ist dem so? Wäre mir neu.

4. Auf dieser Webseite kann man das System von RAFT noch einmal testen: http://play.etcd.io/play
Mir ist jedoch unklar, warum die DB Größe auf den einzelnen Clients nicht gleich ist?

Kann ich gerade leider nicht testen, aber vielleicht hat es mit Punkt 1 zu tun.

5. Das System ist ja dazu da, um alle Server Synchron zu halten, aber laut Architektur Beschreibung gehen alle Anfragen ja über den Leader und werden dann an die Follower verteilt. Ist das nicht ein großes Bottleneck?

Technisch könnte man den Leader als Flaschenhals sehen, aber es gibt ja einen Grund, warum das so ist. Die Leader-Replikation ist gerade der Witz an Raft - es ist die Vorgehensweise, wie Raft das Problem der Konsensfindung löst. Erst wählen alle den Leader, dieser verteilt dann seine Log-Updates in einer von ihm bestimmten Reihenfolge, ohne, dass im jemand reinredet.