vMotion-Tuning: Network I/O-Control und eigener TCP/IP-Stack

So bietet  NIOC unter anderem eine QoS-Option, die es vMotion im Normal­betrieb erlaubt (also solange keine Konflikte um Ressourcen auftreten), so viel Bandbreite wie möglich zu nutzen. In dem Moment, in dem eine physische Netzwerk­karte ü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 Netzwerk­karte 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 ein­gehenden Datenverkehr. In ESXi beziehen sich Angaben wie Eingangs- und Ausgangs­verkehr (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. Ausgangs­datenverkehr (Egress) hingegen bewegt sich vom verteilten vSwitch zum physischen NIC oder zum vNIC.

Das ist  insbe­sondere deshalb wichtig, weil NIOC nur den eingehenden Daten­verkehr 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 beispiel­weise 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 Voraus­setzung, 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 netzwerk­technischen Voraus­setzungen 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.