Wenn ein Cluster durchdreht: Die harte Realität hinter Drei-Node-High-Availability

Das Setup, das auf dem Papier perfekt aussieht

Ein kleines Virtualisierungscluster kann sich wie der Sweet Spot für Zuverlässigkeit anfühlen. Drei Nodes. Shared Storage über iSCSI oder NFS. High Availability so konfiguriert, dass virtuelle Maschinen nahtlos zwischen Hosts wandern können. Der Wartungsmodus funktioniert wunderbar: Man versetzt einen Node in den Wartungsmodus, Live-Migration springt an, Workloads ziehen weg, und der Host bootet friedlich neu.

Alles verhält sich genau wie versprochen.

Deshalb wird die Situation so verwirrend, wenn ein Administrator etwas scheinbar Harmloses ausprobiert. Zwei Hosts gehen in den Wartungsmodus. Alle virtuellen Maschinen migrieren erfolgreich zum dritten Node. Nichts ist überlastet. Die Hardware ist stark genug, um jede Workload auf einer einzigen Maschine zu betreiben.

Dann booten beide Wartungs-Nodes neu.

Und plötzlich beginnt sich der letzte Node so zu verhalten, als sei etwas furchtbar schiefgelaufen. Dienste geraten in Panik. Manchmal bootet der Host sogar neu. Was wie ein routinemäßiges Wartungsfenster aussah, fühlt sich plötzlich an, als würde sich das Cluster wehren.

Für alle, die dabei zusehen, wie Fehlermeldungen über die Konsole scrollen, wird die Frage sofort dringlich und frustrierend: Warum kann der letzte Node nicht einfach weiter die VMs betreiben?

Die Paranoia des Clusters setzt ein

Die Antwort liegt in einer Regel, die die meisten High-Availability-Cluster still im Hintergrund regiert: Mehrheitskonsens.

Verteilte Systeme gehen nicht davon aus, zu verstehen, was im Netzwerk passiert. Sie nehmen das Gegenteil an. Netzwerke fallen aus, Verbindungen brechen ab, Switches spinnen, und Pakete verschwinden. Wegen dieser Unsicherheit verlassen sich Cluster auf Quorum, die Fähigkeit einer Mehrheit der Nodes, zu bestätigen, dass der Cluster-Zustand gültig ist.

In einem Drei-Node-Cluster sind diese Mehrheit zwei Nodes.

In dem Moment, in dem zwei Nodes verschwinden, verliert der verbleibende Host das Quorum. Aus Sicht des Clusters weiß er nicht, ob die anderen Maschinen tatsächlich offline sind oder ob er selbst vom Rest des Systems isoliert ist.

Ein Ingenieur fasste es unverblümt zusammen: Wenn zwei Nodes verschwinden, geht der letzte davon aus, dass er selbst das Problem sein könnte.

Dieser Verdacht löst Schutzverhalten aus. Statt Workloads blind weiterlaufen zu lassen, stoppt das Cluster den Betrieb, um etwas weit Schlimmeres als Ausfallzeit zu vermeiden.

Die Katastrophe, die alle vermeiden wollen

Der Grund für diese strenge Regel ist etwas, das Cluster-Ingenieure mehr fürchten als fast alles andere: Split Brain.

Stellen Sie sich vor, das Cluster hätte dem letzten Node erlaubt, weiterhin jede VM ohne Nachfrage zu betreiben. Stellen Sie sich nun vor, das ursprüngliche Szenario wäre kein geplanter Neustart gewesen, sondern eine Netzwerkpartitionierung. Ein Node verliert die Verbindung zu den anderen beiden.

Wenn der isolierte Node weiter Workloads betreibt, während die anderen Nodes annehmen, er sei tot, startet das Cluster dieselben virtuellen Maschinen möglicherweise anderswo.

Plötzlich existieren zwei identische Instanzen derselben VM gleichzeitig.

Datenbanken schreiben widersprüchliche Daten. Dateisysteme werden beschädigt. Transaktionen divergieren auf Weisen, die sich im Nachhinein kaum reparieren lassen. Jemand beschrieb das Ergebnis als „von jeder VM zwei", was üblicherweise einen sehr langen Tag für die zuständige Person bedeutet.

Um dieses Szenario zu verhindern, folgt Cluster-Software einer konservativen Regel: Wenn ein Node nicht bestätigen kann, dass er zur Mehrheit gehört, weigert er sich, Dienste weiter zu betreiben.

Selbst wenn der Administrator weiß, dass die Situation sicher ist.

Der Wartungsmodus ändert die Mathematik nicht

Ein Detail, das viele überrascht, ist, dass der Wartungsmodus dieses Verhalten nicht ändert. Es fühlt sich an, als sollte er das. Schließlich teilt das Versetzen von Nodes in den Wartungsmodus dem Cluster klar mit, dass diese Maschinen absichtlich den Workload-Pool verlassen.

Aber der Wartungsmodus dreht sich um Scheduling und Migration. Er hebelt nicht das grundlegende Konsenssystem aus, das die Cluster-Sicherheit regiert.

Sobald zwei Nodes aufhören zu kommunizieren, sieht der verbleibende Host trotzdem einen Quorum-Verlust. Die Cluster-Logik kümmert sich nicht darum, dass die Nodes absichtlich neu gestartet wurden. Sie beobachtet einfach, dass die Kommunikation mit der Mehrheit verschwunden ist.

In verteilten Systemen ist Absicht unsichtbar. Nur Signale zählen.

Der VMware-Vergleich, der immer wieder auftaucht

Wann immer diese Situation auftritt, tauchen schnell Vergleiche mit anderen Virtualisierungsplattformen auf.

Manche Administratoren verweisen auf VMwares Datastore-Heartbeat-System. In diesem Modell können Hosts Informationen direkt in Shared Storage schreiben, wodurch andere Nodes bestätigen können, ob eine VM tatsächlich woanders läuft.

Dieser Ansatz gibt dem Cluster ein weiteres Signal jenseits der Netzwerkkommunikation.

Aber das ist keine universelle Lösung. Unterschiedliche Plattformen treffen unterschiedliche Design-Entscheidungen darüber, wie Cluster-Sicherheit funktionieren sollte. Manche verlassen sich stark auf Storage-Signale. Andere priorisieren Netzwerkkonsens zwischen Nodes.

Ein Kommentar brachte es mit einem leich