Kernelports und VMs auf selbem VSwitch

[pgruber]

Ihr Lieben

Folgende Konfiguration grob umrissen:

physisch:
HP Server mit 2x 10Gbit und 6x 1Gbit am Core Switch
NAS mit 2x 10 Gbit am Core Switch

ESXi 6.5 Netzwerkconfig:
VSwitch0 mit management kernelport. vmk0
An VSwitch1 hängen alle VMs in einer Portgruppe und 2 dedizierte vmkernelports in jeweils eigenen dedizierten Portgruppen. vmk1 und vmk2 Auf der anderen Seite des VSwitch hängen die beiden 10 Gbit Nics. nic6 und nic7
Die vmkernelportgruppen sind mit Portbindung und Lastenausgleich konfiguriert. Jeweils ein Nic ist auf aktiv der andere auf aus gesetzt.

Problem:
Das iSCSI Target des Storage wird nicht gefunden. Der Storage befindet sich im selben Subnetz wie die vmk1 und 2. Mit vmkping aus dem cli kann der Storage gepingt werden.

Vermutung: Trotz sauberer Konfiguration versucht ESXi den Storage via dem TCP/IP stack des management kernelports vmk0 zu finden, was fehlschlägt, da dieser in einem anderen Subnetz ist.

Ich habe nun Testweise einen dedizierten VSwitch aufgebaut, auf dem keine anderen Portgruppen als die der vmk1 und vmk2 sind. Alles läuft. Auch MPIO mit Roundrobin ist kein Problem. Aber sobald auf dem Switch noch vnics der VMs drauf sind findet der Host das iSCSI target nicht mehr.

Ist das per Design oder kann man das via cli konfigurieren? Es kann doch nicht sein, dass ich gezwungen bin für jede Kernelport Anwendung eigene physische nics zu installieren. Ich habe schon gelesen, dass es Best practise ist eigene physische Interfaces für den iSCSI Storage zu nutzen aber das macht in meiner Umgebung keinen Sinn. Die 2x10 Gbit sind massiv schneller als die 4x1Gbit auch da MPIO die Bandbreite nicht aggregiert, sondern nur den max Speed eines physischen Nics verwendet. Also nur 1 Gbit.

Besten Dank für Hilfe. Ich gebe gerne mehr Details, falls diese von Nöten sind.

Beste Grüsse
Peter

[JustMe]

Hallo Peter,

hast Du schon probiert, mal eines der beiden 10G-Kabel abzuziehen, bzw. einen der beiden Ports zu deaktivieren?

Was zeigt denn ein traceroute zum ISCSI-Target?
Hast Du beim Ping mal den bevorzugten Port mit angegeben?
Deine geaeusserte Vermutung kann ich persoenlich nicht so recht nachvollziehen. Was genau erzeugte diese Vermutung?

Auch die Geschichte "10 ist mehr als 1" kann ich so nicht ganz teilen. Wenn Du Deine VMs an die 4 (oder 6, beide Werte waren genannt) 1G-pNICs haengst (ggfs. zusammen mit dem Management-vmk; der sollte nicht soooo entscheidend sein), und die 10G nur fuer die Storage-Anbindung nutzt, waere alles wie Best Practice, und wuerde, wie Du schriebst, auch funktionieren...
Oder hast Du nicht genuegend VMs, um die entsprechende Last zu erzeugen?

Poste doch mal ein paar Bilder der (relevanten) Netzwerkkonfiguration aus dem vSphere Client, oder Schaubilder mit Wegen & Adressen. Vielleicht hilft das ja...

[pgruber]

Hallo

Besten Dank für Deinen Input.

Der traceroute Befehl funktioniert nicht für den vmkping. Und ein normaler ping kommt niemals durch im Storage Netz, da dieses per Design kein Gateway besitzt und VMWare auch per design nicht über kernelports normal pingen kann.

Und sicher ist die 10 Gbit Verbindung viel mehr als 4 mal ein Gbit. Erstmal rein mathematisch und dann nochmal richtig viel, weil sowohl LACP als auch MPIO keine Bandbreite aggregieren. Es wird immer nur 1 Gbit verwendet, wenn die Interfaces 1Gbit haben. Egal wie viele Interfaces man bündelt.
Die Idee das VM Netzwerk fpr die Server und Clients an die 4 Gbit zu hängen und den Storage an die zwei 10 Gbit hatte ich auch schon. Kommt aber genau aufs selbe heraus. Sobald z.B. der Backupserver einen anderen Server sichern will muss er diesen komplett holen. Dies würde dann via dem 4Gbit LACP Channel passieren und somit wieder nur 1 Gbit schnell laufen.

Ich habe nun einen weiteren HP PCI 2x 10Gbit Nic, zwei HPE SFP+ SR DOMs, zwei Cisco SFP+ SR DOMs und zwei 10m Glasfaserkabel gekauft. Alles zusammen für rund 430 Euro. Werde das am WE einbauen und den Storage via zwei dedizierten Kernelports mit je 10 Gbit in den ESXi Host nehmen. Somit haben auf diesem Host dann alle Komponenten ausser der management Kernelport einen eigenen 20 Gbit vSwitch. Bei den Kosten für die Core und Accesslayer Switches macht das den Braten auch nicht fett und wird von allen VMWare Profis extrem empfohlen.

Wundert mich dennoch weshalb es nicht ging. Werde das bei Gelegenheit mal in einer Testumgebung austüfteln. Es muss doch möglich sein VMs aus einem Subnetz mit kernelports aus einem anderen Subnetz auf demselben VSwitch zu betreiben und trotzdem ein iSCSI Target anzubinden.

Gruss
Peter

[JustMe]

Sorry, aber auch mit dem Text im zweiten Post wird's zumindest fuer mich nicht wirklich klarer...

Selbstverstaendlich ist auf eine einzelne Verbindung gerechnet 10G mehr als 1G. Deswegen ja der Hinweis mit "genuegend VMs".

Und wg. ping und traceroute, schau' Dir doch bei Gelegenheit mal bei einem ESXi auf der Kommandozeile per 'which' den ping und vmkping an, und danach per 'ls -lh /bin/*ping'...

Viel Glueck bei Deinen weiteren Tests.

[~thc]

Sorry, aber auch mit dem Text im zweiten Post wird's zumindest fuer mich nicht wirklich klarer...

Er möchte auch für einzelne IP-Verbindungen der VMs und iSCSI mehr als 1 GBit Leistung haben und beschloss, die VMs zusammen mit dem iSCSI-vmkernel-Port auf die physische 10 GBit-Karte zu legen, da weder LACP (VMs) noch MPIO (iSCSI) für einzelne IP-Verbindungen auf einem Trunk aus 1 GBit-NICs netto mehr als 1 GBit liefern.

[JustMe]

So ungefaehr hatte ich das schon vermutet...
Aber wenn der gesamte Traffic von Storage, VMs und Kernel sich ueber die nur 2x 10G-Ports draengelt, waehrend die schoenen 1G-Ports vor sich hin vergammeln, hat man in meinen Augen auch nicht viel erreicht

Ausser latuernich, man schaut nur auf die "Performance" eines einzelnen Kopiervorgangs z.B. einer einzelnen Anwendung in einer einzelnen VM, und kuemmert sich nicht weiter um die "day-by-day" Verwendung... (vorausgesetzt, dass nicht so etwas die "day-by-day" Verwendung darstellt...)

[pgruber]

genau

hab eben in einer 12h Aktion alles eingebaut. auch noch subnetze umgestellt und vieles mehr.

läuft rund und mit dem zweiten physischen 2x10Gbit Nic ist der Storage VSwitch jetzt dediziert. Performance Test hat sofort den nächsten Flaschenhals aufgezeigt: In diesem Fall das SATA RAID 10 des iSCSI Target. 380MB/s downstream auf die im Host festverbauten SAS Platten. Also rund 3 Gbit.

Schön das. So kann nebenher noch der ganze produktive Betrieb laufen und ein Backupjob zieht mit satter Geschwindigkeit. Das ist by the way ein fast daily job.. irgendwelche Backups laufen immer und die 40 Clients können so ungestört weiterarbeiten während ich manche Backupjobs jetzt endlich auch unter Tage fahren kann, ohne das ganze Netz lahm zu legen.

Ich geh dann mal ins Bettchen.
prost...