„Ihr Zwei-Node-Cluster ist eine Falle“: Die brutale Wahrheit über Proxmox-Quorum, die niemand erklärt

Die Begeisterungsphase: „Ich habe einen Cluster gebaut—was jetzt?“

Es gibt einen Moment, in dem alles einrastet. Sie haben zwei Maschinen, ordentliche Specs, vielleicht ein NUC gepaart mit einer etwas kräftigeren Kiste, und plötzlich haben Sie einen Cluster gebaut. Es fühlt sich an wie ein Levelaufstieg. Nicht mehr nur VMs betreiben—Sie orchestrieren Infrastruktur.

Diese Begeisterung ist echt. Sie beginnen, über Best Practices, Redundanz, vielleicht sogar High Availability nachzudenken. Sie kennen die Regel bereits: Drei Nodes sind ideal. Aber zwei fühlen sich nah genug an, oder?

Dort beginnt die Illusion.

Denn was wie ein Cluster aussieht... verhält sich noch nicht wirklich wie einer.

Die erste Warnung: „Sie brauchen einen dritten Node. Ernsthaft.“

Die unmittelbarste Antwort schneidet durch alles: Sie brauchen einen dritten Node, um Split Brain zu vermeiden.

Das klingt zunächst nach Übertreibung. Sie haben zwei Maschinen—warum reicht das nicht? Aber beim Clustering geht es nicht darum, mehrere Maschinen zu haben. Es geht um Konsens.

In Proxmox entscheidet Quorum, ob der Cluster funktionieren darf. Und Quorum erfordert eine Mehrheit. Mit zwei Nodes gibt es keine Mehrheit, wenn einer ausfällt. Es gibt nur... Uneinigkeit.

Ein Nutzer verstärkt das noch: eine dritte Stimme—oft über ein QDevice—ist „im Grunde erforderlich“.

Nicht optional. Kein Nice-to-have. Erforderlich.

Das ist der Moment, in dem die Begeisterung in Vorsicht umschlägt.

Das Sperrszenario: Wenn ein Node ausfällt und alles stehen bleibt

Hier kommt der Teil, den die meisten Leute nicht erwarten.

Wenn Sie einen Zwei-Node-Cluster betreiben und ein Node offline geht—selbst für etwas Harmloses wie einen Neustart—kann der andere Node Sie komplett aussperren. Weil er kein Quorum herstellen kann.

Denken Sie kurz darüber nach.

Ihr „Cluster“ wird unbenutzbar... weil eine Maschine neu gestartet hat.

Das ist kein Bug. Das ist das System, das genau das tut, wofür es entworfen wurde: Split Brain zu verhindern, bei dem zwei Nodes unabhängig agieren und den gemeinsamen Zustand korrumpieren.

Aber in einem Homelab fühlt sich das brutal an. Sie denken nicht an verteilten Konsens—Sie versuchen nur, den Laden am Laufen zu halten.

Und plötzlich arbeitet das System gegen Sie.

Der Workaround: QDevice und der „fake dritte Node“

Hier kommt der clevere Workaround ins Spiel: ein QDevice.

Statt einen vollständigen dritten Server hinzuzufügen, können Sie eine leichtgewichtige Stimme hinzufügen—etwas, das am Quorum teilnimmt, ohne Workloads zu betreiben. Es ist kein vollständiger Node, aber es kippt das Gleichgewicht.

Deshalb erwähnt jemand beiläufig, vergessen zu haben, „mein qdevice neu einzurichten“, als wäre es ein kritischer Bestandteil des Setups.

Denn das ist es.

Mit einem QDevice wird Ihr Zwei-Node-Cluster funktional stabil. Ohne es sind Sie immer nur einen Neustart von Verwirrung entfernt.

Es ist der kleinste Fix mit der größten Wirkung—und irgendwie ist es derjenige, von dem die meisten Leute zu spät erfahren.

Der magische Moment: „Moment... ich kann laufende VMs verschieben?“

Trotz all der Warnungen gibt es einen Grund, warum Leute beim Clustering bleiben.

Denn wenn es funktioniert, fühlt es sich unglaublich an.

Live-Migration ist das Feature, das alles dreht. Eine laufende VM ohne Downtime von einem Node auf einen anderen zu verschieben, fühlt sich an wie Schummeln. Ein Nutzer beschrieb es als „wirklich magisch“, sobald man Workloads von Hardware entkoppelt.

Ein anderer sagt es geradeheraus: „Es wird Sie umhauen.“

Und sie übertreiben nicht.

Das ist der Moment, in dem Ihr Homelab aufhört, sich wie eine Ansammlung von Maschinen anzufühlen, und beginnt, sich wie eine Plattform anzufühlen.

Die Realitätsprüfung: „Brauchen Sie überhaupt einen Cluster?“

Dann kommt die unbequeme Frage.

Brauchen Sie das überhaupt?

Eine Perspektive holt die Sache zurück auf den Boden: Für die meisten Leute geht es bei Clustern im Homelab ums Lernen, nicht um Notwendigkeit. Echte High-Availability-Setups—Ceph, HA, Zero-Downtime-Upgrades—sind mächtig, fügen aber auch schnell Komplexität hinzu.

Ein anderer Nutzer deutet eine Alternative an: mehrere eigenständige Hosts ohne Clustering zu verwalten, besonders wenn manche Nodes nicht immer online sind.

Das ist die Kluft:

• Cluster für Erfahrung und fortgeschrittene Features
• Eigenständige Setups für Einfachheit und Zuverlässigkeit

Und je nach Ihren Zielen ergibt das eine deutlich mehr Sinn als das andere.

Die versteckte Einschränkung: Ihr schwächster Node definiert alles

Es gibt noch ein weiteres subtiles Detail, das Leute überrascht: Ihr Cluster ist nur so flexibel wie seine schwächste Hardware.

Ein Kommentar weist darauf hin, dass die älteste CPU in Ihrem Cluster bestimmt, was wohin migrieren kann.

Das bedeutet, Ihr glänzender neuer Node schaltet keine neuen Fähigkeiten frei, wenn Ihr älterer Node sie nicht unterstützen kann. Migrationskompatibilität wird zu einem Problem des kleinsten gemeinsamen Nenners.

Es ist kein Dealbreaker. Aber es ist eine weitere Erinnerung daran, dass es bei Clustern nicht nur darum geht, Maschinen hinzuzufügen—sondern sie aufeinander abzustimmen.

Die größere Wahrheit: Cluster lösen Probleme, die Sie vielleicht noch gar nicht haben

Was diese ganze Situation so interessant macht, ist, wie schnell Leute ins Clustering einsteigen—und wie langsam ihnen klar wird, wofür es eigentlich gut ist.

Cluster glänzen, wenn Sie brauchen:

• High Availability
• Nahtloses Failover
• Wartung ohne Downtime

Aber wenn Sie nur ein paar Dienste betreiben, überwiegen diese Vorteile die zusätzliche Komplexität vielleicht nicht.

Und das ist die stille Wahrheit, die sich durch das alles zieht: Ein Zwei-Node-Cluster fühlt sich wie Fortschritt an, aber ohne Quorum ist er zerbrechlich. Fügen Sie eine dritte Stimme hinzu, und er wird stabil. Fügen Sie Shared Storage und HA hinzu, und er wird mächtig.

Aber bis dahin?

Ist es eine Lernerfahrung, getarnt als Infrastruktur.

Und vielleicht ist genau das, was es sein soll.