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