Proxmox Cluster Netzwerk auf OVH: vRack richtig nutzen
Hinweis zum Inhalt: Die Informationen in diesem Artikel wurden nach bestem Wissen zum Zeitpunkt der Veröffentlichung zusammengestellt. Technische Details, Preise, Versionen, Lizenzmodelle und externe Inhalte können sich ändern. Bitte prüfen Sie die genannten Angaben eigenständig, insbesondere vor geschäftskritischen oder sicherheitsrelevanten Entscheidungen. Dieser Artikel ersetzt keine individuelle Fach-, Rechts- oder Steuerberatung.
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.
Geschrieben von
Timo Wevelsiep
Co-Founder & CEO
Co-Founder von WZ-IT. Spezialisiert auf Cloud-Infrastruktur, Open-Source-Plattformen und Managed Services für KMUs und Enterprise-Kunden weltweit.
LinkedInLassen 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