Proxmox VE + NetApp SnapMirror: DR ohne MetroCluster

MetroCluster macht, was es verspricht – synchrone Spiegelung, automatisches Failover, RPO=0, RTO nahe Null. Dass dafür FC-Infrastruktur zwischen den Standorten, dedizierte ISL-Links, Tiebreaker-Nodes und eine Lizenz fällig werden, die bei vielen Mittelständlern das Jahresbudget der Storage-Abteilung sprengt, steht auf einem anderen Blatt.

Die Frage, die wir in der Praxis häufiger hören: Was brauchen wir wirklich – und was glauben wir nur zu brauchen?

Die ehrliche Anforderungsanalyse

Die meisten Workloads im Mittelstand vertragen einen RPO von wenigen Minuten. Wer ehrlich priorisiert, landet oft bei einer Handvoll VMs, die tatsächlich RPO=0 rechtfertigen – und einem großen Rest, für den asynchrone Replikation im 5- bis 15-Minuten-Intervall völlig ausreicht. Genau hier setzt das Setup an.

Architektur in drei Sätzen

Zwei eigenständige Proxmox-VE-Cluster, je einer pro Standort. Jeder Cluster nutzt den lokalen NetApp-Storage via iSCSI mit Multipathing (ALUA, vier Pfade pro LUN, dedizierte iSCSI-VLANs). Zwischen den NetApp-Systemen repliziert SnapMirror die relevanten Volumes – asynchron für den Großteil, synchron (SM-S) für die wenigen Workloads, die RPO=0 tatsächlich brauchen.

Was diese Architektur vom MetroCluster unterscheidet

Der zentrale Unterschied ist nicht der RPO – SnapMirror Synchronous liefert RPO=0 genauso wie MetroCluster. Der Unterschied ist das Failover-Verhalten: MetroCluster schwenkt automatisch, SnapMirror erfordert einen aktiven Eingriff. Konkret: SnapMirror-Relationship breaken, Destination-Volume mounten, LUNs mappen, VMs am DR-Standort starten. Mit einem getesteten Runbook sind das 5–15 Minuten.

Wer mit dieser RTO leben kann, spart sich die gesamte MetroCluster-Infrastruktur.

Wo die Kostenersparnis liegt

Kein MetroCluster heißt: keine FC-Switches zwischen den Standorten, keine dedizierten Backend-Verbindungen, kein Tiebreaker-Setup, keine MetroCluster-Lizenz. SnapMirror ist in den meisten ONTAP-Bundles enthalten. Proxmox VE ersetzt VMware durch ein Open-Source-Modell mit optionalem Enterprise-Support. Die iSCSI-Anbindung läuft über vorhandene Ethernet-Infrastruktur.

In Projekten, die wir so umgesetzt haben, lag die Gesamtersparnis gegenüber MetroCluster mit VMware typischerweise bei 60–75 % der laufenden Lizenz- und Infrastrukturkosten.

Was man beachten muss

iSCSI-Multipathing funktioniert unter Proxmox stabil, wenn das Netzwerk-Design stimmt: dedizierte VLANs, Jumbo Frames durchgängig, kein iSCSI über shared Infrastruktur.

SnapMirror Synchronous verlangt unter 10 ms RTT zwischen den Controllern. Für typische Dual-RZ-Szenarien im Mittelstand (10–30 km) passt das.

Proxmox-HA funktioniert zuverlässig innerhalb eines Standorts. Einen Cluster über zwei RZs strecken empfehlen wir nicht – Corosync ist latenzempfindlich, ein instabiles Quorum ist schlimmer als ein sauberer manueller Schwenk.

DR-Tests quartalsweise, dokumentiert, mit dem ganzen Team. Ein Runbook, das nie unter Stress getestet wurde, ist Wunschdenken.

Einordnung

Diese Architektur ersetzt MetroCluster nicht – sie macht es in vielen Fällen überflüssig. Die Kombination aus Proxmox VE, iSCSI-Multipathing und SnapMirror deckt DR-Anforderungen von RPO=15 min bis RPO=0 ab. Was bleibt, ist ein manueller Failover-Prozess – beherrschbar, testbar, transparent.

Für Umgebungen, in denen automatisches Failover kein hartes Kriterium ist, ist das die wirtschaftlich sinnvollere Architektur.

‍