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

    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.

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

    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.

    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 seit mehr als 20 Jahren selb­ständig als Redakteur und Autor für viele ehe­malige und aktuelle IT-Magazine sowie Blogs. Thomas ist zudem Buch­autor und IT-Consultant. Seit 5 Jahren ist Thomas neben seiner journa­listischen Tätig­keit haupt­beruflicher, selb­ständiger IT-Trainer für VMware und Microsoft.

    Seine Themen­schwer­punkte sind Virtua­lisierung und Cloud Com­puting, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zerti­fi­zierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas ist außerdem zertifi­zierter AWS Solu­tions Archi­tect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Admini­strator.

    Thomas führt aktuell jeden zwei­ten Mon­tag einen 4-tägigen Grund­lagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Infor­mationen und Anmel­dung über sein AWS-Blog.

    Verwandte Beiträge

    Weitere Links