0800 71 20000
Kontakt
...
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.

4 Kapitel mit allen Befehlen
Passende Kurse ansehen Persönlich beraten lassen
Zwei Administratoren planen im Serverraum eine Migration
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
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
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

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.

Tutorial

Cluster aufbauen, der einen Ausfall wirklich übersteht

Ein Proxmox-Cluster ist schnell zusammengeklickt. Ob er einen Node-Ausfall übersteht, entscheidet sich an drei Stellen: Quorum, Netztrennung und Storage-Layout. Dieser Teil geht sie in der Reihenfolge durch, in der sie beim Aufbau anfallen.

01

Quorum: warum drei Nodes das Minimum sind

Ein Cluster trifft Entscheidungen per Mehrheit. Bei zwei Nodes gibt es keine Mehrheit, sobald einer ausfällt, und der verbleibende darf nichts mehr tun.

Ausfalltoleranz nach Node-Zahl

NodesQuorum nötigVerkraftet Ausfall vonBewertung
220ungeeignet ohne QDevice
321Minimum für HA
431kein Gewinn gegenüber 3
532empfohlen ab mittlerer Größe
Cluster anlegen und Zustand prüfen
# Auf dem ersten Node
pvecm create meincluster --link0 10.0.20.11

# Auf den weiteren Nodes
pvecm add 10.0.20.11 --link0 10.0.20.12

# Zustand ansehen: Quorate muss 'Yes' sein
pvecm status
pvecm nodes
corosync-quorumtool -s

Bei genau zwei Nodes brauchst du ein QDevice als Schiedsrichter: ein kleiner dritter Rechner, der nur eine Stimme beisteuert. pvecm qdevice setup 10.0.20.99 richtet es ein.

02

Netze trennen

Corosync reagiert empfindlich auf Latenz. Läuft es über dieselbe Leitung wie Backups oder Storage-Verkehr, kommt es unter Last zu Aussetzern und im schlimmsten Fall zum ungewollten Ausschluss eines Nodes.

Empfohlene Trennung

NetzZweckAnforderung
CorosyncCluster-Kommunikationeigenes VLAN oder eigene Karte, Latenz unter 5 ms, sehr wenig Verkehr
Storage (Ceph)Replikation zwischen Nodes10 GbE aufwärts, eigenes Netz
VM-VerkehrNutzdaten der Gästenach Bedarf, getrennt von Corosync
VerwaltungWeboberfläche, SSHgetrennt, nur intern erreichbar
Zweiten Corosync-Ring nachrüsten
# Redundanz für die Cluster-Kommunikation
pvecm status                      # aktuelle Links ansehen

# /etc/pve/corosync.conf bearbeiten, je Node ergänzen:
#   ring1_addr: 10.0.21.11
# und im totem-Abschnitt:
#   interface { linknumber: 1 }

# WICHTIG: config_version hochzählen, sonst wird nichts übernommen

# Nach dem Speichern prüfen
corosync-cfgtool -s

Bearbeite corosync.conf immer über /etc/pve/, damit die Änderung auf alle Nodes verteilt wird. Ein Fehler hier legt den Cluster still, also vorher eine Kopie sichern.

03

Storage: Ceph oder ZFS-Replikation

Für echte Hochverfügbarkeit braucht eine VM ihren Speicher auf mehreren Nodes. Dafür gibt es zwei Wege mit sehr unterschiedlichen Anforderungen.

Die zwei Ansätze

CephZFS-Replikation
Datenverlust bei Ausfallkeiner, synchronbis zum letzten Replikationslauf (z.B. 15 Min)
Mindest-Nodes3, besser 52
Netzanforderung10 GbE Pflicht1 GbE genügt
Komplexitäthochgering
Passt fürechte HA, größere Clusterkleine Umgebungen, kurze Ausfälle akzeptabel
ZFS-Replikation einrichten
# Auf beiden Nodes gleichnamiger Pool, hier 'rpool/data'
# Replikationsjob für eine VM, alle 15 Minuten
pvesr create-local-job 100-0 node2 --schedule '*/15'

pvesr status
pvesr list

Der Pool muss auf beiden Nodes exakt gleich heißen, sonst schlägt die Replikation fehl. Bei einem Ausfall verlierst du maximal die Änderungen seit dem letzten Lauf.

Ceph in Kürze
pveceph install
pveceph init --network 10.0.22.0/24
pveceph mon create
pveceph osd create /dev/nvme0n1

# Pool mit dreifacher Replikation
pveceph pool create vmdaten --size 3 --min_size 2

ceph -s          # HEALTH_OK anstreben
ceph osd df tree

min_size 2 bedeutet: Schreibvorgänge sind nur möglich, solange zwei Kopien erreichbar sind. Auf min_size 1 zu gehen wirkt verlockend, riskiert aber Datenverlust bei einem weiteren Ausfall.

04

HA aktivieren und Fencing verstehen

Erst mit HA-Gruppen startet Proxmox eine VM nach einem Node-Ausfall selbsttätig neu. Voraussetzung ist, dass der Cluster sicher weiß, dass der Node wirklich weg ist.

HA einrichten
# Gruppe mit Vorrang je Node
ha-manager groupadd produktiv --nodes "node1:2,node2:1,node3:1"

# VM unter HA-Verwaltung stellen
ha-manager add vm:100 --group produktiv --max_restart 3 --max_relocate 2

ha-manager status
ha-manager config

Die Zahl hinter dem Node ist die Priorität. Kommt node1 zurück, wandert die VM dorthin zurück, sofern nicht nofailback gesetzt ist.

Der entscheidende Mechanismus heißt Fencing. Bevor eine VM woanders gestartet wird, muss sichergestellt sein, dass sie auf dem alten Node nicht mehr läuft, sonst schreiben zwei Instanzen auf dieselben Daten. Proxmox löst das über einen Watchdog: Ein Node, der das Quorum verliert, startet sich nach etwa 60 Sekunden selbst neu. Deshalb dauert ein Failover auch immer mindestens diese Zeit.

Passende Kurse

Kurse zu Hochverfügbarkeit mit Proxmox bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

Proxmox Aufbaukurs: Cluster, Ceph & High Availability 2 Tage Präsenz nächster Termin 10.09.2026 Zum Kurs Proxmox Grundkurs: KVM, LXC, Storage und Backup 3 Tage Präsenz nächster Termin 21.09.2026 Garantietermin Zum Kurs Migration von VMware zu Proxmox 3 Tage Präsenz oder Live-Online nächster Termin 21.09.2026 Garantietermin Zum Kurs Linux Storage und Dateisysteme (STOR) 3 Tage Präsenz nächster Termin 28.09.2026 Zum Kurs
Unverbindlich beraten lassen Alle Proxmox-Kurse ansehen
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.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick
Virtualisierung & Proxmox VMware-Alternativen: So findest du die Plattform, die zu deiner IT passt Ansehen Virtualisierung & Proxmox Von VMware zu Proxmox migrieren: der Weg, den deine VMs wirklich gehen Ansehen Virtualisierung & Proxmox Ceph Storage einrichten: So planst du einen Cluster, der deine Virtualisierung trägt Ansehen DevOps & Automatisierung Ansible Einstieg für Admins: von der Handarbeit zum reproduzierbaren Playbook Ansehen
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.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

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

0800 71 20000 E-Mail
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.

Beratung anfragen 0800 71 20000