Proxmox HA-Cluster Firewall

Hochverfügbare Firewall auf zwei Proxmox-Nodes – ohne Shared Storage.

Wer eine geschäftskritische Firewall virtualisiert, will im Ausfall keine Minuten verlieren. Klassische HA-Setups verlangen teure SAN-Infrastruktur. Mit zwei Proxmox-Servern, einem externen Quorum-Vote und ZFS-Replikation lässt sich das deutlich schlanker bauen – und genau dieses Muster setzen wir produktiv ein.

Gespräch vereinbaren Häufige Fragen

Ausgangslage
Die Firewall läuft als virtuelle Maschine. Auf genau einem Server.
Vor ein paar Jahren war das eine vernünftige Entscheidung: Die Firewall wurde virtualisiert, der Server ist solide. Dass an diesem einen Gerät inzwischen der Internetzugang, die VPN-Verbindungen und die Erreichbarkeit aller Standorte hängen, merkt man erst, wenn es ausfällt – und jemand vor Ort sein muss, bevor irgendetwas wieder geht.
Die übliche Antwort darauf ist ein Cluster mit zentralem Speicher, einem SAN. Für eine einzelne Firewall-VM ist das ein Aufwand, der in keinem Verhältnis steht.
Unser Lösungsweg
Zwei Server, ein kleiner Schiedsrichter, kein SAN.
Wir bauen den Cluster schlank: zwei identische Proxmox-Server mit lokalem ZFS-Spiegel, dazu ein kleines extern gehostetes QDevice als dritte Quorum-Stimme, die Split-Brain verhindert. Proxmox Storage Replication spiegelt die Disks der Firewall-VM in kurzen Abständen auf den zweiten Knoten. Fällt ein Knoten aus, startet die VM automatisch auf dem anderen.
Dieses Muster setzen wir selbst produktiv ein. Und wir sagen dazu, wo seine Grenzen liegen: Es schützt vor Hardware-Ausfall, nicht vor Fehlkonfiguration, gelöschten VMs oder Ransomware. Dafür planen wir ein separates Backup-Konzept mit ein.
Das Ergebnis
Ein defekter Server wird zum Wartungsfall – nicht zum Notfall.
- Fällt ein Server aus, startet die Firewall auf dem zweiten von selbst – ohne dass erst jemand ins Büro fahren muss.
- Redundanz ohne Shared Storage: weniger Kosten, weniger Komplexität, nur native Proxmox-Bordmittel.
- Updates spielen Sie ein, nachdem die VM vorab auf den passiven Knoten verschoben wurde – ohne Auswirkung auf den laufenden Betrieb.
- Sie wissen, was das Setup leistet und was nicht, und haben für den Rest ein Backup-Konzept.

Was wir abdecken

Die wichtigsten Bausteine im Überblick.

Zwei identische Nodes

Zwei Proxmox-VE-Server mit lokalem ZFS-Mirror-Pool. Identische Konfiguration, sodass jede VM auf jedem Knoten lauffähig ist.

QDevice als 3. Quorum-Vote

Ein kleines extern gehostetes System (z. B. Raspberry Pi) trägt eine Quorum-Stimme bei – verhindert Split-Brain bei Verlust einer Verbindung.

ZFS-Replikation alle 5 Min

Proxmox Storage Replication (pvesr) synchronisiert die VM-Disks im Hintergrund – ohne SAN, ohne zentrales Storage.

Hardware-Watchdog

Bei Quorum-Verlust erzwingt die Watchdog-Komponente einen Neustart – das schützt vor Split-Brain-Szenarien.

Das Fundament: Proxmox VE

Open-Source-Virtualisierung mit Cluster-Genen.

Proxmox VE ist eine deutsche Open-Source-Virtualisierungsplattform, die KVM-Virtualisierung, LXC-Container und Cluster-Management unter einer Web-Oberfläche vereint. Für uns das richtige Werkzeug, wenn Hochverfügbarkeit, transparente Lizenzierung und ZFS-Storage gefragt sind – ohne den Footprint eines Enterprise-Hypervisors.

Komplett-Stack

KVM für VMs, LXC für Container, Web-Oberfläche, Cluster-Management und Live-Migration in einem System.

Storage-Optionen

ZFS, Ceph, LVM-Thin, NFS oder iSCSI – wir wählen die Storage-Architektur passend zum Use-Case.

Hochverfügbarkeit

Eingebautes HA-Framework mit Quorum, Watchdog und automatischer VM-Migration – auch ohne SAN.

Architektur

Zwei Nodes, ein QDevice, lokale ZFS-Pools.

Zwei vollwertige Proxmox-Server bilden den Cluster, ein externes QDevice trägt die dritte Quorum-Stimme bei. Die Firewall-VM läuft auf einem Knoten und repliziert ihre Disks im 5-Minuten-Takt auf den anderen. Bei einem Ausfall sorgen Hardware-Watchdog und das HA-Framework dafür, dass die VM automatisch übernommen wird.

RPO

~ 5 Min

möglicher Datenverlust

Failover-Zeit

~ 3 Min

Watchdog + HA + Boot

Quorum

2 von 3

Node A · Node B · QDevice

Was passiert, wenn ein Knoten ausfällt?

Lösen Sie den Ausfall aus und sehen Sie dem Cluster bei der Übernahme zu.

Proxmox Node Aonline

Firewall-VMläuft

3. Stimme

3 / 3

ZFS-Replikation

alle 5 Minuten

Proxmox Node Bonline

bereit zur Übernahme

1
Node A antwortet nicht mehr
Stromausfall, Hardware-Defekt oder Kernel-Panic – der Knoten fällt aus dem Cluster.
2
Quorum bleibt bestehen
Node B und das externe QDevice halten zusammen 2 von 3 Stimmen. Der Cluster bleibt beschlussfähig.
3
Watchdog schaltet Node A ab
Der Hardware-Watchdog setzt den ausgefallenen Knoten zurück – so kann die VM nicht zweimal laufen.
4
Firewall-VM startet auf Node B
Das HA-Framework fährt die VM aus der letzten ZFS-Replikation hoch.

Vereinfachte Darstellung des Ablaufs – keine Messung und keine zugesagte Wiederanlaufzeit.

Was die Lösung leistet

Hochverfügbarkeit ohne SAN-Aufwand.

Automatische VM-Migration bei Hardware-Ausfall
Kein Shared Storage nötig – weniger Kosten, weniger Komplexität
Nutzt native Proxmox-Bordmittel (kein Exoten-Stack)
Optional: zrepl als unabhängiger zweiter Replikations-Pfad

Realistische Grenzen

Was dieses Setup nicht abdeckt.

Datenverlust bis zur letzten Replikation (RPO ~5 Min) ist möglich.
Failover-Zeit liegt typischerweise bei ~3 Min – nicht „sofort".
Kein Schutz vor Ransomware, gelöschten VMs oder Fehlkonfiguration – dafür braucht es ein separates Backup-Konzept.
Sehr hohe Last-Spitzen können bei nur einem aktiven Knoten zur Engstelle werden.

FAQ

Häufige Fragen zu Proxmox HA-Cluster.

Welche Ausfallzeit ist realistisch?

Die Failover-Zeit liegt in der Praxis bei rund 3 Minuten – Hardware-Watchdog, HA-Übernahme und VM-Boot zusammengerechnet. Für viele Firewall-Szenarien ein akzeptables Zeitfenster.

Wie groß ist der mögliche Datenverlust?

Der Recovery Point Objective (RPO) liegt bei rund 5 Minuten, weil die ZFS-Replikation in diesem Intervall läuft. Für Firewall-Konfigurationen, die selten ändern, ist das in der Regel unkritisch.

Schützt das Setup vor Ransomware oder gelöschten VMs?

Nein. Das Cluster-Setup schützt vor Hardware-Ausfall – nicht vor Fehlkonfiguration, gelöschten VMs oder Ransomware. Dafür braucht es zusätzlich ein separates Backup-Konzept, das wir gern mit einplanen.

Warum ein QDevice statt eines dritten Proxmox-Knotens?

Ein dritter vollwertiger Knoten kostet Lizenz, Hardware und Strom. Ein QDevice (etwa auf Raspberry Pi) trägt nur eine Quorum-Stimme bei und reicht für das Quorum-Modell – ein guter Kompromiss zwischen Kosten und Robustheit.

Was ist mit Updates der Firewall-VM?

Updates planen wir in Wartungsfenster ein. Die VM lässt sich vorab manuell auf den passiven Knoten verschieben, sodass Updates ohne Auswirkungen auf den laufenden Betrieb möglich sind.

Kontakt