Proxmox-Cluster ohne Shared Storage aufbauen

Die verbreitete Annahme lautet: Cluster braucht gemeinsamen Speicher. Ein SAN, mindestens aber ein NAS, an dem alle Knoten hängen.

Das stimmt für Hochverfügbarkeit im Rechenzentrumssinn. Für ein Homelab und für viele Kleinbetriebe ist es die falsche Anforderung – und teuer dazu. Proxmox kann Cluster mit lokalem Speicher auf jedem Knoten, und die Lücke, die dabei bleibt, ist kleiner als erwartet.

Man muss nur wissen, welche Lücke das ist.

Was ein Cluster ohne gemeinsamen Speicher kann – und was nicht

	mit gemeinsamem Speicher	lokal + Replikation
Gemeinsame Verwaltung aller Knoten	ja	ja
Migration im laufenden Betrieb	ja	ja
Umzug ohne vorherige Kopie	ja	nein, dauert länger
Automatischer Neustart nach Ausfall	ja	ja
Datenverlust bei Knotenausfall	keiner	bis zu einem Replikationsintervall
Kosten	SAN oder NAS	zweiter Datenträgersatz

Die vorletzte Zeile ist der ganze Unterschied. Fällt ein Knoten aus, startet der Gast auf einem anderen Knoten aus der letzten Replikation. Alles, was seit dieser Replikation geschrieben wurde, ist weg.

Bei einem Intervall von einer Minute sind das im schlechtesten Fall die Änderungen einer Minute. Für einen Dienst im Homelab ist das meist unerheblich. Für eine Datenbank mit Zahlungsverkehr ist es das nicht.

Sei bei dieser Einschätzung ehrlich zu dir selbst. Und verwechsle das Ganze nicht mit einer Sicherung: Replikation kopiert auch einen Verschlüsselungstrojaner zuverlässig auf den zweiten Knoten. Warum das zwei verschiedene Dinge sind, steht in der 3-2-1-Backup-Strategie.

Voraussetzung: ZFS auf jedem Knoten

Die eingebaute Replikation von Proxmox setzt auf ZFS-Snapshots auf. Ohne ZFS als Speicherunterbau gibt es sie nicht.

Das ist der Grund, warum die Entscheidung für das Dateisystem schon bei der Installation fällt und später nur mit Neuinstallation zu ändern ist – siehe Proxmox VE im Homelab: der Einstieg.

Zweite Voraussetzung: Der ZFS-Pool muss auf allen Knoten gleich heißen. Die Replikation spricht den Zielspeicher über seinen Namen an. Unterschiedliche Namen sind ein vermeidbarer Ärger.

Quorum: warum zwei Knoten nicht genügen

Der Punkt, an dem die meisten Zwei-Knoten-Aufbauten scheitern – und zwar erst im Ernstfall.

Ein Cluster muss entscheiden können, welche Seite weiterarbeiten darf, wenn die Verbindung zwischen den Knoten abreißt. Ohne diese Entscheidung würden beide Seiten dieselben Gäste starten und dieselben Daten unabhängig voneinander verändern.

Die Entscheidung fällt per Mehrheit. Bei zwei Knoten hat nach einem Verbindungsverlust keine Seite die Mehrheit – beide sperren sich selbst, und es geht gar nichts mehr.

Die Lösung ist ein dritter Stimmberechtigter, der keine Gäste betreibt: ein QDevice. Das kann ein winziges Gerät sein, das ohnehin läuft – ein Einplatinenrechner genügt.

# Auf dem Zeugen-Gerät (nicht Teil des Clusters):
apt install corosync-qnetd

# Auf einem Cluster-Knoten:
apt install corosync-qdevice
pvecm qdevice setup <adresse-des-zeugen>
pvecm status

pvecm status muss danach drei Stimmen ausweisen. Steht dort weiterhin zwei, ist die Einrichtung nicht durchgelaufen – und der Aufbau bringt nichts.

Drei echte Knoten sind die andere Lösung und die schönere, wenn die Hardware da ist.

Das Cluster-Netz

Die Verbindung zwischen den Knoten reagiert empfindlich auf Verzögerungen. Sie stellt laufend fest, ob die anderen Knoten noch da sind, und macht das mit engen Zeitgrenzen.

Daraus folgen zwei Regeln:

• Nicht über WLAN, nicht über eine überlastete Leitung. Ein Datenstrom, der die Leitung füllt, kann dazu führen, dass sich Knoten gegenseitig für ausgefallen halten.
• Wenn möglich ein eigenes Netz für die Clusterkommunikation. Zwei Netzwerkkarten je Knoten reichen; ein einfacher Switch dazwischen genügt.

Bei mehreren Netzen trägt man beim Anlegen mehrere Verbindungen ein. Fällt die bevorzugte aus, übernimmt die zweite.

Für die Adressplanung der zusätzlichen Netze hilft der Subnetzrechner.

Cluster anlegen und beitreten

# Auf dem ersten Knoten:
pvecm create <clustername>

# Auf jedem weiteren Knoten:
pvecm add <adresse-des-ersten-knotens>

# Zur Kontrolle:
pvecm status

Zwei Dinge vorher prüfen, weil sie hinterher wehtun:

1. Der beitretende Knoten darf keine Gäste haben. Der Beitritt bricht sonst ab. Wer dort schon etwas laufen hat, sichert es weg und stellt es nach dem Beitritt wieder her – die Nummern der Gäste müssen im Cluster eindeutig sein.
2. Ein Knoten verlässt einen Cluster nicht sauber wieder. Der unterstützte Weg ist Entfernen und Neuinstallation. Behandle den Beitritt als endgültig.

Replikation einrichten

Pro Gast ein Auftrag, mit Ziel und Intervall. In der Oberfläche unter „Replication“, auf der Kommandozeile:

# VM 101 alle 15 Minuten auf knoten2 replizieren
pvesr create-local-job 101-0 knoten2 --schedule '*/15'
pvesr status

Zum Intervall: Der erste Lauf überträgt alles, jeder weitere nur die Unterschiede. Ein kurzes Intervall ist deshalb billiger, als es klingt – und es bestimmt unmittelbar, wie viel bei einem Ausfall verloren geht.

Was dabei tatsächlich anfällt, hängt von der Schreiblast des Gastes ab. Miss es, statt zu raten: Die Replikationsansicht zeigt Dauer und Umfang jedes Laufs.

Migration: was sich ändert

Mit vorhandener Replikation ist die Migration im laufenden Betrieb schnell. Der Zielknoten hat den Datenträgerinhalt schon fast vollständig; übertragen wird nur der Rest plus der Arbeitsspeicher.

Ohne Replikation geht es auch, dauert aber so lange, wie das Kopieren des gesamten Datenträgers braucht.

Container migrieren nicht im laufenden Betrieb – sie werden angehalten, verschoben und neu gestartet. Das gilt unabhängig vom Speicher und ist einer der Punkte in VM oder LXC-Container.

Praktischer Hinweis: Vor einem geplanten Wartungsfenster einmal von Hand replizieren lassen. Dann ist der Umzug eine Sache von Sekunden statt von Minuten.

Hochverfügbarkeit: erst danach

Ist der Cluster stabil und die Replikation eingerichtet, kann man Gäste in eine HA-Gruppe aufnehmen. Fällt ihr Knoten aus, startet der Cluster sie anderswo neu.

Zwei Dinge muss man dabei wissen:

Der Gast startet neu, er läuft nicht weiter. Hochverfügbarkeit heißt hier: aus dem letzten replizierten Stand hochfahren. Nicht: unterbrechungsfrei.

Ein Knoten, der das Quorum verliert, startet sich selbst neu. Das ist gewollt – so wird sichergestellt, dass ein abgehängter Knoten die Gäste nicht doppelt betreibt. Wer HA aktiviert, muss also damit rechnen, dass ein Netzproblem zu einem Neustart führt.

Genau deshalb: HA zuletzt. Erst Cluster, dann Quorum sauber, dann Replikation, dann – wenn überhaupt – HA.

Reihenfolge, die funktioniert

1. Alle Knoten mit ZFS installieren, Pools gleich benennen.
2. Cluster-Netz aufbauen, möglichst getrennt vom übrigen Verkehr.
3. Cluster anlegen, Knoten beitreten lassen.
4. Bei zwei Knoten: QDevice einrichten, pvecm status auf drei Stimmen prüfen.
5. Replikation je Gast einrichten, Intervall nach Schreiblast wählen.
6. Migration einmal von Hand durchspielen – vor dem Ernstfall.
7. Sicherung prüfen. Ein Cluster ersetzt sie nicht: Proxmox Backup Server einrichten und Restore testen.
8. Erst danach HA, und nur für Gäste, die es wirklich brauchen.

Weiter im Cluster

• Proxmox VE im Homelab: der Einstieg – warum die ZFS-Entscheidung schon bei der Installation fällt
• VM oder LXC-Container – der Migrationsunterschied
• Proxmox-Snapshots richtig nutzen – die Technik, auf der die Replikation aufsetzt
• 3-2-1-Backup-Strategie – warum Replikation keine Sicherung ist