Hochverfügbarkeits-Cluster: Das 3-Node-Quorum

Fragen Sie jemanden, der ausfallsichere Systeme entwirft, warum Hochverfügbarkeits-Cluster so oft aus drei Knoten bestehen, und meist bekommen Sie eine selbstbewusste Antwort, die sich als nur halb richtig erweist. Drei Knoten sind tatsächlich die Basis für echte Hochverfügbarkeit, doch der Grund ist nicht einfach, dass mehr Kopien sicherer wären. Es läuft auf ein tückisch feines Problem hinaus: Wie einigt sich eine Gruppe von Maschinen auf die Wahrheit, wenn einige von ihnen nicht mehr miteinander sprechen können? Die Antwort darauf heißt Quorum, und das Quorum ist der Grund, warum zwei Knoten gefährlich und drei das praktische Minimum sind.

Dieser Beitrag erklärt die Logik von Grund auf, warum naive Redundanz scheitert, was Split-Brain ist und warum es so zerstörerisch wirkt, wie ein ungeradzahliges Quorum es löst und wie diese Ideen in den realen Cluster-Systemen auftauchen, die eine Private Cloud betreiben.

Redundanz ist nicht dasselbe wie Verfügbarkeit

Man nimmt leicht an, dass ein zweiter Server automatisch Hochverfügbarkeit bringt. Fällt einer aus, übernimmt der andere, also ist man abgesichert. Für ein einfaches Active-Passive-Failover stimmt diese Intuition ungefähr, doch sie verbirgt einen gefährlichen Grenzfall, der genau dann auftritt, wenn beide Knoten am Leben sind, aber nicht mehr miteinander kommunizieren können.

Hochverfügbarkeit bedeutet nicht nur, einen sterbenden Knoten zu überstehen. Ein toter Knoten ist der einfache Fall, er antwortet nicht mehr, und alle sind sich einig, dass er weg ist. Der schwierige Fall ist der Knoten, der noch läuft, aber isoliert ist, durch eine ausgefallene Netzverbindung abgeschnitten, während er sich weiter für gesund und zuständig hält. Für dieses Szenario zu entwerfen, nicht nur für saubere Ausfälle, unterscheidet einen echten HA-Cluster von einem Serverpaar, das sich zufällig gegenseitig absichert.

Die Zwei-Knoten-Falle und Split-Brain

Stellen Sie sich einen klassischen Zwei-Knoten-Cluster vor: einer aktiv, einer im Standby, gemeinsam zuständig für eine Datenbank oder eine virtuelle IP. Die Netzverbindung zwischen ihnen fällt aus, doch beide Knoten sind völlig gesund. Nun blickt jeder Knoten über die Verbindung, sieht nichts und zieht denselben logischen Schluss: Mein Partner ist gestorben, also muss ich übernehmen.

Das Ergebnis ist katastrophal. Beide Knoten halten sich jetzt für den einzigen Überlebenden und den rechtmäßigen Primärknoten. Beide binden den gemeinsamen Speicher ein, beide nehmen Schreibvorgänge an, beide beantworten Client-Anfragen. Das ist Split-Brain, und es ist weit schlimmer als ein Ausfall. Ein Ausfall bedeutet Stillstand; Split-Brain bedeutet zwei auseinanderdriftende Kopien Ihrer Daten, die parallel widersprüchliche Änderungen ansammeln. Wenn die Verbindung wiederkehrt, gibt es keinen sauberen Weg, sie zu versöhnen. Sie müssen wählen, welche Schreibvorgänge Sie verwerfen, was in einem transaktionalen System verlorene Bestellungen, beschädigte Datensätze oder Schlimmeres bedeuten kann.

Die Ursache ist, dass sich bei zwei Knoten nicht unterscheiden lässt zwischen mein Partner ist ausgefallen und ich bin derjenige, der abgeschnitten ist. Jeder Knoten hat genau eine Stimme, und eine Stimme kann kein Patt brechen. Symmetrie ist der Feind der Einigung.

Quorum: sich auf eine einzige Quelle der Wahrheit einigen

Das Quorum ist der Mechanismus, der die Symmetrie bricht. Das Prinzip ist einfach: Der Cluster darf nur arbeiten, wenn eine strikte Mehrheit seiner Mitglieder sich darauf einigen kann, Teil der aktiven Gruppe zu sein. Ein Knoten, oder eine Gruppe von Knoten, muss mehr als die Hälfte der Gesamtstimmen halten, bevor er als Primärknoten agieren darf. Eine Minderheit, so gesund sie auch sei, muss zurücktreten und den Dienst verweigern.

Wenden Sie das auf einen Drei-Knoten-Cluster an. Gesamtstimmen: drei. Benötigte Mehrheit: zwei. Nun denken Sie sich eine Netzpartition, die den Cluster teilt, einen Knoten auf der einen Seite isoliert und zwei auf der anderen zusammenlässt. Das Paar hat zwei Stimmen, eine Mehrheit, behält also das Quorum und läuft weiter. Der einzelne Knoten hat nur eine Stimme, weiß, dass er in der Minderheit ist, und stellt freiwillig den Dienst ein, statt ein Auseinanderdriften zu riskieren. Split-Brain wird unmöglich, weil nicht beide Seiten gleichzeitig eine Mehrheit von drei halten können.

Das ist der ganze Kniff. Das Quorum verhindert keine Partitionen; es garantiert, dass höchstens eine Seite jeder Partition jemals handeln darf, und genau das brauchen Sie, um die Datenintegrität zu schützen.

Warum drei, und warum ungerade Zahlen

Hier beantwortet sich die Frage warum nicht zwei von selbst. Zwei Knoten können ohne Einstimmigkeit keine Mehrheit von zwei bilden, und Einstimmigkeit ist genau das, was eine Netzpartition zerstört. Bei zwei Stimmen hat ein Eins-zu-eins-Split keine Mehrheit, also hält entweder der Cluster vollständig an (keine Verfügbarkeit) oder jede Seite macht allein weiter (Split-Brain). Es gibt kein sicheres Ergebnis. Drei ist der kleinste Cluster, bei dem ein einzelner Ausfall noch eine funktionierende Mehrheit übrig lässt.

Der Fall gegen gerade Zahlen

Wenn drei gut ist, müssen vier doch besser sein? Wider Erwarten nein, und der Grund ist aufschlussreich. Mit vier Knoten vertragen Sie einen Ausfall (drei bleiben, eine Mehrheit), doch ein sauberer Zwei-zu-zwei-Netz-Split lässt keiner Seite eine Mehrheit, also friert der gesamte Cluster ein. Sie haben einen Knoten hinzugefügt und gegenüber drei keine zusätzliche Ausfalltoleranz gewonnen, dafür aber ein neues Patt-Szenario eingeführt. Fünf Knoten vertragen zwei Ausfälle und vermeiden weiterhin Patts; vier vertragen nur einen, genau wie drei. Deshalb werden HA-Cluster fast immer in ungeraden Zahlen gebaut: drei, fünf, sieben. Jeder ungerade Schritt erkauft echte, zusätzliche Fehlertoleranz, während gerade Zahlen nur Kosten und ein Patt-Risiko hinzufügen.

Der reine Quorum-Tiebreaker

Manchmal sind drei vollwertige Knoten überdimensioniert, etwa wenn zwei kräftige Server den Workload bequem tragen. Der elegante Kompromiss ist ein Witness oder Quorum-Gerät: ein leichtgewichtiger dritter Wähler, der keine Daten hält und keinen Workload fährt, sondern allein existiert, um in einer Partition die entscheidende Stimme abzugeben. Zwei Datenknoten plus ein winziger Witness ergeben die drei Stimmen umfassende, Split-Brain-sichere Topologie zu einem Bruchteil der Kosten eines dritten vollwertigen Servers.

Fencing: dafür sorgen, dass der Verlierer unten bleibt

Das Quorum entscheidet, wer Primärknoten sein soll, doch ein robuster Cluster muss auch garantieren, dass der Knoten, der die Abstimmung verloren hat, tatsächlich stoppt. Ein Minderheitsknoten, der fehlfunktioniert, tritt vielleicht nicht sauber von selbst zurück. Hier kommt Fencing (auch STONITH, Shoot The Other Node In The Head) ins Spiel: Der Cluster isoliert oder schaltet den unterlegenen Knoten zwangsweise ab, oft indem er ihm auf Hardwareebene Strom oder Netz kappt, sodass keinerlei Chance besteht, dass er weiter in den gemeinsamen Speicher schreibt.

Quorum und Fencing ergänzen sich. Das Quorum ist die Entscheidung; Fencing ist die Durchsetzung. Zusammen stellen sie nicht nur sicher, dass der Cluster einen einzigen Primärknoten wählt, sondern auch, dass der abgewiesene Knoten keinen Schaden anrichten kann, solange er über seinen eigenen Zustand im Unklaren ist.

Wie sich das durch eine Private Cloud zieht

Diese Prinzipien sind nicht abstrakt; sie stecken in nahezu jedem Cluster-System, auf das Sie sich verlassen. Verteilte Datenbanken wie die Galera-basierten MySQL/MariaDB-Cluster hinter vielen OpenStack-Steuerungsebenen verlangen eine Mehrheit der Knoten online, um Schreibvorgänge anzunehmen, und genau deshalb ist ein Drei-Knoten-Datenbankcluster Standard. Die OpenStack-Steuerungsebene selbst, die API-Dienste, die Message Queue und die Koordinationsschicht, wird über drei Controller verteilt, sodass der Verlust eines einzelnen eine funktionierende Mehrheit übrig lässt. Ceph, die verteilte Speicherschicht, betreibt seine Monitore aus genau demselben Grund als ungeradzahliges Quorum: Die Cluster-Map muss jederzeit eine einzige einvernehmliche Version haben.

Das Muster wiederholt sich, weil das zugrundeliegende Problem universell ist. Jedes System, das über mehrere Maschinen hinweg konsistent bleiben muss, steht vor der Partitionsfrage, und ein Quorum über eine ungerade Zahl von Mitgliedern ist die bewährte Antwort. Netzredundanz ergänzt das auf einer anderen Ebene, indem sie die Verbindungen zwischen diesen Knoten am Leben hält, damit Partitionen überhaupt selten bleiben, was im Mittelpunkt unseres Leitfadens zu MLAG und Netzredundanz steht.

Für echte Resilienz entwerfen

Aus all dem folgen einige praktische Prinzipien. Verwenden Sie stets eine ungerade Zahl stimmberechtigter Mitglieder, mindestens drei, fünf für höhere Fehlertoleranz. Verteilen Sie diese Mitglieder über unabhängige Fehlerdomänen, getrennte Hosts, getrennte Racks, getrennte Stromkreise, damit ein einzelnes physisches Ereignis nicht auf einen Schlag eine Mehrheit ausschalten kann. Konfigurieren Sie Fencing, damit ein verwirrter Minderheitsknoten entschieden entfernt wird. Und denken Sie daran, dass das Quorum Konsistenz schützt, nicht Kapazität: Sie brauchen weiterhin genug überlebende Knoten, um den Workload nach einem Ausfall zu tragen, nicht nur genug, um eine Abstimmung zu halten.

Genau diese Architektur baut clouditiv standardmäßig. Unsere OpenStack-Private-Clouds werden über drei Controller-Knoten mit quorum-basierten Datenbanken, einem ungeradzahligen Ceph-Monitor-Cluster und redundantem Netzwerk verteilt, sodass der Ausfall eines einzelnen Knotens oder einer einzelnen Verbindung kein Ereignis ist statt eines Ausfalls, im Dienst der 99,9 Prozent Verfügbarkeit, auf die unsere Kunden bauen. Weil der gesamte Cluster automatisch bereitgestellt wird, steht dieses ausfallsichere Drei-Knoten-Fundament in unter einer Stunde, statt tagelangen sorgfältigen Handaufbau zu verlangen. Wie die Teile zusammenpassen, sehen Sie auf unserer On-Premise-Cloud-Plattform.

Das Wesentliche

Drei Knoten sind die Basis für Hochverfügbarkeit, nicht weil drei Kopien an sich sicherer wären, sondern weil drei Stimmen die kleinste Zahl sind, die nach einem Ausfall noch eine Mehrheit bilden und so Split-Brain verhindern kann. Das Quorum lässt einen Cluster sich auf eine einzige Quelle der Wahrheit einigen, selbst wenn das Netz ihn in zwei Teile reißt; ungerade Zahlen sorgen dafür, dass es stets eine klare Mehrheit gibt; und Fencing garantiert, dass der Verlierer unten bleibt. Verstehen Sie diese drei Ideen, und die Entwurfsentscheidungen hinter jedem ernsthaften Cluster-System, von Datenbanken über Storage bis zur Cloud-Steuerungsebene, wirken nicht mehr willkürlich, sondern unausweichlich.