Performance von VMware vMotion erhöhen durch Multi-NIC-Setup


    Tags: , ,

    VM-Migration durch DRS mittels vMotionDas von VMware schon 2003 ent­wickelte vMotion erlaubt einen unter­brechungs­losen Umzug von laufen­den virtu­ellen Maschinen zwischen ESXi-Servern, etwa für die Hardware-Wartung oder zur manu­ellen bzw. auto­matischen (DRS) Last­verteilung. Die parallele Nutzung mehrerer Netz­werk­karten be­schleunigt diesen Vor­gang.

    vMotion ist das eigentliche Killer-Feature, das aus einem Produkt für die Server-Konsolidierung eine Business-Continuity-Lösung machte. Mit vMotion muss nämlich ein Rechen­zentrum keinen Ausfall von Anwendungen mehr hin­nehmen, nur weil einige Infrastruktur­komponenten ersetzt werden müssen.

    VMware hat das vMotion-Feature über die Jahre immer weiter ausgebaut. Hier die technologische Timeline zu vMotion bis vSphere 6.0, noch ohne Encrypted vMotion, das in der Version 6.5 hinzukam:

    Historische Entwicklung von vMotion

    Grundlegendes Netzwerk-Design für vMotion

    Vor vSphere 5 war das Entwerfen eines vMotion-Netzwerks relativ einfach. Man wählte nach Möglich­keit die schnellste physische Netzwerk­karte aus und fügte diese einem vMotion-Kernel-Adapter (VMknic) hinzu. So unter­stützte beispiels­weise schon vSphere 4.x Netzwerke mit 1 GB und 10 GB.

    Die Einrichtung in Kurzform:

    1. VMkernel-Adapter auf einen Standard-vSwitch erstellen
    2. vMotion-Checkbox aktivieren
    3. IP-Adresse von Quell- und Ziel-Host im gleichen Subnetz, ggf. auch gleiches VLAN
    4. Zuweisen einer physikalischen NIC

    Einfache Netzwerkkonfiguration für vMotion mit einer physischen NIC

    Multiple-NIC-vMotion

    vSphere verteilt seit der Version 5.x vMotion-Vorgänge stets auf alle dafür verfügbaren Netzwerk­karten. Das gilt sowohl für eine einzelne als auch für mehrere gleichzeitige VM-Migrationen. So lässt sich durch Verwenden mehrerer NICs die Dauer eines vMotion-Vorgangs reduzieren.

    Das bietet gleich mehrere Vorteile:

    Manuelle vMotion-Prozesse: Weist man dem vMotion-Prozess indirekt mehr Bandbreite zu, verkürzt das allgemein die Migrations­zeiten.

    DRS-Lastausgleich: Aufgrund der kürzeren Zeit pro Migration und der höheren Anzahl der gleichzeitigen vMotion-Prozesse reduziert DRS bei Multiple-NIC-vMotion die Anzahl der Last­ausgleichs­vorgänge zwischen zwei Last­ausgleichs­läufen.

    Dies kommt wiederum dem Load-Balancing des Clusters insgesamt zugute. Ein besserer Lastausgleich bewirkt eine höhere Verfügbarkeit von Ressourcen für die virtuellen Maschinen, was zu einer besseren Leistung für die Anwendungen führt.

    Wartungsmodus: Kürzere Migrations­zeiten bedeuten auch, dass ein einzelner Host weniger Zeit benötigt, um in den Wartungs­modus zu wechseln. Mit einem höheren Konsoli­dierungsgrad nimmt insgesamt die Zeit zu, die für die Migration aller virtuellen Maschinen vom Host erforderlich ist.

    Multi-NIC-Setup

    Der VMotion-Prozess nutzt für den Lastausgleich immer den VMKernel-Port (VMknic), anstatt Pakete direkt an eine physische Netzwerk­karte zu senden. Um also mehrere NICs für vMotion verwenden zu können, benötigt man mehrere VMKernel-Adapter.

    Dabei ist für die Failover-Reihenfolge und Lastausgleichs­richtlinie Folgendes zu berücksichtigen:

    • Jeder VMknic darf nur eine aktive Netzwerk­karte verwenden. Damit ist die einzige zulässige Lastaus­gleichsrichtlinie "Route basierend auf dem ursprünglichen virtuellen Port" (Route based on virtual port id).
    • Dieses Setup schließt die beiden Regeln für den physischen NIC-Lastausgleich ("IP-Hash" oder "Lastaus­gleichs­richtlinie basierend auf der physischen Last (LBT)" (nur für Distributed vSwitch) aus. Damit ist die einzige sinnvolle Failover-Reihenfolge Active/Standby.

    Der Grund dafür liegt in der Funktions­weise des vMotion-Lastausgleichs, der seinen eigenen Algorithmus nutzt und nicht über eine der beiden physischen Lastaus­gleichsregeln erfolgt. Unter anderem deswegen wird der vMotion-Traffic auf einem eigenen VMKernel-Adapter mit "vMotion" getaggt.

    Da vMotion davon ausgeht, dass unter jeder VMknic nur eine einzelne physische NIC liegt, stellt das Senden von Daten über einen bestimmten VMknic sicher, dass vMotion die Daten über exakt diesen dedizierten physischen NIC überträgt.

    Schematische Darstellung des Lastausgleichs von vMotion zwischen mehreren NICs

    Konfiguriert man hingegen die physischen NICs in einem Lastaus­gleichs­modus (IP Hash-Regel mit zwei aktiven VMknic), dann kann das die Logik auf der Ebene von vMotion beeinträchtigen. Dieses kann dann nämlich nicht vorhersagen, welche physische Netzwerkkarte vom VMknic verwendet wird.

    Unter Umständen wird dann der gesamte VMotion-Datenverkehr über dieselbe Netzwerk­karte gesendet, selbst wenn Motion die Daten an ver­schiedene VMknics schickt.

    In der obigen Abbildung werden trotzdem zwei Netzwerk­karten pro VMKernel-Adapter für vMotion verwendet, hier aber jeweils einer davon als Failover-Adapter. Dieser kann bei Ausfall des aktiven Adapters die Last übernehmen. Der Lastausgleich findet trotzdem über die Kernel-Adapter statt.

    Wollte man für vMotion nur einen VMKernel-Adapter mit zwei aktiven physischen Netzwerkkarten konfigurieren, dann würde der Konfigurations­dialog dies zwar nicht verhindern, aber der gesamte vMotion-Traffic liefe aber dann immer nur über ein und dieselbe physische NIC.

    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.

    Ähnliche Beiträge

    Weitere Links