Virtualisierung & Proxmox

Proxmox-Cluster aufbauen: Quorum, Ceph und HA ohne böse Überraschungen

Über deine Verfügbarkeit entscheidet nicht der Hypervisor, sondern das Cluster-Design darunter. Drei Nodes für ein stabiles Quorum, getrenntes Netz für Corosync und ein Ceph-Layout, das einen Node-Ausfall aushält, sind die Mindestausstattung.

Zwei Administratoren planen im Serverraum eine Migration
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum Proxmox-Cluster im Alltag scheitern

Ein Proxmox-Cluster ist schnell erzeugt. Mit pvecm create und pvecm add stehen drei Nodes in wenigen Minuten, das Web-Interface zeigt alle Hosts grün, und die erste Live-Migration läuft auf Anhieb. Die Probleme kommen später, meist beim ersten ungeplanten Ausfall oder beim ersten Wartungsfenster mit Reboot. Dann stellt sich heraus, dass das Cluster zwar zusammensteht, aber nie für den Fehlerfall ausgelegt wurde.

Die Klassiker wiederholen sich: Ein Zwei-Node-Cluster ohne QDevice verliert beim Ausfall eines Hosts das Quorum, der verbleibende Node setzt sich read-only und startet keine VM mehr. Corosync läuft über dieselbe Leitung wie Migrations- und Backup-Traffic, sodass ein voller Link Latenzspitzen erzeugt und Nodes sich gegenseitig als tot markieren. Oder HA ist aktiviert, die VM-Disks liegen aber auf lokalem LVM-Thin, womit ein Failover technisch gar nicht möglich ist und der HA-Manager die Maschine nur endlos neu zu starten versucht.

Dazu kommen Betriebsdetails, die erst unter Last auffallen. Ceph mit drei Nodes und der Default-Regel size=3, min_size=2 verträgt genau einen Ausfall, und wer beim Wartungs-Reboot den noout-Flag vergisst, löst ein unnötiges Rebalancing über das Produktivnetz aus. Fencing über den Proxmox-Watchdog funktioniert nur, wenn der HA-Stack konsistent konfiguriert ist. Und CPU-Modelle wie host statt x86-64-v2-AES verhindern die Live-Migration auf Hardware anderer Generation. Das sind alles keine exotischen Fälle, sondern die Standardstolpersteine der ersten Betriebsmonate.

Miniatur-Szene: ein physischer Server links, virtuelle Maschinen als schwebende Würfel rechts, dazwischen eine Brücke

Sechs Schritte zum belastbaren Cluster

  1. 01 Netz trennen
  2. 02 Nodes und Quorum
  3. 03 Shared Storage
  4. 04 HA-Gruppen
  5. 05 Fencing testen
  6. 06 Backup und Restore
Was du mitnimmst

So planst du ein Cluster, das den Ausfall auch übersteht

Ein belastbares Proxmox-Cluster entsteht aus wenigen, aber konsequenten Entscheidungen zu Netz, Quorum und Storage. Die folgenden Punkte sind die Reihenfolge, in der du sie treffen solltest, bevor die erste produktive VM darauf läuft.

Netz zuerst, Cluster danach

Corosync bekommt ein eigenes, möglichst redundantes Netz mit niedriger Latenz. Über den zweiten Ring, konfiguriert als link1 in der corosync.conf, hast du einen Ausweichpfad, wenn ein Switch oder ein Uplink ausfällt. Migration, Backup und Ceph-Replikation gehören auf getrennte Interfaces, sonst bestimmt der Backup-Job die Stabilität der Cluster-Kommunikation.

Quorum ehrlich rechnen

Drei Nodes sind das sinnvolle Minimum, weil ein Ausfall dann noch zwei von drei Stimmen übrig lässt. Wenn du aus Budgetgründen bei zwei Hosts bleibst, brauchst du ein QDevice auf einem dritten, kleinen System als Tiebreaker. Von manuell gesetzten expected votes solltest du die Finger lassen, das verschiebt das Problem nur in Richtung Split-Brain.

Shared Storage passend zur Größe wählen

HA und Live-Migration ohne Downtime brauchen Speicher, den alle Nodes sehen. Ceph ist die integrierte Variante und lohnt sich ab drei Nodes mit ausreichend OSDs und dediziertem Netz. Bestehendes SAN über iSCSI oder Fibre Channel mit LVM darüber ist genauso legitim, und ZFS mit Replikation ist eine Option, wenn du einen Datenverlust im Minutenbereich akzeptieren kannst.

HA-Gruppen und Fencing bewusst konfigurieren

Lege HA-Gruppen mit Prioritäten fest, damit klar ist, wo eine VM bevorzugt läuft und wohin sie im Fehlerfall wandert. Der Watchdog fenced einen Node, der das Quorum verliert, hart. Teste das, indem du im Wartungsfenster gezielt einen Host vom Netz nimmst, statt darauf zu vertrauen, dass es im Ernstfall passt.

Wartung als eigenen Prozess definieren

Für Updates und Reboots brauchst du eine feste Reihenfolge: Node in den Ceph-Maintenance-Modus mit noout, VMs per Live-Migration abziehen, patchen, Health prüfen, erst dann den nächsten Host anfassen. Mit einer solchen Routine bleiben Kernel-Updates unspektakulär.

Backup und Restore mitdenken

Ein Cluster ersetzt kein Backup. Der Proxmox Backup Server mit Deduplizierung und geprüften Restores gehört von Anfang an dazu, und der Restore-Test ist Teil der Inbetriebnahme, nicht eine Aufgabe für später.

Gut zu wissen

Häufige Fragen zu Hochverfügbarkeit mit Proxmox

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Wie viele Nodes braucht ein Proxmox-Cluster mindestens?
Technisch genügen zwei Nodes, sinnvoll für Hochverfügbarkeit sind drei. Bei drei Hosts bleibt nach einem Ausfall mit zwei von drei Stimmen das Quorum erhalten, bei zwei Hosts brauchst du ein QDevice auf einem dritten System, sonst blockiert der überlebende Node.
Was passiert, wenn ein Proxmox-Cluster das Quorum verliert?
Ohne Quorum schaltet das Cluster-Dateisystem pmxcfs unter /etc/pve in den Nur-Lese-Modus. Du kannst dann keine VMs mehr starten oder Konfigurationen ändern, und bei aktivem HA fenced der Watchdog den betroffenen Node nach kurzer Zeit hart.
Brauche ich Ceph für Proxmox HA?
Nein, du brauchst gemeinsam erreichbaren Speicher, und Ceph ist nur eine mögliche Umsetzung davon. Ein SAN über iSCSI oder Fibre Channel mit LVM funktioniert ebenso. Ceph ist attraktiv, weil es ohne externes Storage-System auskommt, verlangt dafür aber ein eigenes Netz und genügend OSDs pro Node.
Warum schlägt die Live-Migration zwischen meinen Nodes fehl?
Meist liegt es am CPU-Typ oder am Storage. Steht der VM-Prozessor auf host, muss die Ziel-CPU die gleichen Flags bieten, sonst hilft ein gemeinsamer Typ wie x86-64-v2-AES. Liegt die Disk auf lokalem Speicher, ist nur eine Migration mit Datenkopie möglich, nicht die unterbrechungsfreie Variante.
Wie aktualisiere ich ein Proxmox-Cluster ohne Ausfall?
Node für Node und nie parallel. Setze bei Ceph vorher das noout-Flag, migriere die VMs auf die anderen Hosts, aktualisiere und starte neu, prüfe Cluster- und Ceph-Status und nimm dir erst danach den nächsten Node vor.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Rückmeldung aus dem Kurs „SELinux Training: Grundlagen und Administration (SEL1)“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Cluster-Design gemeinsam durchgehen

Im Proxmox Aufbaukurs zu Cluster, Ceph und High Availability baust du die hier beschriebene Umgebung selbst auf, provozierst Node-Ausfälle im Labor und siehst, wie sich Quorum, Fencing und Ceph dabei verhalten. Wenn dir noch die Basis fehlt, fängst du mit dem Proxmox Grundkurs zu KVM, LXC, Storage und Backup an, und wer gerade von VMware kommt, findet im Kurs zur Migration von VMware zu Proxmox den passenden Einstieg. Alle Termine gibt es als Präsenz- und Live-Online-Schulung, auf Wunsch auch als Inhouse-Training auf deiner eigenen Hardware. Sprich uns an, dann klären wir vorab, welche Variante zu deiner Umgebung passt.