Proxmox 3-Node-Cluster ohne Shared Storage: ZFS-Replikation als Ersatz

Ein hochverfügbarer Proxmox-Cluster muss nicht zwangsläufig mit Ceph oder einem klassischen SAN aufgebaut werden. Für viele mittelständische Umgebungen mit zwei produktiven Hypervisoren und einer überschaubaren Anzahl virtueller Maschinen ist ein 3-Node-Cluster mit lokalem ZFS-Storage und geplanter Replikation die wirtschaftlich und betrieblich sinnvollere Lösung. Sie sparen nicht nur erhebliche Hardwarekosten, sondern reduzieren auch die Komplexität im Betrieb spürbar.

In diesem Artikel zeigen wir, wie Sie einen solchen Cluster mit Proxmox VE 8.3 sauber aufsetzen, welche RPO- und RTO-Werte realistisch sind und an welcher Stelle die Lösung gegenüber Ceph an ihre Grenzen stößt.

Warum lokaler Storage statt Ceph oder SAN

Ceph ist eine hervorragende Lösung — ab einer gewissen Größenordnung. Wer drei Nodes mit jeweils sechs OSDs, dediziertem 25-GbE-Backend und ausreichend RAM betreiben kann, erhält echten Shared Storage mit Live-Migration und sofortigem Failover. Im SMB-Umfeld mit zwei Hypervisoren, 20 bis 50 VMs und einem Backup-Fenster über Nacht ist der Overhead dieser Lösung jedoch oft nicht gerechtfertigt.

Lokaler ZFS-Storage bietet im Gegenzug:

• Volle NVMe-Performance ohne Netzwerk-Overhead
• Snapshot- und Klontechnik auf Block-Ebene
• Inline-Kompression und optional Deduplizierung
• Replikation auf Block-Ebene zwischen Nodes
• Bewährte Recovery-Werkzeuge

Der Preis dafür ist klar: Sie verlieren die “Null-RPO-Garantie” eines synchronen Shared Storage. Eine VM, die zwischen zwei Replikationsläufen ausfällt, verliert die Änderungen dieses Intervalls.

Hardware-Setup für den 3-Node-Cluster

Ein bewährtes Setup im Mittelstand sieht zwei produktive Nodes mit identischer Hardware und einen kleinen dritten Node als QDevice-Träger vor. Der dritte Node muss keine VMs hosten — er dient ausschließlich dem Quorum.

Komponente	Node 1 + 2 (Produktion)	Node 3 (QDevice)
CPU	AMD EPYC 4564P, 16 Cores	Intel N100 oder kleiner Xeon
RAM	256 GB DDR5 ECC	16 GB
Storage	4x 3,84 TB NVMe (ZFS RAID10)	1x 500 GB SSD
Netzwerk	2x 25 GbE (LACP) Corosync getrennt	2x 1 GbE
Stromversorgung	Redundant 2x 800 W	Single 250 W

Die produktiven Nodes erhalten ein dediziertes Corosync-Netzwerk auf eigenen physischen Interfaces. Dies ist nicht optional, sondern entscheidend für die Stabilität des Clusters. Wenn der Replikations-Traffic die Corosync-Pakete verzögert, kommt es zu Fencing-Events und VMs werden unnötig neu gestartet.

Cluster und QDevice einrichten

Nach der Proxmox-Installation auf allen drei Nodes legen Sie den Cluster auf Node 1 an:

# Auf Node 1
pvecm create datazone-cluster --link0 10.10.10.1 --link1 10.10.20.1

# Auf Node 2
pvecm add 10.10.10.1 --link0 10.10.10.2 --link1 10.10.20.2

# QDevice-Paket auf allen Nodes und auf Node 3 installieren
apt install corosync-qdevice

# Auf Node 3 (kein Cluster-Mitglied, nur QNet-Daemon)
apt install corosync-qnetd
systemctl enable --now corosync-qnetd

# Auf Node 1 das QDevice registrieren
pvecm qdevice setup 10.10.10.3

Die Prüfung mit pvecm status muss anschließend drei Stimmen zeigen: zwei von den produktiven Nodes und eine vom QDevice. Damit ist auch bei Ausfall eines produktiven Nodes weiterhin Quorum gegeben und der verbleibende Node kann VMs übernehmen.

ZFS-Pools und Replikation konfigurieren

Auf beiden produktiven Nodes wird ein identisch benannter ZFS-Pool angelegt. Der Name muss zwingend übereinstimmen, sonst funktioniert die Replikation nicht.

# Auf Node 1 und Node 2 identisch
zpool create -o ashift=12 -O compression=lz4 -O atime=off \
  rpool-vm mirror nvme0n1 nvme1n1 mirror nvme2n1 nvme3n1

zfs set recordsize=64k rpool-vm
zfs set sync=standard rpool-vm

Anschließend richten Sie den Storage in der Proxmox-GUI als “ZFS”-Typ unter Datacenter → Storage ein und aktivieren beide Nodes. Für jede VM, die hochverfügbar laufen soll, konfigurieren Sie unter VM → Replication einen Job auf den Partner-Node:

# CLI-Variante für VM 100 alle 15 Minuten auf Node 2
pvesr create-local-job 100-0 node2 --schedule "*/15"

Das initiale Replikat überträgt den vollständigen ZFS-Datensatz. Alle Folgeläufe übertragen nur die inkrementellen Snapshots seit dem letzten erfolgreichen Lauf. Bei typischen Office-VMs mit 100 GB Volume liegen die 15-Minuten-Deltas meist im Bereich weniger hundert Megabyte.

RPO, RTO und HA-Verhalten realistisch einschätzen

Hier liegt der entscheidende Unterschied zu Ceph oder Shared Storage. Bei einem klassischen SAN-Setup ist RPO gleich null — jeder Schreibvorgang ist auf beiden Pfaden persistiert. Bei ZFS-Replikation entspricht das RPO dem konfigurierten Replikationsintervall.

Szenario	RPO	RTO	Auswirkung
Node-Ausfall, letztes Replikat 5 min alt	~5 min	2-4 min	VM startet auf Partner mit altem Stand
Node-Ausfall, letztes Replikat 14 min alt	~14 min	2-4 min	Worst Case bei 15-min-Intervall
Geplante Wartung	0	30-60 s	Live-Migration möglich, kein Datenverlust
Ausfall QDevice (Node 3)	0	0	Cluster läuft weiter, kein VM-Impact
Ausfall beider Produktiv-Nodes	n/a	Backup-Restore	Disaster-Recovery aus PBS notwendig

Für viele SMB-Anwendungen ist ein RPO von 15 Minuten völlig akzeptabel. Für Datenbanken mit hohem Schreibvolumen sollten Sie das Intervall auf 5 oder sogar 1 Minute reduzieren — oder gezielt auf applikationsseitige Replikation (PostgreSQL-Streaming, MSSQL-AG) ausweichen.

Stolperfallen und Best Practices

Aus zahlreichen Projekten kristallisieren sich einige Themen heraus, die in der Dokumentation oft zu kurz kommen:

Corosync-Netzwerk trennen: Wenn Corosync und Replikation über dieselbe Leitung laufen, sind unter Last Fencing-Events vorprogrammiert. Mindestens VLAN-Trennung, besser physisch getrennt.

HA-Gruppen sauber definieren: Eine VM mit aktiver Replikation auf Node 2 darf bei HA-Failover nicht auf Node 3 starten — dort liegt kein Replikat. Definieren Sie HA-Gruppen explizit pro VM.

Snapshot-Hygiene: Replikations-Snapshots werden automatisch gepflegt. Manuelle Snapshots aus der GUI können die Replikation brechen, wenn sie nicht synchron auf beiden Seiten existieren.

Backup unabhängig halten: Replikation ist kein Backup. Ein versehentlich gelöschtes File wird in 15 Minuten zuverlässig auf den Partner repliziert. Ein separater Proxmox Backup Server mit Retention von 30 oder 60 Tagen ist Pflicht.

Monitoring einrichten: Replikationsjobs können scheitern — volle Pools, abgebrochene SSH-Sessions, Snapshot-Konflikte. Ein einfaches Skript, das pvesr status auswertet und in Ihre Monitoring-Lösung einspeist, verhindert böse Überraschungen.

Fazit

Ein 3-Node-Proxmox-Cluster mit ZFS-Replikation und QDevice ist für viele mittelständische IT-Umgebungen die wirtschaftlich und technisch sinnvollere Alternative zu Ceph oder einem klassischen SAN. Sie erhalten echte Hochverfügbarkeit mit überschaubarem RPO, sehr niedriger RTO und drastisch geringeren Hardwarekosten. Die Lösung skaliert sauber bis in den Bereich von 50 bis 80 VMs pro Node-Paar und lässt sich später bei Bedarf um weitere Nodes erweitern.

DATAZONE plant, baut und betreibt seit Jahren Proxmox-Cluster in genau dieser Größenordnung — inklusive sauberer Netzwerktrennung, dokumentierter Replikationsstrategie und integriertem Backup auf PBS. Wenn Sie überlegen, von VMware zu Proxmox zu migrieren oder Ihren bestehenden Cluster zu konsolidieren, sprechen Sie uns an: Wir analysieren Ihre Anforderungen und schlagen das passende Setup vor. Mehr zu unseren Leistungen finden Sie in der Proxmox-Beratung oder direkt über das Kontaktformular.