Traffic-Flow in vSwitchen vSphere Networking Basics

Verschiedene Traffic-Flow-Szenarien im Layer-2

Das Thema vSphere-Networking ist selbst für alte VMware-Hasen oft nicht ganz einfach zu durchdringen. In diesem Beitrag geht’s es einmal nicht um die Workflow zum Erstellen von vSwitchen, Kernel-Adaptern oder VM-Portgroups/Netzwerken, sondern um die Art und Weise, wie Traffic in verschiedenen Netzwerk-Szenarien tatsächlich fließt, was entscheidenden Einfluss auf die Performance haben kann.

Hat man die Prinzipien der Netzwerkvirtualisierung unter VMware vSphere verstanden, beantworten sich auch häufig wiederkehrende Grundsatzfragen von selbst. Als VMware-Trainer kann ich bestätigen, dass das Thema Networking in jedem VMware-Kurs neben Storage den größten Raum einnimmt. Eine beliebte wiederkehren Frage ist z.B., mit welcher Bandbreite einer virtuelle Maschine an einen virtuellen Switch angebunden ist, insbesondere vor dem Hintergrund, dass z. B. der paravirtualisierte VMNET3-Adpter ein 10Gbit/s-Adapter ist.

Anmerkung: Eine Single-Core-VM wird nur in den seltensten Fällen von einer 10G-Netzwerkanbindung profitieren, vor allem dann nicht, wenn das Gastsystem hier nicht mitspielt. Einzelheiten zur Performance des VMXNET3-Adapters finden sich bei Bedarf im Whitepaper https://www.vmware.com/pdf/vsp_4_vmxnet3_perf.pdf Performance Evaluation of VMXNET3 Virtual Network Device von VMware).

Dieser Beitrag hilft zu verstehen, wie der Verkehr der virtuellen Maschinen in verschiedenen Szenarien fließt und wovon erzielbare Performance abhängt.

Grundsatzfragen

Befinden sich z. B. zwischen zwei virtuellen Maschinen tatsächlich auf dem gleichen Host, kann man sich fragen, ob der Datenverkehr überhaupt das virtuelle und physische Netzwerk tangiert, denn ein vSwitch auf einem ESX-Host ist im wesentlichen Software, die sich im Speicher der Host-Server befindet. Die Frage (und die Antwort) impliziert, dass der Nutzer durch Zuweisung bestimmter VMs zum gleichen Host, vSwitch und gleicher Portgruppe die Netzwerkgeschwindigkeit erhöhen und die Latenz reduzieren kann? Verwendet etwa der virtuelle NIC der Netzwerkkarte, bzw. dessen Treiber einer entsprechend leistungsfähige Netzwerkkarte wie z. B. den VMNET3-Adapter, könnte diese ja mit dessen maximal möglicher Geschwindigkeit mit dem vSwitch kommunizieren.

Da der Netzwerkverkehr zwischen VMs auf dem gleichen Host, dem gleichen vSwitch sowie der gleichen Portgruppe den Host nicht verlässt, versucht man tatsächlich in der Praxis VMs, die intensiv im Netzwerk miteinander kommunizieren müssen, (z. B. Webserver, Anwendungsserver und Datenbank) in der gezeigten Weise auf dem gleichen Host zu platzieren. Dadurch wird die Netzwerkgeschwindigkeit erhöht und die Netzwerklatenz zwischen den VMs verringert. 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, sind Diese der limitierende Faktor für Performance und Latenz. Schauen wir uns verschiedene Szenarien an.

Tatsächlich machen wir hier nur eine Reine Layer-2-Betrachtung. Eine Layer-3-Betrachtung ist auch gar nicht möglich, da für die VMs keine IP-Adresse angegeben sind.

Befinden sich zwei VMs nicht im gleichen Layer-3-Netzwerk, kann sie ein vSwitch ohnehin 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. A) Man konfiguriert eine VM mit zwei Netzwerkkarten auf dem gleichen vSwitch als Router oder 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 Folgenden ersten Szenario:

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

Folgende Abbildung zeigt ein Szenario, in dem VM1 und VM2 sind mit dem gleichen vSwitch mit dem Namen „vSwitch1“ und der gleichen Portgruppe mit dem Namen „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 Netzwerkverkehr zwischen VM1 und VM2 wird dann tatsächlich nicht an physische NICs auf dem ESXi-Host weitergeleitet.

Daher werden die Frames auch nicht an physische Netzwerke wie physische Switches oder nachgeschaltete Geräte (strukturierte Verkabelung) weitergeleitet, denn die VMs können tatsächlich innerhalb des vSwitch kommunizieren. In diesen Fall kann der Nutzer also sehrwohl eine erhöhte Netzwerkgeschwindigkeit, bzw. geringere Netzwerklatenz erzielen, unter Berücksichtigung der im o. verlinkten Dokument verbundenen prinzipiellen Einschränkungen des paravirtualisierten Adapters.

VMs auf gleichem vSwitch, anderer Portgruppe / VLAN

Im zweiten Szenario sind VM1 und VM2 sind mit dem gleichen vSwitch mit dem Namen „vSwitch1“, aber VM1 ist mit einer Portgruppe namens „TestDev“ und VM2 mit einer Portgruppe mit dem Namen „Production“ verbunden. Beide laufen aber auch dem gleichen ESXi-Host mit dem Namen „ESX1“. Trotzdem wird der Netzwerkverkehr zwischen VM1 und VM2 dann über eine an vSwitch1 angeschlossene physische NIC und dann an einen physischen Switch geleitet. Anschließend wird er zu einer physischen NIC auf vSwitch1 und anschließend zu VM2 zurückgeleitet.

Eigentlich geht aus der Zeichnung (die Zeichnung stammt nicht von mir, sondern einem https://communities.vmware.com/docs/DOC-25426 Blog-Eintrag im VMTN) nicht hervor, ob die unterschiedlichen Farben und Bezeichnungen für die beiden Portgroups für unterschiedliche VLANs oder unterschiedliche Layer-3-Netze oder Beides stehen sollen. Da wie aber einer Layer-3-Betrachtung ausschließen und die IP-Konfiguration ohnehin Sache der VM (vNIC) und nicht der Portgruppe ist kommt hier nur der Umstand zu tragen, dass VM 1 und VM2 jetzt in unterschiedlichen Layer-2-Segmenten voneinander isoliert sind, denn  aufgrund der unterschiedlichen Portgroup-Namen/oder Farben stecken sie in unterschiedlichen VLANs.

VMs sind mit unterschiedlichen vSwitch-Ports verbunden, haben jedoch dieselbe Portgruppe

Im nächsten Beispiel ist VM1 ist mit dem virtuellen Switch vSwitch1 und VM2 mit dem virtuellen Switch vSwitch2 verbunden, beide sind jedoch mit derselben Portgruppe mit dem Namen „Production“ verbunden und beide VMs laufen auf demselben ESXi-Host mit dem Namen ESX1. Der Netzwerkverkehr zwischen VM1 und VM2 wird über eine physische NIC auf vSwitch1 und dann zu einem physischen Switch geleitet und anschließend zu einer auf dem vSwitch2 angeschlossenen physischen NIC zurückgesendet und erreicht dann VM2.

Hier sorgen die beiden unterschiedlichen vSwitche auf ESX1 dafür, dass sich die beiden VMs aus Layer-2-Sicht trotz gleich benannter Portgroups sozusagen „physikalisch“ in unterschiedlichen Layer-2-Segmenten befinden, obwohl sie offensichtlich im gleichen (oder Keinem) VLAN sind (gleiche Bezeichnung, gleiche Farbe).  Für die Route ist das der gleiche Fall als wären beide VMs wie oben in unterschiedlichen VLANs am gleichen vSwitch.

VMs auf verschiedenen ESX-Hosts mit  verschiedenen vSwitch- und Portgruppen

Im nächsten Beispiel läuft VM1 auf einem ESX-Host mit dem Namen „ESX1“ und ist mit dem virtuellen Switch mit dem Namen „vSwitch1“ und der Portgruppe mit dem Namen „Production „verbunden. VM2 läuft auf einem ESX-Host mit dem Namen „ESX2“ und ist mit einem virtuellen Switch mit dem Namen „vSwitch1“ und der Portgruppe „TestDev“ verbunden. Der Netzwerkverkehr zwischen VM1 und VM2 wird über eine physische NIC auf vSwitch1 auf ESX1 und dann auf den physischen Switch übertragen und dann zu einer physischen NIC zurückgeleitet, die an den vSwitch1 des ESX-Hosts angeschlossen ist, und erreicht dann VM2.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.