Traffic-Flow mit vSwitches: Wann läuft die VM-Kommunikation über das physische Netzwerk?

Anmerkung: Eine Single-Core-VM wird nur in den seltensten Fällen von einer 10G-Netzwerk­anbindung profitieren, vor allem dann nicht, wenn das Gast­system hier nicht mitspielt. Einzel­heiten zur Performance des VMXNET3-Adapters finden sich im VMware-Whitepaper Performance Evaluation of VMXNET3 Virtual Network Device.

Grundsatzfragen

Befinden sich etwa zwei virtuelle Maschinen auf dem gleichen Host, dann kann man sich fragen, ob der Datenverkehr über­haupt das virtuelle und physische Netzwerk tangiert, denn ein vSwitch ist ein Software definiertes Layer-2-Gerät im Kernel von ESXi.

Die Frage (und die Antwort) impliziert, dass der Nutzer durch Zuweisung bestimmter VMs zum gleichen Host, vSwitch und zur gleichen Portgruppe die Netzwerk­geschwindigkeit erhöhen und die Latenz reduzieren kann.

Verwendet etwa die virtuelle NIC bzw. der Treiber einer ausreichend leistungs­fähigen Netzwerk­karte zum Beispiel den VMNET3-Adapter, dann könnte diese ja mit dessen maximal möglichen Geschwindig­keit mit dem vSwitch kommunizieren.

Da der Netzwerk­verkehr zwischen VMs auf dem gleichen Host, vSwitch oder der gleichen Portgruppe den Host nicht verlässt, versucht man in der Praxis tatsächlich, solche VMs, die intensiv im Netzwerk mit­einander kommu­nizieren müssen, (zum Beispiel Web-, Anwendungs- oder Datenbank-Server) auf dem gleichen Host zu platzieren.

Dies erhöht die Netzwerk­geschwindigkeit und die Netzwerk­latenz zwischen den VMs verringert sich. In einem DRS-Cluster könnte man dann sogar per Regel erzwingen, dass die VMs auch bei einem vMotion-Vorgang auf dem gleichen Host bleiben.

Verlässt der Netzwerk-Traffic allerdings den Host über dessen Uplink-Adapter, dann ist dieser der limitierende Faktor für Performance und Latenz. Schauen wir uns dazu verschiedene Szenarien an.

Tatsächlich machen wir hier nur eine Reine Layer-2-Betrachtung. Eine Layer-3-Perspektive ist auch gar nicht möglich, da für VMs keine IP-Adressen angegeben sind. Befinden sich zwei VMs nicht im gleichen Layer-3-Netzwerk, dann kann sie ein vSwitch nicht routen und das Routing wird an den physischen Switch delegiert, der in der Praxis entweder ein Multilayer-Switch ist oder einen Router kennt.

Allerdings sind hier zwei Ausnahmen denkbar:

• Man konfiguriert eine VM mit zwei Netzwerk­karten auf dem gleichen vSwitch als Router
• Man betrachtet zwei VMs in zwei verschieden benannten Portgruppen, die aber beide im gleichen VLAN oder keinem VLAN sind. Auch hier würde der Traffic direkt über den vSwitch laufen, wie im ersten der folgenden Szenarien.

VMs auf gleichem Host, gleichem vSwitch, gleicher Portgruppe/VLAN

Folgende Abbildung zeigt ein Szenario, in dem VM1 und VM2 mit vSwitch1 und der gleichen Portgruppe Production verbunden sind. Ob Production ein dediziertes VLAN repräsentiert oder keinem VLAN zugeordnet ist, spielt hierbei keine Rolle. Beide VMs laufen auf dem gleichen ESXi-Host mit dem Namen ESX1.

Der Netzwerk­verkehr zwischen VM1 und VM2 wird hier nicht an physische Netzwerke wie Switches oder nach­geschaltete Geräte (strukturierte Verkabelung) weitergeleitet, denn die VMs können über den vSwitch kommunizieren.

In diesen Fall kann der Nutzer also eine erhöhte Netzwerk­geschwindigkeit bzw. eine geringere Netzwerk­latenz erzielen, wobei die prinzi­piellen Ein­schränkungen eines para­virtualisierten Adapters gelten.

VMs auf gleichem vSwitch, aber anderer Portgruppe / VLAN

Im zweiten Szenario hängen VM1 und VM2 am gleichen vSwitch namens vSwitch1, aber VM1 ist mit einer Portgruppe namens TestDev und VM2 mit der Portgruppe Production verbunden. Beide laufen auf dem gleichen Host mit dem Namen ESX1.

Hier fließt der Netzwerk­verkehr zwischen VM1 und VM2 über eine an vSwitch1 angeschlossene physische NIC und dann an einen physischen Switch. Anschließend wird er zu einer physischen NIC auf vSwitch1 und anschließend zu VM2 zurückgeleitet.

Eigentlich geht aus der Zeichnung (sie stammt von einem Blog-Eintrag im VMTN) nicht hervor, ob die unter­schiedlichen Farben und Bezeichnungen für die beiden Portgroups, für unterschiedliche VLANs oder unter­schiedliche Layer-3-Netze oder beides stehen sollen.

Da wir aber eine Layer-3-Betrachtung ausschließen und die IP-Konfiguration ohnehin Sache der VM (vNIC) und nicht der Portgruppe ist, wirkt sich hier nur der Umstand aus, dass VM 1 und VM2 jetzt in unter­schiedlichen Layer-2-Segmenten voneinander isoliert sind. Aufgrund der unterschied­lichen Portgroup-Namen stecken sie nämlich in unterschiedlichen VLANs.

Unterschiedliche vSwitches, dieselbe Portgruppe

Im nächsten Beispiel hängt VM1 an vSwitch1 und VM2 an vSwitch2, beide sind jedoch mit derselben Portgruppe Production verbunden und beide VMs laufen auf demselben ESXi-Host namens ESX1.

Der Netzwerk­verkehr zwischen VM1 und VM2 wird in diesem Fall über eine physische NIC auf vSwitch1 und dann zu einem physischen Switch geleitet und anschließend zu einer auf vSwitch2 angeschlossenen physischen NIC zurück­gesendet und erreicht dann VM2.

Hier sorgen die beiden unter­schiedlichen vSwitches auf ESX1 dafür, dass sich die beiden VMs aus Layer-2-Sicht trotz gleich benannter Portgroups sozusagen physikalisch in unter­schiedlichen Layer-2-Segmenten befinden, obwohl sie offensichtlich im gleichen (oder keinem) VLAN sind (gleiche Bezeichnung, gleiche Farbe). Für die Route hat dies den gleichen Effekt, als wären beide VMs wie oben am gleichen vSwitch, aber in unter­schiedlichen VLANs.

VMs auf verschiedenen ESX-Hosts, vSwitch und Portgruppen

Im nächsten Beispiel läuft VM1 auf einem Host mit dem Namen ESX1 und ist mit dem virtuellen Switch vSwitch1 und der Portgruppe Production verbunden. VM2 läuft auf ESX2 und ist mit vSwitch1 und der Portgruppe TestDev verbunden.

Der Netzwerk­verkehr zwischen VM1 und VM2 wird in diesem Szenario über eine physische NIC auf vSwitch1 von ESX1 und dann auf den physischen Switch übertragen, anschließend zu einer physischen NIC zurück­geleitet, die an den vSwitch1 des ESXi2-Hosts angeschlossen ist, und erreicht schließlich VM2.