Proxmox Cluster Netzwerk auf OVH: vRack richtig nutzen

Proxmox auf OVH professionell betreiben? WZ-IT übernimmt Setup, Netzwerk-Design, Betrieb und Support für Ihre Proxmox-Infrastruktur. Zur Service-Seite →

Wenn Proxmox-Cluster auf Bare Metal instabil werden, ist die Ursache oft banal: Cluster-Kommunikation (Corosync), Storage-Traffic und "normaler" VM-Traffic teilen sich eine Leitung – oder laufen sogar über Public IPs. Genau dafür ist OVHcloud vRack ein starker Baustein: vRack verbindet Bare Metal, Public Cloud und Hosted Private Cloud in einem privaten Layer-2 Netzwerk, als ob alles im selben Rack/Datacenter wäre (OVHcloud Docs).

Inhaltsverzeichnis

• Welche Netze braucht ein Proxmox Setup wirklich?
• Was ist vRack in Klartext?
• vRack Use Cases für Proxmox
• Referenz-Architekturen
• Schritt-für-Schritt Vorgehen
• Validierung
• Häufige Fehler und wie du sie vermeidest
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Welche Netze braucht ein Proxmox Setup wirklich?

Proxmox funktioniert auch "alles in einem Netz". Aber gut (und HA-fähig) wird es erst, wenn du Traffic sauber trennst.

Management-Netz (GUI/SSH/API)

Admin-Zugriff, Automatisierung, Monitoring. Nicht unnötig öffentlich lassen: lieber VPN/Bastion, restriktive Firewall.

Cluster-/Corosync-Netz (separat!)

Proxmox empfiehlt ausdrücklich ein separates Netzwerk für Corosync, weil anderer Traffic Corosync stören kann (Proxmox Wiki).

Merksatz: Corosync ist der "Cluster-Herzschlag". Wenn der Herzschlag stottert, verliert der Cluster Quorum – und dann wird's ungemütlich.

Storage-Netz (optional, aber bei Ceph dringend)

Der wichtigste Satz aus der Proxmox-Doku:

"Storage communication should never be on the same network as corosync!" (Proxmox Wiki)

Das ist genau der Punkt, an dem vRack enorm hilft: Storage-/Backend-Traffic privat und getrennt führen.

Was ist vRack in Klartext?

vRack ist OVHclouds Lösung für ein isoliertes privates Netzwerk, das Public Cloud, Hosted Private Cloud und Bare Metal verbindet – als sicheres Layer-2 Netzwerk (OVHcloud Docs).

Für Proxmox heißt das konkret:

• Corosync/Cluster-Kommunikation muss nicht über Public IP laufen
• Storage/Backend kann privat bleiben
• Hybrid-Setups (Public Cloud Bastion/Monitoring + Dedicated Proxmox Nodes) werden sauber

vRack Use Cases für Proxmox

Use Case A: Proxmox Cluster auf OVH Bare Metal

• Proxmox Nodes sind Dedicated Server
• vRack liefert private L2-Konnektivität → gut für Corosync/Storage Separation

Use Case B: Hybrid – Public Cloud + Dedicated (privat)

OVH dokumentiert, wie man private Vernetzung zwischen Public Cloud Instance und Dedicated Server über vRack konfiguriert (OVHcloud Support).

Das ist perfekt für:

• Bastion/Jump Host (Public Cloud) → Zugriff auf private Proxmox-IPs
• Monitoring/Automation in der Public Cloud
• "Public nur dort, wo nötig"

Für Details zur Umsetzung: Proxmox auf OVH Service-Seite.

Use Case C: Single Node auf Bare Metal

Single Node braucht kein vRack "zwingend" – aber wenn du Backups/Storage/Monitoring privat führen willst (oder später skalieren), ist vRack trotzdem sinnvoll.

Referenz-Architekturen

Drei Patterns, die in Projekten funktionieren – abhängig von Budget und Verfügbarkeitsziel. Alle drei setzen wir regelmäßig für Kunden um (→ Service-Seite).

Pattern A: Single Node (Dedicated)

Für wen: Kleine bis mittlere Setups, Kostenfokus, "erstmal loslegen".

Netze:

• Management (gesichert)
• Optional: Backend (Backups/Monitoring privat)

Warum das okay ist: Proxmox kann Single Node. Die Stabilität kommt über Betrieb: Backups, Restore-Tests, Monitoring, Update-Prozess.

Wichtig: Single Node ≠ HA. Es braucht einen Plan, wie bei Hardwareausfall wieder hochgefahren wird (RTO). Wir helfen bei der Planung und Umsetzung.

Pattern B: 3-Node Cluster (der "Standard" für ernsthafte HA)

Für wen: Echtes Failover, Wartung ohne Downtime, Resilienz.

Netze:

• Management-Netz (sicher)
• Corosync/Cluster-Netz (separat!) (Proxmox Wiki)
• Storage-Netz (wenn Ceph / storage-intensiv) – niemals mit Corosync teilen!

Optional: Redundanz fürs Cluster-Netz (zweiter Ring) – empfohlen über zwei physisch getrennte Netze (RRP).

Pattern C: Hybrid – Cloud Bastion/Tools + Dedicated Proxmox Cluster via vRack

Für wen: Teams, die Cloud-Komfort (Bastion, Monitoring, CI, VPN) wollen, aber Workloads auf Bare Metal betreiben.

Netze:

• Public Cloud: Bastion/Monitoring/Automation
• Dedicated: Proxmox Nodes/Workloads
• Verbindung privat via vRack (OVHcloud Support)

Vorteil: Proxmox GUI/SSH komplett über private IPs erreichbar (über Bastion/VPN), statt öffentlich exponiert.

Schritt-für-Schritt Vorgehen

Schritt 1: IP-Plan + Namensschema (vorher!)

• Subnetze: Mgmt / Corosync / Storage
• IP-Ranges: nicht zu klein planen
• Entscheiden: Welche Ports/Services sind überhaupt öffentlich?

Schritt 2: vRack aktivieren & Dedicated Server einbinden

OVH bietet dafür eigene Support-Guides: "Configuring the vRack on your Dedicated Servers" (OVHcloud Support).

vRack wird als "virtual rack" beschrieben, mit dem Server gruppiert und an einen virtuellen Switch im privaten Netz gehängt werden.

Auf dem Node erhält das vRack-Interface anschließend eine private Bridge in /etc/network/interfaces (Syntax gemäß Proxmox Doku):

auto vmbr1
iface vmbr1 inet static
        address 10.10.20.11/24
        bridge-ports eno2
        bridge-stp off
        bridge-fd 0

Schritt 3: Optional: Public Cloud Instance ins vRack hängen

Wenn du Hybrid willst: OVH erklärt das in Guides wie "Configuring vRack for Public Cloud" (OVHcloud Support).

Schritt 4: Proxmox: Corosync explizit auf das Cluster-Netz binden

Bei der Cluster-Erstellung (oder nachträglich) sicherstellen, dass Corosync nicht über das "fette" VM-Netz läuft. Proxmox empfiehlt das ausdrücklich (Proxmox Wiki).

Konkret binden Sie Corosync bei der Cluster-Erstellung an die private(n) IP(s); ein zweiter Link liefert Redundanz (Proxmox Doku):

# Node 1:
pvecm create CLUSTERNAME --link0 10.10.20.11 --link1 10.10.30.11
# Node 2 (Join):
pvecm add 10.10.20.11 --link0 10.10.20.12 --link1 10.10.30.12

Pro-Tipp: Plant außerdem, wo Migration-Traffic laufen soll – standardmäßig nutzt Proxmox oft das Cluster-Netz, was nicht ideal ist (Proxmox Forum).

Unsicher bei der Zuordnung? Wir beraten dich.

Schritt 5: Storage-Traffic getrennt halten (bei Ceph Pflicht)

Storage nie im Corosync-Netz (Proxmox Wiki). Bei Ceph/Storage-Recovery kann es sonst passieren, dass Corosync "untergeht".

Validierung

Nach dem Aufbau (vor Produktiv):

• Corosync bleibt stabil unter Last (kein Packetloss/Spikes)?
• Storage-Recovery/Backfill beeinflusst Corosync nicht merkbar?
• Migration läuft über ein Netz, das Bandbreite verträgt (nicht über Corosync)?
• Admin-Zugriffe laufen über Bastion/VPN, nicht offen ins Internet?

Quorum- und Link-Status prüfen Sie mit:

pvecm status

Häufige Fehler und wie du sie vermeidest

Fehler 1: Corosync + Storage im selben Netz

Proxmox sagt: nicht machen (Proxmox Wiki).

Fix: Storage-Netz separieren. Corosync bekommt "ruhige" Leitung.

Fehler 2: Cluster läuft über Public IP

Funktioniert – bis es nicht mehr funktioniert. vRack ist genau dafür da, Traffic privat zu halten.

Fix: vRack nutzen für private Cluster-Kommunikation.

Fehler 3: Hybrid ohne vRack

Dann wird aus "private" am Ende "WireGuard plus NAT plus Bauchschmerzen".

Fix: vRack nutzen für saubere Cloud ↔ Dedicated Kopplung (OVHcloud Support).

Fehler 4: Migration-Traffic killt Corosync

Proxmox nutzt per Default oft das Cluster-Netz für Migration – das kann problematisch sein (Proxmox Forum).

Fix: Migration auf ein separates Netz mit ausreichend Bandbreite legen.

Fehler 5: Management UI öffentlich erreichbar

Unnötiges Risiko.

Fix: Bastion/VPN + restriktive Firewall, Management nur aus privaten Netzen.

Unser Vorgehen bei WZ-IT

Bei Proxmox auf OVH gehen wir so vor:

1. Anforderungsanalyse: Single Node vs. Cluster, HA-Ziele, Storage-Anforderungen
2. Netzwerk-Design: IP-Plan, vRack-Topologie, VLAN-Struktur
3. Setup: vRack, Dedicated/Cloud Anbindung, Proxmox Installation mit sauberer Interface-Zuordnung
4. Härtung: Management absichern, Firewall, Bastion/VPN
5. Validierung: Corosync-Stabilität, Failover-Tests, Monitoring
6. Dokumentation: Netzwerkplan, Runbooks, Eskalationspfade

Wir übernehmen das komplette Setup oder auditieren bestehende Infrastrukturen.

Zur Service-Seite: Proxmox auf OVH →

Weiterführende Guides

• Proxmox Übersicht
• Proxmox Wartung & Support
• VMware zu Proxmox Migration
• Proxmox auf Hetzner