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


    Tags: ,

    VM-Migration durch DRS mittels vMotionDas Entwerfen eines vMotion-Netzwerks ist eine Heraus­forderung, wenn man vMotion so viel Band­breite wie möglich bieten möchte, ohne andere Netzwerk­verkehrs­ströme wie iSCSI oder vSAN zu beein­trächtigen. Beim Einsatz eines Distributed vSwitch (DVS) kann man dafür Network I/O Control (NIOC) in Betracht ziehen.

    NIOC bietet ins­besondere in Version 3 (ab vSphere 6) mehrere Tools zur Band­breiten­verwaltung, 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 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

    In 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.

    Aktiviert man NIOC am Distributed vSwitch, dann erschinen  7 vordefinierte System-Netzwerk-Ressource-Pools.

    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.

    vMotion konsumiert nur im Konkurrenzfall immer 50 Shares pro physischem Adapter.

    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 dieser 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.

    Tuning von vMotion durch Einrichten eines separaten TCP/IP-Stacks.

    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.

    Keine Kommentare