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.
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).
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?
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:
- Anforderungsanalyse: Single Node vs. Cluster, HA-Ziele, Storage-Anforderungen
- Netzwerk-Design: IP-Plan, vRack-Topologie, VLAN-Struktur
- Setup: vRack, Dedicated/Cloud Anbindung, Proxmox Installation mit sauberer Interface-Zuordnung
- Härtung: Management absichern, Firewall, Bastion/VPN
- Validierung: Corosync-Stabilität, Failover-Tests, Monitoring
- Dokumentation: Netzwerkplan, Runbooks, Eskalationspfade
Wir übernehmen das komplette Setup oder auditieren bestehende Infrastrukturen.
Zur Service-Seite: Proxmox auf OVH →
Weiterführende Guides
Häufig gestellte Fragen
Antworten auf wichtige Fragen zu diesem Thema
Ein privates Layer-2 Netzwerk, das OVH-Produkte (Public Cloud, Private Cloud, Bare Metal) verbindet – als ob alles im selben Rack wäre.
Nicht zwingend. Aber sinnvoll, wenn du Backups/Monitoring/Backend privat halten willst oder später auf Cluster wachsen möchtest.
Ja, OVH hat dafür konkrete Guides (Public Cloud ↔ Dedicated via vRack).
Weil anderer Traffic Corosync stören kann – Proxmox empfiehlt ein separates Corosync-Netz.
Nein. Proxmox sagt explizit: Storage niemals im Corosync-Netz.
Für robustes Quorum/HA ist 3+ der Standard; 2 Nodes sind möglich, aber operativ heikler.
OVH beschreibt, dass vRack Server unabhängig von Anzahl/physischer Location gruppieren kann.
High-Level über das OVH Control Panel/Guides (Dedicated in vRack, optional Public Cloud in vRack).
IP/VLAN-Plan improvisiert, MTU/Jumbo inkonsistent, Storage/Corosync vermischt.
Routen/Interfaces prüfen (private IPs), Firewall-Logs, und sicherstellen, dass Cluster/Storage nicht über Public Interface gehen.
Ja, sollte man. Proxmox kann sonst standardmäßig Cluster-Netz für Migration nutzen; das ist nicht optimal.
Ja, Proxmox empfiehlt Redundanz via RRP und zwei getrennten Netzen.
Single Node: meist ZFS. HA-Cluster: Ceph nur, wenn Netz/Disks/Sizing wirklich passen.
Nein – besser Bastion/VPN + restriktive Regeln.
Es liefert euch die Basis für private Netze (Corosync/Storage), ohne Public IP Chat.
Lassen Sie uns über Ihre Idee sprechen
Ob konkrete IT-Herausforderung oder einfach eine Idee – wir freuen uns auf den Austausch. In einem kurzen Gespräch prüfen wir gemeinsam, ob und wie Ihr Projekt zu WZ-IT passt.
Vertraut von führenden Unternehmen
Timo Wevelsiep & Robin Zins
Geschäftsführer