VMware-Forum

Hallo vm-Gemeinde

Ich benötige etwas Unterstützung zwecks vlan-/Netzwerk-Gestaltung in einer vsphere-Umgebung und wäre dankbar, wenn man mir über die Schulter schauen könnte, da ich mich mit virtuellen Netzen und vlans noch nicht so gut auskenne.

Die aktuelle Infra wird rundum erneuert, sprich neues SAN, neue Server, neue Switches.

Alte Infra besteht aus zwei ESX 4.0, einem EMC Clariion CX200, FC-Switch und einigen Cisco Switches.

Neue Infra wird etwas kompakter mit zwei ESXi 4.1, einem EQL PS6000XV und zwei Powerconnect 6248 im Stack.

Alte Infra belegt mit den vServern und Workstations das gleiche Subnetz (10.132.16.0/24).
Für die neue dachte ich mir ein eigenes Vlan und Subnetz für
a) das iSCSI-Netz
b) die vServer
c) die Workstations

Wäre dies die richtige Angehensweise? Denn was natürlich hinzu kommt, wäre die Migration resp. Umstellung, so dass ich von einer Infra in die andere komme (converter, SMB).

Beim 6248 wird ja empfohlen das mgmt-vlan (1) als separates subnetz zu betreiben und die weiteren getrennt zu erstellen, wie löse ich aber dann den Zugang über ssh/web zu dem switch? Einfach eine weitere IP aus dem mgmt-Netz dem Server hinzufügen, welcher den Switch verwalten soll?

Dann wären da noch so Dinge wie vlan-tagging und LAG, etherchannel.

Macht es Sinn die 4 iscsi-Nics eines ESXi mittels LAG zu bündeln, switchseitig?
Eigener Vmkernel mit 4 Portgroups ist bereits vorhanden, RoundRobin funktioniert soweit...

Wie löse ich die vlan-Problematik am besten auf VM-Ebene?
Einige VM's brauchen den direkten Access in das SAN-Netz, zwecks iscsi-Disk.
In anderen Artikeln/Foren fiel der Standard 802.1q, wie läuft das genau ab? Muss ich dazu separate Portgruppen, ja sogar vSwitches erstellen?

Bin um jeden Tipp bzw. Erklärung dankbar!

Grüsse

Hi!
mal ein paar Links bzw. suchbegriffe bei google (jeweils pro zeile )
great vswitch debate
iscsi multivendor
http://www.vmware.com/pdf/esx_vlan.pdf

habt ihr normale oder distributed vSwitche?
wie viele phys. nic-ports im Server?

viele grüße,
jörg

Ciao Jörg

Danke schon mal für die rasche Hilfe!

Wir setzen normale vSwitches ein, ein ESXi hat jeweils 12 Nics (edit: natürlich nic-ports )

Virtuozzi hat geschrieben:Hallo vm-Gemeinde

Ich benötige etwas Unterstützung zwecks vlan-/Netzwerk-Gestaltung in einer vsphere-Umgebung und wäre dankbar, wenn man mir über die Schulter schauen könnte, da ich mich mit virtuellen Netzen und vlans noch nicht so gut auskenne.

Die aktuelle Infra wird rundum erneuert, sprich neues SAN, neue Server, neue Switches.

Alte Infra besteht aus zwei ESX 4.0, einem EMC Clariion CX200, FC-Switch und einigen Cisco Switches.

Neue Infra wird etwas kompakter mit zwei ESXi 4.1, einem EQL PS6000XV und zwei Powerconnect 6248 im Stack.

Alte Infra belegt mit den vServern und Workstations das gleiche Subnetz (10.132.16.0/24).
Für die neue dachte ich mir ein eigenes Vlan und Subnetz für
a) das iSCSI-Netz
b) die vServer
c) die Workstations

Wäre dies die richtige Angehensweise? Denn was natürlich hinzu kommt, wäre die Migration resp. Umstellung, so dass ich von einer Infra in die andere komme (converter, SMB).

Wenn du eh schon Segmente hast dann moechtest du auch ein Subnet fuer Management haben.

Bei uns liegen da die ESX Hosts, Remote Management, USV, Switche inkl. primaerer Backup Traffic drin. Das ganze dann per FW Regeln von aussen so konfiguriert das nur bestimmte IP/Ports zugreifen bzw. heraus duerfen.

Jedes Segment hat ein VLAN und ist auf den Switchen entsprechend konfiguriert. Allerdings ist nicht jedes Geraet VLAN Faehig (die EQLs z.B nicht) so das du entsprechene Tagged und Untagged Ports in dem VLAN Bereich benoetigst.

Beim 6248 wird ja empfohlen das mgmt-vlan (1) als separates subnetz zu betreiben und die weiteren getrennt zu erstellen, wie löse ich aber dann den Zugang über ssh/web zu dem switch? Einfach eine weitere IP aus dem mgmt-Netz dem Server hinzufügen, welcher den Switch verwalten soll?

Unser Management VLAN ist nicht die 1 und wird entsprechend dann auf den Switchen geaendert. Das geht bei "besseren" Switchen ohne Probleme nur die guenstigen bieten oftmals diese Moeglichkeit nicht.

Dann wären da noch so Dinge wie vlan-tagging und LAG, etherchannel.

Macht es Sinn die 4 iscsi-Nics eines ESXi mittels LAG zu bündeln, switchseitig?
Eigener Vmkernel mit 4 Portgroups ist bereits vorhanden, RoundRobin funktioniert soweit...

Klares Nein.

Wie löse ich die vlan-Problematik am besten auf VM-Ebene?
Einige VM's brauchen den direkten Access in das SAN-Netz, zwecks iscsi-Disk.
In anderen Artikeln/Foren fiel der Standard 802.1q, wie läuft das genau ab? Muss ich dazu separate Portgruppen, ja sogar vSwitches erstellen?

Ja du brauchtst eine extra Portgruppe bzw. zwei wenn MPIO genutzt werden soll. Sofern du fuer deine swiscsi Konfig schon einen seperaten vSS gemacht hast legst du dort 2 weitere PGs vom Typ "Virtual Machine Network" an. Bei uns heissen die ISCSI-1 und ISCSI-2.

Deine VM bekommt dann 2 zusaetzliche vNICs und entsprechend 2 IPs aus deinem iSCSI Subnet. Ob du dafuer die pNICs nimmst welche schon fuer die VMKs benutzt werden oder 2 neue haengt von dir ab.

VLAN innerhalb der VM braucht nicht konfiguriert werden da du es fuer die PG auf vSwitch Ebene setzt wenn der Switch entsprechend konfiguriert ist.

Meine "Spielwiesen" hier sind auch div. EQLs mit PC5458,62xx,8024f.

Gruss
Joerg

Vielen Dank euch beiden für die Hilfe und Anregungen!

Schon alleine die "great vswitch debate" wars wert

Super Forum, nochmals danke!

Zwischenstand soweit:

Die Sache ist gemäss meinem ersten Post fertig aufgesetzt.

Ich habe nun noch eine kleine Frage betreffend Jumbo Frames:
Damit der dedizierte vSwitch mit den enthaltenen iscsi-vmks mit jumbos zu dem EQL kommunziert, musste ich zunächst die "Management Network" PG abreissen und neu über die cli mit "-m 9000" erstellen.

Erst dann war der iscsi-Login im EQL-Log als "jumbo frame" deklariert.
Vorher gings immer mit der standard Länge, obwohl doch eigentlich die vmks dafür verantwortlich sind und der iscsi-vSwitch inkl. PGs mit jumbos konfiguriert wurde.

Ist dies ein normales Verhalten, dass der Login zunächst über die mgmt-vmk (vmk0) läuft und nicht direkt über die eigentlich zutreffenden?

Hab dank folgendem Artikel die Sache herausgefunden:
http://www.gavinadams.org/blog/2010/07/19/esxi-41-and-the-9000-byte-mtu-on-vmk0

Nun zu meiner ursprünglichen Verständnisfrage:

Schlussendlich werden die ESXi-Hosts in einem externen RZ stehen, von wo aus per Standleitung dann zugegriffen wird.
Endpunkt beim Kunden ist ein FC-Router mit Ethernet-Ports, von welchem aus die Clients dann in das RZ-Netz kommen.
Endpunkt im RZ ist eine Watchguard-FW, mit Verbindung zu dem 6248-Stack, wo sich auch alle virtuellen Server inkl. ESXi-Hosts befinden.

Testweise habe ich mit vmxnet3, die VM's auch mit jumbos am Laufen, funktioniert soweit gut.

Was mir Sorgen bereitet sind allfällige Timeouts/Retransmits, wenn die Clients dann mit den vServern kommunizieren. Die Watchguard-FW hat auf diesem Port zum 6248-Stack auch eine MTU von 9000. Hört dort die jumbo-Geschichte auf und danach ist gut, oder kann es allfällige Probleme geben, da weder die Standleitung, noch die Clients mit jumbo laufen?

Danke, falls ihr überhaupt bis hier hin gelesen habt.

Gruss

push

Möchte ungern diesen alten Thread ausgraben, man lebt doch lieber als sorgenfreier Admin


Das Netz sieht nun ziemlich so aus wie es irix von sich aus beschrieben hat.
1 vlan für die vserver, eins für iscsi und eins für management.

Klappt soweit auch wunderbar, ausser folgendes:
Wir haben 2 ESXe (v5) und ein EQL 6000XV dazu ein 2er Stack Dell 6248.

Sobald ich einen der beiden DC's auf den anderen Host verschiebe klappt gar nichts mehr mit dem AD. Unendliche timeouts, GPO's werden nicht mehr aktualisiert, alles bleibt stehn und laggt ab wie Sau (AD-technisch).

Sind die DC's auf dem selben Host läufts wie geschmiert, getrennt sind sie aber beide von sich aus anpingbar (somit funktioniert das vlan aus meiner Sicht).

Ich kriege aber Replikations-Fehlermeldungen à la anderer DC nicht erreichbar, Zugriff verweigert.

Kann mir da jemand weiterhelfen, resp. habt ihr einen Anhaltspunkt?

Gruss