Der Tag, an dem ein Drei-Knoten-Cluster sich selbst nicht mehr traute

Wenn „High Availability" plötzlich zerbrechlich wirkt

Der Betrieb eines Drei-Knoten-Virtualisierungsclusters vermittelt normalerweise ein beruhigendes Gefühl von Redundanz. Sie starten einen Knoten neu, die anderen beiden halten alles am Laufen. Der Wartungsmodus migriert virtuelle Maschinen reibungslos. Das System verhält sich wie ein gut choreografierter Tanz: Workloads gleiten zwischen Hosts hin und her, während Administratoren Kaffee trinken und auf Dashboards schauen.

Dann probiert jemand etwas, das völlig vernünftig erscheint: zwei Knoten gleichzeitig neu starten, nachdem alle VMs auf den dritten Host migriert wurden. Und plötzlich verhält sich der Cluster, als hätte er eine existenzielle Krise.

Der letzte Knoten gerät in Panik, Dienste starten neu, manchmal startet sogar der Host neu. Statt ruhig jeden Workload im Cluster zu betreiben, weigert sich die letzte verbliebene Maschine, der Situation zu vertrauen. Für den Administrator, der das an der Konsole beobachtet, wirkt es absurd. Die Hardware ist stark genug, um alles zu betreiben, die VMs sind bereits migriert, und technisch ist nichts überlastet. Warum revoltiert der Cluster also in dem Moment, in dem zwei Knoten verschwinden?

Die unsichtbare Regel: Die Mehrheit gewinnt immer

Eine Erklärung kommt von Menschen, die seit Jahren mit verteilten Systemen leben. Sie verweisen auf eine grundlegende Regel, die unter den meisten High-Availability-Clustern liegt, nämlich die Mehrheitsregel.

In einem Drei-Knoten-Setup erwartet der Cluster, dass sich mindestens zwei Knoten über die Realität einig sind. Diese Übereinstimmung bildet etwas, das Quorum genannt wird. Verliert man das Quorum, vertraut das System seinem eigenen Zustand nicht mehr.

Ein Techniker erklärte es unverblümt: Wenn zwei Knoten verschwinden, nimmt der verbleibende Knoten an, dass das Problem eigentlich er selbst sein könnte. Aus seiner Perspektive sind die anderen Maschinen nicht verschwunden, er könnte einfach isoliert sein.

Das klingt paranoid, aber diese Paranoia hat einen Grund. Verteilte Systeme behandeln Isolation als gefährlich, weil sie zu etwas Schlimmerem als einem Ausfall führen kann, nämlich zu Split Brain.

Das Albtraum-Szenario, vor dem Techniker sich fürchten

Stellen Sie sich vor, der Cluster verhält sich so, wie Administratoren es zunächst erwarten. Zwei Knoten gehen offline, der letzte Knoten betreibt klaglos jede VM weiter.

Stellen Sie sich jetzt die gegenteilige Situation vor. Statt eines geplanten Neustarts fällt die Netzwerkverbindung zwischen den Knoten aus. Der Cluster spaltet sich in zwei Gruppen, die einander nicht sehen können. Glauben beide Seiten, sie seien der legitime Cluster, könnten sie beginnen, dieselben virtuellen Maschinen gleichzeitig zu betreiben.

So enden Sie mit doppelten Datenbanken, die auf denselben Storage schreiben, mit zwei Kopien einer VM, die Transaktionen verarbeiten, und mit Dateisystemen, die irreparabel beschädigt sind. Ein Administrator beschrieb das Ergebnis mit bildhaften Worten: Plötzlich hat man jede VM doppelt laufen, und der Tag geht schnell bergab.

Um diesen Albtraum zu verhindern, folgt Cluster-Software einer strikten Regel. Kann ein Knoten nicht bestätigen, dass er Teil der Mehrheit ist, weigert er sich, Workloads zu betreiben, selbst wenn das bedeutet, Dienste abzuschalten, die Sekunden zuvor noch völlig gesund waren. Aus Sicht des Systems ist es die sicherere Option, einfach alles zu stoppen.

Warum der Wartungsmodus das Problem nicht löst

Viele Administratoren gehen davon aus, dass der Wartungsmodus die Rechnung ändern sollte. Schließlich migriert das Versetzen von Knoten in den Wartungsmodus Workloads und signalisiert dem Cluster, dass diese Maschinen absichtlich zurücktreten. Diese Logik erscheint vernünftig: Wenn der Cluster weiß, dass zwei Knoten bewusst offline sind, sollte der verbleibende Host die VMs weiter betreiben.

Der Cluster sieht das anders. Der Wartungsmodus kümmert sich um Workload-Migration und Scheduling-Entscheidungen, er ändert nichts an den fundamentalen Quorum-Regeln, die die Sicherheit des Clusters bestimmen. Sobald zwei Knoten aus der Kommunikation verschwinden, verliert der verbleibende Knoten trotzdem die Mehrheitszustimmung.

Aus Sicht der Software gibt es keinen zuverlässigen Beweis, dass die anderen Hosts tatsächlich offline sind, statt schlicht unerreichbar. Verteilte Systeme arbeiten mit einer harten Grundannahme: Netzwerke lügen ständig.

Der VMware-Vergleich, der immer auftaucht

Wann immer dieses Verhalten jemanden überrascht, tauchen fast sofort Vergleiche mit anderen Virtualisierungsplattformen auf. In manchen Umgebungen sind Administratoren an Mechanismen wie Datastore-Heartbeating oder Storage-Locks gewöhnt. Diese Systeme erlauben es Hosts zu prüfen, ob eine andere Maschine eine VM noch besitzt oder den Zugriff auf gemeinsamen Storage verloren hat.

Dieser Ansatz erzeugt eine andere Art der Ausfallerkennung. Statt sich primär auf das Cluster-Quorum zu verlassen, schaut das System auf Signale des gemeinsamen Storage, um zu bestimmen, ob eine VM anderswo noch läuft.

Manche Techniker bevorzugen dieses Modell, andere sehen darin, ein Risiko gegen ein anderes einzutauschen. Wie ein Kommentator anmerkte, trifft jede Plattform unterschiedliche Designentscheidungen darüber, woher Vertrauen kommt: Netzwerk-Konsens, Storage-Locks oder eine hybride Kombination. Perfekt ist keine davon.

Die sture Einfachheit der Proxmox-Philosophie

Die Designphilosophie hinter vielen Open-Source-Clustern ist fast stur einfach. Kann ein Knoten nicht bestätigen, dass er Teil der Mehrheit ist, nimmt er an, dass etwas Gefährliches passieren könnte, und schaltet sich ab. Es gibt kein cleveres Raten und keine optimistischen Annahmen, er stoppt einfach.

Dieser Ansatz stellt Konsistenz und Datensicherheit über Komfort. Das bedeutet, Administratoren müssen strikte Betriebsmuster einhalten: Knoten einzeln neu starten, Quorum aufrechterhalten und Situationen vermeiden, in denen der Cluster seine Abstimmungsmehrheit verliert.

Manche Menschen finden das frustrierend, weil es sich anfühlt, als würde das System offensichtlichen Absichten während Wartungsfenstern nicht vertrauen. Aus Sicht verteilter Systeme verhält sich der Cluster aber genau so, wie er entworfen wurde, und schützt Daten vor Szenarien, die Menschen oft unterschätzen.

Die versteckten Kosten kleiner Cluster

Diese Situation beleuchtet auch eine unbequeme Eigenschaft kleiner Cluster. Ein Drei-Knoten-Cluster verträgt jeweils nur einen Ausfall, und in dem Moment, in dem zwei Knoten verschwinden, ist das Quorum weg.

Diese Einschränkung führt zu dem Ratschlag, der in solchen Gesprächen unweigerlich auftaucht: Wenn der Cluster den Verlust von zwei Knoten überstehen soll, brauchen Sie mehr Knoten. Das klingt fast wie eine Ausrede, ist mathematisch aber korrekt. Größere Cluster erhöhen die Anzahl der Ausfälle, die auftreten können, ohne den Mehrheitskonsens zu brechen.

Ein Fünf-Knoten-Cluster kann zwei Knoten verlieren und trotzdem das Quorum halten, ein Sieben-Knoten-Cluster kann drei verlieren. Mit drei Knoten gibt es schlicht keinen Spielraum.

Der Moment, in dem das Design endlich Sinn ergibt

Für Administratoren, die diesem Verhalten zum ersten Mal begegnen, wirkt das System übervorsichtig. Schließlich wissen sie genau, was sie tun, sie haben Knoten absichtlich in den Wartungsmodus versetzt, und das Szenario ist kontrolliert.

Verteilte Systeme verlassen sich allerdings auf Regeln, die chaotische Bedingungen überstehen, also kaputte Switches, Netzwerkpartitionen, abgestürzte Hosts und beschädigten Speicher, und menschliche Gewissheit zählt für sie nicht. Diese Regeln wirken bei Routinewartungen oft stur, doch sie existieren, weil irgendwer, irgendwo, einmal einen ganzen Cluster an Split Brain verloren hat.

Wenn also das nächste Mal ein Drei-Knoten-Cluster sich weigert, weiterzulaufen, nachdem zwei Knoten verschwunden sind, weigert er sich schlicht zu raten.