Tags: vSphere, Netzwerk
Das Entwerfen eines vMotion-Netzwerks ist eine Herausforderung, wenn man vMotion so viel Bandbreite wie möglich bieten möchte, ohne andere Netzwerkverkehrsströme wie iSCSI oder vSAN zu beeinträchtigen. Beim Einsatz eines Distributed vSwitch (DVS) kann man dafür Network I/O Control (NIOC) in Betracht ziehen.
NIOC bietet insbesondere in Version 3 (ab vSphere 6) mehrere Tools zur Bandbreitenverwaltung, mit denen sich auch das vMotion-Netzwerk gestalten lässt.
QoS über Network I/O Control
So bietet NIOC unter anderem eine QoS-Option, die es vMotion im Normalbetrieb erlaubt (also solange keine Konflikte um Ressourcen auftreten), so viel Bandbreite wie möglich zu nutzen. In dem Moment, in dem eine physische Netzwerkkarte überlastet ist, verteilt NIOC die Bandbreite dann gemäß der relativen Shares-Werte der jeweiligen Network-Ressource-Pools.
Auch hier kümmert sich vMotion auf Ebene der VM-Kernel-Adapter selbst um den Lastausgleich. Trotzdem verwenden wir je eine NIC für Standby bzw. Failover. Hat jedoch die entsprechende DVS-Portgroup mehr als zwei Uplinks konfiguriert, werden alle redundanten Uplinks (mit Ausnahme der zwei für Active/Standby) als "Unused" markiert.
Dies kann der Fall sein, weil etwa der Distributed Switch selbst, auf dem die VMKernel-Portgroup definiert ist, 4 oder mehr Uplinks benötigt.
vMotion-Network-Ressource-Pool
Im folgenden Beispiel ist jeder Host mit einem Distributed vSwitch verbunden und verfügt über je zwei Uplink-Adapter. Dabei ist je ein virtueller Adapter mit aktiviertem VMotion mit je einem dieser Uplinks verbunden und vMotion kann beide physischen Adapter nutzen, um vMotion-Datenverkehr zu senden.
Sobald wir NIOC auf dem Distributed vSwitch einschalten, werden 7 vordefinierte System-Netzwerk-Ressource-Pools aktiv, einer davon für vMotion. Das bedeutet, dass der vMotion-Datenverkehr an den Netzwerk-Ressource-Pool des vMotion-Systems gebunden wird.
Kommt es zu einen Wettstreit um Bandbreite, dann gelten die vordefinierten Shares-Werte (50 = normal) auf der physischen Adapterschicht.
Da vMotion beide Uplinks verwenden kann, konsumiert vMotion (nur im Konkurrenzfall) immer 50 Shares pro physischem Adapter. Zur Erinnerung: Shares wirken sich im Gegensatz zu Reservations und Limits immer nur dann aus, wenn vMotion tatsächlich parallel zu anderen Traffic-Mustern aktiv ist.
Ist vMotion nicht aktiv, werden Shares auch nicht beachtet, wenn ein Adapter überlastet ist. Verwendet vMotion nur einen einzelnen Uplink, sind nur 50 Shares aktiv.
Ansonsten gilt: Obwohl die Uplink-Portgruppe mit 2 Uplinks konfiguriert ist, wird je einer als Standby konfiguriert. Solange die aktive Netzwerkkarte normal funktioniert, kann die Standby-Verbindung also nicht verwendet werden. Tatsächlich nutzt vMotion immer nur eine Verbindung und die erwähnten 50 Shares werden im Falle einer Überlastung angerechnet.
NIOC nur für Ingress
Aber Achtung: NIOC-Shares und -Limits gelten nur für eingehenden Datenverkehr. In ESXi beziehen sich Angaben wie Eingangs- und Ausgangsverkehr (etwa auch bei der Konfiguration von Traffic Shaping) immer auf die Sicht des Distributed vSwitches.
Ingress ist also Datenverkehr, der von einem VMKernel-Adapter des Hosts oder einer vnic der ausgeführten VM kommt und zum Distributed vSwitch fließt. Ausgangsdatenverkehr (Egress) hingegen bewegt sich vom verteilten vSwitch zum physischen NIC oder zum vNIC.
Das ist insbesondere deshalb wichtig, weil NIOC nur den eingehenden Datenverkehr steuert, der vom ESXi-Host initiiert wird. Wir können also problemlos auch einen Grenzwert für den vMotion-Netzwerk-Ressource-Pool festlegen, weil sich dieser nur auf den Datenverkehr auswirkt, der innerhalb des Hosts zum Uplink gesendet wird.
Hat man beispielweise einen Cluster mit wenigen Hosts, in dem gerade mehrere vMotion-Vorgänge an einen Host gesendet werden, kann allerdings auch NIOC nicht verhindern, dass der eingehende Datenverkehr die Uplinks überlastet. Um auch diese Situation zu vermeiden, muss auf den beteiligten DVS-Portgroups Traffic Shaping konfiguriert werden.
Cross-vCenter und Long Distance vMotion
Seit vSphere 6.0 unterstützt vMotion auch das Verschieben von virtuellen Maschinen über vCenter- oder WAN-Grenzen hinweg. Für Cross-vCenter-vMotion ist die einzige Voraussetzung, dass beide vCenter im Enhanced- oder Embedded Linked Mode verknüpft und zeitsynchron sind. Ferner müssen die beteiligten vMotion-Adapter im gleichen Subnetz sein.
Bei Long-Distance-vMotion sind zusätzlich die netzwerktechnischen Voraussetzungen zu beachten. Im Virtual Machine Network (Layer-2-Verbindung) muss sichergestellt sein, dass die bestehende IP-Adresse in der Umgebung des Ziel-Hosts auch verwendet werden kann.
Das vMotion-Netzwerk hingegen ist jetzt eine Layer-3-Verbindung, die sich aus diesem Grund ab vSphere 6.5 auch verschlüsseln lässt. Außerdem müssen hier eine Bandbreite von mindestens 250 Mb/s sowie einer Roundtrip-Time von 150ms garantiert sein.
Eine letzte Tuning-Maßnahme für vMotion besteht in der Verwendung eines separaten TCP/IP-Stacks für vMotion mit eigenem Heap, eigenem Default-Gateway, eigener ARP-Table und eigener Routing-Table.
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
- vMotion mit mehreren NICs: Verbindungsgeschwindigkeit, Failover-Anordnung, Standard-Schnittstelle
- Performance von VMware vMotion erhöhen durch Multi-NIC-Setup
- 2-Knoten-vSAN-Cluster mit Direct Connect einrichten
- Tipps und Tools für die Diagnose von Netzwerkproblemen in VMware vSphere
- Traffic-Flow mit vSwitches: Wann läuft die VM-Kommunikation über das physische Netzwerk?
Weitere Links