Vlan Einrichtung, über vSwitch / Bridge oder Vlan Aware mit Tag

[spooner]

Hallo Zusammen,
ich arbeite sehr viel mit Vlans für die Netzwerksegmentierung und auch wegen der Sicherheit.
Bisher habe ich die meisten Erfahrungen mit VMware und Hyper-V und stelle mich jetzt langfristig auf Proxmox ein.
Ich bin gerade dabei ein Proxmox Cluster aufzubauen und dabei kam mir das VLan Thema jetzt in Kopf.

Es gibt ja verschiedene Wege das mit den VLans unter Proxmox einzurichten.

Variante 1:
über vSwitch / Bridge
Sprich pro Vlan eine eigene Bridge

usw.

Diese Bridge dann der jeweiligen VM als NIC zuweisen.


Variante 2:
Vlan Aware mit Tag
Beim Host:


Und dann bei der VM die einzigste vorhandene Bridge auswählen einen VLan Tag:



Was ist den jetzt der richtige Weg und die "Best Practise" Lösung?

Oder gibt es keinen Unterschied?

Beim Cluster ist das Tagging vermutlich besser und einfacher von der Handhabung.

Viele Grüße
Arthur

 

[Bu66as]

Klar, da gibt's eine eindeutige Empfehlung: nimm die VLAN-aware Bridge mit Tags (deine Variante 2). Im Cluster ist das einfach angenehmer, weil du nur EINE Bridge (vmbr0) auf allen Nodes identisch konfigurierst und das VLAN dann pro VM am NIC taggst. Bei der Bridge-pro-VLAN-Variante musst du auf jedem Node für jedes neue VLAN ne eigene Bridge + Subinterface anlegen, das wird im Cluster schnell unübersichtlich und fehleranfällig (eine vergessene Bridge auf Node X und die Live-Migration scheitert).

Am Ende kommt's funktional auf das Gleiche raus, aber Variante 2 ist einfach die bessere Lösung und skaliert besser. Ein neues VLAN heißt dann nur noch: am Switchport trunken und in der VM den Tag setzen, fertig, kein Eingriff mehr an der Host-Netzwerkconfig.

Auf der Bridge muss sauber sein: der Uplink (enp2s0 bei dir) muss als Trunk vom Switch kommen und alle VLANs durchreichen. Wenn du die VLANs auf bestimmte IDs begrenzen willst, kannst du in /etc/network/interfaces noch bridge-vids setzen, sonst sind per Default alle erlaubt.

Noch was: du hast die Management-IP direkt auf vmbr0 (192.168.104.10) liegen, also untagged/native. Pass auf dass dein Switchport das Native-VLAN passend hat, sonst sperrst du dich beim Umstellen aus. Läuft dein Mgmt mit über den selben Uplink oder hast du dafür ne separate NIC?

 

[spooner]

Alles klar, super, danke.
Ich hab leider nur zwei NICs.
NICs 1: MGMT und Up-Link und Vlans
NIC2 : ZFS-Replication

MGMT wollte ich über Vlan1 laufen lassen, also kein Tagging.

 

[spooner]

Alles klar, super, danke.
Ich hab leider nur zwei NICs.
NICs 1: MGMT und Up-Link und Vlans
NIC2 : ZFS-Replication

MGMT wollte ich über Vlan1 laufen lassen, also kein Tagging.

Quatsch, ich sehe gerade für die Hyper-V Hosts hab ich ein eigenes Vlan.
Aber trotzdem ohne Tagging, ist das Native Vlan auf dem Switch Port

 

[Bu66as]

Passt so, dein MGMT untagged übers Native-VLAN am Switchport zu fahren ist völlig in Ordnung, das läuft dann einfach auf vmbr0 ohne Tag und der Switch packt's ins richtige VLAN. Die getaggten VMs hängen ja über die selbe vmbr0 mit ihrem jeweiligen Tag (bei dir z.B. 22) parallel daneben, das beißt sich nicht.

Was ich mir bei 2 NICs aber überlegen würde: wo läuft dein Corosync? Du hast NIC1 für MGMT+Uplink+VLANs und NIC2 für ZFS-Replication, da bleibt für Corosync nur eins von beiden übrig. Corosync will niedrige, stabile Latenz, und wenn du den Ring auf die NIC legst wo gleichzeitig die ZFS-Replikation Vollgas zieht, kannst du dir Quorum-Flaps einfangen. Am besten corosync auf die ruhigere Leitung (eher MGMT-Seite) und wenn möglich nen zweiten Ring als Backup auf die andere NIC, dann fängt dich der ab wenn ein Link mal weg ist.

bridge-vids auf vmbr0 setzen lohnt sich übrigens auch, dann reichst du nur die VLANs durch die du wirklich brauchst statt per Default alle, hält's sauber.

Wie viele Nodes wird der Cluster denn? Bei genau zwei brauchst du noch nen QDevice als Tie-Breaker, sonst hast du beim Ausfall eines Nodes kein Quorum mehr.

 

[spooner]

Ja, ich hab nur 2 Nodes und auch QDevice ist eingeplant.
Das habe ich schon hier im Forum in einem anderen Thread herausgearbeitet.

Die NIC 2 ist eine 2,5G PCI-E Karte und darüber wollte ich eigentlich die gesamten Netzwerk-Verkehr der beiden Hosts laufen lassen.
Sprich: ZFS-Replication und Corosync

Über die Onboard 1G NIC, dann im Prinzip alles andere.

 

[Bu66as]

Genau die Kombi würde ich so nicht machen. ZFS-Replikation zieht die 2,5G-Leitung phasenweise komplett voll, und Corosync auf der selben NIC kriegt dann genau die Latenz-Spikes ab, die zu Quorum-Flaps führen. Corosync braucht ja praktisch keine Bandbreite, nur niedrige stabile Latenz. Das passt nicht zusammen mit nem Replikations-Burst.

Ich würd's andersrum aufteilen: Corosync auf die ruhige Onboard-1G (läuft eh mit MGMT, da ist wenig los), und die 2,5G allein für die ZFS-Replikation. Und wenn du's sauber willst, nimm die 2,5G als zweiten Corosync-Ring dazu (Link1), dann hast du Redundanz, falls die 1G mal weg ist, ohne dass die Replikation den primären Ring stört.

Bei 2 Nodes + QDevice ist ein stabiles Corosync eh das A und O, ein eingefrorener Node wegen Quorum-Flap ist deutlich nerviger als ne Replikation die mal ne Minute länger braucht.