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


    Tags: , ,

    Traffic Flow in vSphere abhängig von vSwitch, Portgroups und VLANsDie Performance eines virtu­ellen Netz­werks hängt ent­scheidend davon ab, ob die Kommu­nikation zwischen den VMs rein Host-intern oder über die phy­sische Infra­struktur läuft. Dieser Bei­trag klärt, wie sich die Zuor­dnung einer virtu­ellen Maschine zu vSwitches, Port­groups und VLANs auf den Traffic-Flow aus­wirkt.

    Als VMware-Trainer mache ich die Erfahrung, dass Networking neben Storage in jedem Kurs den größten Raum ein­nimmt. Eine beliebte wieder­kehrende Frage ist, mit welcher Band­breite eine virtuelle Maschine an einen virtuellen Switch angebunden ist, insbesondere vor dem Hintergrund, dass etwa der para­virtualisierte VMNET3-Adpter ein 10Gbit/s-Adapter ist.

    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.

    Verschiedene Kombinationen aus vSwitch, Portgroups und VLANs bestimmen die Performance und Latenz beim Traffic zwischen VMs.

    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.

    Szenario 1: VMs an gleichem vSwitch und an gleicher Portgruppe

    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.

    Szenario 2: VMs am gleichen vSwitch, aber an verschiedenen Portgroups

    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.

    Szenario 3: VMs an verschiedenen vSwitches, aber an der gleichen Portgroup

    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.

    Szenario 4: VMs auf verschiedenen Hosts an vSwitches mit dem gleichen Namen

    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.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Thomas Drilling

    Thomas Drilling arbeitet ist seit fast 30 Jahren selb­ständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehe­malige 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 zerti­fi­zierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grund­lagenkurse 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 Infor­mationen und Anmel­dung über sein Azure-Blog.

    Verwandte Beiträge

    Weitere Links