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

Worum geht es?

Redundanz für die Firewall, ohne Enterprise-Storage-Budget.

Zwei Proxmox-Server, eine kritische Firewall-VM, kein Shared Storage – und die Anforderung, dass die VM beim Ausfall eines Knotens auf dem anderen automatisch startet. Üblicherweise braucht es dafür ein SAN-Setup. Mit lokalen ZFS-Pools, automatischer Storage-Replikation und einem externen Quorum-Device lässt sich derselbe Effekt ohne SAN-Kosten erreichen – mit ehrlich kommunizierten Grenzen.

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

Proxmox HA-Cluster Firewall unverbindlich anfragen

Sie möchten ein konkretes Angebot, eine Demo oder haben Fragen zur Migration? Schreiben Sie uns – wir melden uns in der Regel innerhalb eines Werktags.

E-Mail

office@stylite.de

Telefon

+49 (0) 6251 827550

DSGVO-konform

Hosting im eigenen RZ in Deutschland · AVV nach Art. 28 DSGVO