Tags: vSphere, Netzwerk, Performance
Die Performance eines virtuellen Netzwerks hängt entscheidend davon ab, ob die Kommunikation zwischen den VMs rein Host-intern oder über die physische Infrastruktur läuft. Dieser Beitrag klärt, wie sich die Zuordnung einer virtuellen Maschine zu vSwitches, Portgroups und VLANs auf den Traffic-Flow auswirkt.
Als VMware-Trainer mache ich die Erfahrung, dass Networking neben Storage in jedem Kurs den größten Raum einnimmt. Eine beliebte wiederkehrende Frage ist, mit welcher Bandbreite eine virtuelle Maschine an einen virtuellen Switch angebunden ist, insbesondere vor dem Hintergrund, dass etwa 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 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 überhaupt 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 Netzwerkgeschwindigkeit erhöhen und die Latenz reduzieren kann.
Verwendet etwa die virtuelle NIC bzw. der Treiber einer ausreichend leistungsfähigen Netzwerkkarte zum Beispiel den VMNET3-Adapter, dann könnte diese ja mit dessen maximal möglichen Geschwindigkeit mit dem vSwitch kommunizieren.
Da der Netzwerkverkehr 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 miteinander kommunizieren müssen, (zum Beispiel Web-, Anwendungs- oder Datenbank-Server) auf dem gleichen Host zu platzieren.
Dies erhöht die Netzwerkgeschwindigkeit und die Netzwerklatenz 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 Netzwerkkarten 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 Netzwerkverkehr zwischen VM1 und VM2 wird hier nicht an physische Netzwerke wie Switches oder nachgeschaltete Geräte (strukturierte Verkabelung) weitergeleitet, denn die VMs können über den vSwitch kommunizieren.
In diesen Fall kann der Nutzer also eine erhöhte Netzwerkgeschwindigkeit bzw. eine geringere Netzwerklatenz erzielen, wobei die prinzipiellen Einschränkungen eines paravirtualisierten 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 Netzwerkverkehr 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 unterschiedlichen Farben und Bezeichnungen für die beiden Portgroups, für unterschiedliche VLANs oder unterschiedliche 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 unterschiedlichen Layer-2-Segmenten voneinander isoliert sind. Aufgrund der unterschiedlichen 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 Netzwerkverkehr 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ückgesendet und erreicht dann VM2.
Hier sorgen die beiden unterschiedlichen vSwitches 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 hat dies den gleichen Effekt, als wären beide VMs wie oben am gleichen vSwitch, aber in unterschiedlichen 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 Netzwerkverkehr 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ückgeleitet, die an den vSwitch1 des ESXi2-Hosts angeschlossen ist, und erreicht schließlich VM2.
Täglich Know-how für IT-Pros mit unserem Newsletter
Thomas Drilling arbeitet ist seit fast 30 Jahren selbständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehemalige und aktuelle IT-Magazine sowie Blogs.
Aktuell bestätigt sich Thomas schwerpunktmäßig als IT-Trainer für Cloud-Computing in den Bereichen Microsoft Azure, Amazon Web Services und VMware.
Thomas ist zertifizierter Microsoft-Trainer für nahe das gesamte Portfolio an Microsoft Azure Trainings. Thomas ist außerdem zertifizierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grundlagenkurse in Cloud Computing mit Azure durch, die sich inhaltlich bewusst von den Microsft-Kursen abheben und vorzuweise als Bootcamp in eine besonderen Lokation stattfinden. Optional kann aber aber auch remote via Microsoft Teams teilgenommen werden.
Das aktuelle Trainingsprogramm findet sich unter Azure-Trainings. Weitere Informationen und Anmeldung über sein Azure-Blog.
Verwandte Beiträge
Weitere Links