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).
Die gemeinsame Grundlage erläutert Proxmox-Cluster-Netzwerk planen: Corosync-Trennung, physische Pfade, MTU und Abnahme.
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 Sie sie vermeiden
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Welche Netze braucht ein Proxmox-Cluster auf OVH?
Trennen Sie Management-, Corosync- und Storage-Traffic, damit Storage-Last die Cluster-Kommunikation nicht beeinträchtigt.
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 VE Admin Guide).
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:
Das Cluster-Netz soll nicht durch Storage oder Live-Migration stark ausgelastet werden. (Proxmox VE Admin Guide)
Das ist genau der Punkt, an dem vRack enorm hilft: Storage-/Backend-Traffic privat und getrennt führen.
Was ist vRack bei OVHcloud?
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).
Mögliche Einsatzfälle sind:
- 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 Sie Backups/Storage/Monitoring privat führen möchten (oder später skalieren), ist vRack trotzdem sinnvoll.
Referenz-Architekturen
Hosting-Anbieter vergleichen, bevor Hardware und Netze festgelegt werden.
Drei Patterns, die in Projekten funktionieren - abhängig von Budget und Verfügbarkeitsziel. Alle drei Muster bieten wir als Setup auf OVHcloud an.
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)
HA-Cluster aufbauen, zwei Nodes mit QDevice und Storage-Wahl.
Für wen: Echtes Failover, Wartung ohne Downtime, Resilienz.
Netze:
- Management-Netz (sicher)
- Corosync/Cluster-Netz (separat!) (Proxmox VE Admin Guide)
- Storage-Netz (wenn Ceph / storage-intensiv), nicht mit Corosync geteilt
Optional: Zweiter Corosync-Link über Kronosnet auf einem anderen physischen Netz (--link1), bis zu acht Links insgesamt.
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.
vRack für Proxmox einrichten: Schritt für Schritt
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
Additional IP, virtuelle MAC und Bridge-Modus
Beim Routed-Modus am öffentlichen Netz ist die Additional IP dem Dedicated Server zugeordnet; bei einem Hostwechsel muss die Zuordnung ebenfalls wechseln. Ein Additional-IP-Block im vRack folgt einem anderen Pfad über das private Interface. Bridge-Modus mit virtueller MAC hängt von der Serverreihe ab und darf nicht mit den Anforderungen des Routed-Modus vermischt werden. Folgen Sie der OVH-Anleitung für HG, Scale und bestimmte Advance-Server.
Die Bridge oben ist ein schematisches Beispiel: HG/Scale verwenden in der Herstelleranleitung bond0 für öffentlich und bond1 für vRack. Die dort behandelten Advance-Server der dritten Generation verwenden direkte NICs; Namen und Servergeneration vorher abgleichen. Weitere Details: Additional-IP-Block im vRack und mehrere VLANs.
Schritt 3: Optional: Public Cloud Instance ins vRack hängen
Wenn Sie Hybrid planen: 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 VE Admin Guide).
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: Planen Sie außerdem, wo Migration-Traffic laufen soll - standardmäßig nutzt Proxmox oft das Cluster-Netz, was nicht ideal ist (Proxmox VE Admin Guide).
Unsicher bei der Zuordnung? Wir beraten Sie.
Schritt 5: Storage-Traffic getrennt halten (bei Ceph Pflicht)
Corosync und Storage sollen kein gemeinsames Netz nutzen; Ausnahme ist höchstens ein niedrig priorisierter Fallback-Link in einer redundanten Konfiguration (Proxmox VE Admin Guide). Bei Ceph/Storage-Recovery kann es sonst passieren, dass Corosync "untergeht".
Cluster-Netzwerk prüfen: Corosync, Migration, Storage
Das Migrationsnetz lässt sich als CIDR in der Datacenter-Konfiguration festlegen, statt das Cluster-Netz zu belasten (Proxmox-Dokumentation).
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 Cluster-Mitgliedschaft prüfen Sie mit:
pvecm status
Schematische Beispielausgabe für einen Cluster mit drei Nodes:
Transport: knet
Nodes: 3
Quorate: Yes
Quelle: Clusterstatus im Admin Guide. pvecm status zeigt Quorum und Mitgliedschaft; prüfen Sie die einzelnen Links zusätzlich mit den Corosync-Werkzeugen. In einer isolierten Testumgebung mit geprüftem Backup zuerst einen Node-Ausfall, danach separat einen Ausfall des Storage-Netzes auslösen. Jeweils Quorum, HA-Neustart und Storage-Erreichbarkeit protokollieren, den Ausgangszustand wiederherstellen und erst dann den nächsten Fehlerfall prüfen.
Häufige Fehler und wie Sie sie vermeiden
Fehler 1: Corosync + Storage im selben Netz
Storage und Corosync getrennt führen (Proxmox VE Admin Guide).
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 VE Admin Guide).
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
Zur öffentlichen Anbindung und zu privaten Gästen: OVH Additional IP in Proxmox: Bridge, Gateway und NAT.
Betrieb der OVHcloud-Server samt vRack und Additional IPs: Managed Operations OVHcloud.
- HA-Cluster
- Zwei Nodes mit QDevice
- Storage-Vergleich
- Cluster-Netzwerk auf Hetzner
- Cluster-Netzwerk auf IONOS
- Ceph
Quellen
Herstellerdokumentation, Stand Oktober 2026.
