Proxmox Cluster Netzwerk auf IONOS: Privates Netz mit VLAN (802.1Q)

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

IONOS-Setups scheitern selten an "Proxmox kann das nicht", sondern daran, dass Leute kein sauberes privates Backend-Netz bauen – und dann laufen Corosync oder Storage über Public IPs. Dabei beschreibt IONOS sehr klar, wie man für Dedicated Server ein privates Netzwerk aufbaut: über tagged VLANs nach IEEE 802.1Q (IONOS Docs).

Inhaltsverzeichnis

• Proxmox braucht Netztrennung – IONOS liefert die Bausteine
• Was bedeutet "tagged VLAN (802.1Q)" bei IONOS?
• Referenz-Architekturen
• Schritt-für-Schritt Vorgehen
• Häufige Fehler und wie du sie vermeidest
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

---

Proxmox braucht Netztrennung – IONOS liefert die Bausteine

Proxmox sagt: separates Corosync-Netz ist good practice; Storage darf nie auf demselben Netz wie Corosync liegen (Proxmox Wiki).

IONOS liefert für Dedicated Server die technische Grundlage, um ein privates Netz zu bauen: tagged VLANs (IEEE 802.1Q) (IONOS Docs).

---

Was bedeutet "tagged VLAN (802.1Q)" bei IONOS?

Ein privates Netzwerk aus Dedicated Servern kann durch Konfiguration von tagged VLANs erstellt werden. VLANs sind in IEEE 802.1Q standardisiert (IONOS Docs).

IONOS hat OS-spezifische Guides:

• AlmaLinux/Rocky: VLAN-Trunk (802.1Q) (IONOS Docs EN)
• Ubuntu/Debian: tagged VLAN für privates Netz (IONOS Docs EN)

Praktisch heißt das:

• Du definierst VLAN-IDs (z. B. VLAN 10 = Management, VLAN 20 = Corosync, VLAN 30 = Storage)
• Das Interface wird VLAN-aware, und Traffic ist logisch getrennt
• Du kannst ein "Backend" bauen, das nicht öffentlich routet

---

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:

• Public: nur was wirklich nötig ist (z. B. Services)
• Private/VLAN: Management (oder nur VPN/Bastion), optional Backup-Backend

Ziel: Schnell, robust, betriebssicher (Backups/Monitoring/Updates).

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 (Recommended)

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

Netze:

• Management VLAN
• Corosync VLAN (separat!) (Proxmox Wiki)
• Storage VLAN (bei Ceph/Storage-intensiv) – niemals mit Corosync teilen!

---

Pattern C: "2 VLANs reichen oft" (kleiner Cluster ohne Ceph)

Wenn kein Ceph:

• VLAN A: Management
• VLAN B: Corosync + Migration (oder Migration separat, wenn ihr's sauber machen wollt)

Aber: Sobald Storage intensiv wird, wieder trennen.

---

Schritt-für-Schritt Vorgehen

Schritt 1: Netzwerkplan (VLAN-IDs, IP-Ranges, Rollen)

Bevor du am OS "rumkonfigurierst":

• VLAN-IDs definieren
• IP-Plan pro VLAN
• Welche Server hängen in welche VLANs?
• Wo läuft VPN/Bastion?

Schritt 2: VLAN/802.1Q auf Dedicated Servern konfigurieren (IONOS Guides)

IONOS dokumentiert das als Schrittfolge je OS:

• AlmaLinux/Rocky: VLAN Trunk (802.1Q) für privates Netz (IONOS Docs EN)
• Ubuntu/Debian: tagged VLAN für privates Netz (IONOS Docs EN)

Wichtig (Real-Life): Wenn VLAN-Modul/802.1Q nicht korrekt geladen ist, funktioniert es nicht (IONOS erwähnt das in ihren Troubleshooting-Hinweisen).

Schritt 3: Proxmox Bridges sauber zuordnen

• Management Bridge auf Management-VLAN
• Corosync Interface/Bridge auf Corosync-VLAN
• Storage Interface/Bridge auf Storage-VLAN (falls nötig)

Unsicher bei der Zuordnung? Wir beraten dich.

Schritt 4: Corosync wirklich separat betreiben

Proxmox: separate Cluster network ist good practice, und Storage darf nicht im Corosync-Netz laufen (Proxmox Wiki).

Das ist dein Guardrail, wenn du die VLANs definierst.

Schritt 5: Validierung & Tests

Nach dem Aufbau (vor Produktiv):

• Corosync unter Last stabil?
• Storage-Recovery beeinflusst Corosync nicht?
• Migration läuft über ein Netz mit Bandbreite (und nicht über Corosync) – Proxmox nutzt sonst oft Cluster-Netz für Migration, was nicht optimal ist (Proxmox Forum)

---

Häufige Fehler und wie du sie vermeidest

Fehler 1: "VLAN geplant, aber nicht end-to-end umgesetzt"

Ein Node hat VLAN 20, der andere nicht → "geht komisch".

Fix: VLAN Plan + consistent OS config überall.

Fehler 2: 802.1Q Modul fehlt / falscher Kernel

IONOS nennt explizit, dass 802.1Q Modul-Verfügbarkeit ein Fehlergrund sein kann (IONOS Docs EN).

Fix: Modul laden / Kernel prüfen.

Fehler 3: Corosync + Storage im gleichen VLAN

Proxmox sagt: nein (Proxmox Wiki).

Fix: Eigenes Storage-VLAN.

Fehler 4: Management öffentlich

Unnötiges Risiko.

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

Fehler 5: Migration killt Cluster-Netz

Wenn Migration über Cluster-Netz läuft, kann Corosync leiden (Proxmox Forum).

Fix: Migration auf "fat pipe" VLAN.

---

Unser Vorgehen bei WZ-IT

Bei Proxmox auf IONOS gehen wir so vor:

1. Anforderungsanalyse: Single Node vs. Cluster, HA-Ziele, Storage-Anforderungen
2. Netzwerk-Design: IP-Plan, VLAN-IDs, Interface-Zuordnung
3. Setup: VLAN-Konfiguration (802.1Q), Proxmox Installation mit sauberer Bridge-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 IONOS →

---

Weiterführende Guides

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