Möchte man vMotion mit Lastausgleich über mehrere VMKnic betreiben, dann muss jede physische Netzwerkkarte im gesamten vMotion-Netzwerk auf allen Hosts eines Clusters auf die gleiche Weise konfiguriert sein. Zu den relevanten Parametern zählen hier Verbindungsgeschwindigkeit, MTU oder Duplex-Modus.
vCenter Server ist in Bezug auf korrekt konfiguriertes vMotion sehr konservativ und reduziert die Anzahl gleichzeitiger vMotion-Vorgänge auf nicht konsistent konfigurierten Hosts automatisch auf 2, unabhängig von der verfügbaren Bandbreite. Natürlich müssen auch sämtliche vMotion-VMknics im selben Subnetz sein, denn vMotion unterstützt keine ge-routeten Topologien, auch wenn es theoretisch möglich wäre, statische Routen festzulegen.
NIC-Zahl
Eine Erhöhung der NIC-Zahl für vMotion führt nicht automatisch zu mehr gleichzeitig möglichen vMotion-Vorgängen, auch wenn die Verwendung mehrerer Netzwerkkarten die verfügbare Bandbreite für VM-Migration erhöht. Grundsätzlich sind immer nur vier gleichzeitige vMotion-Vorgänge bei Verwendung eines 1-GBit-Adapters und maximal acht bei 10-Gbit-Uplinks möglich. Die Erhöhung der Bandbreite verringert jedoch die Dauer jeder einzelnen vMotion. Eine korrekte Multi-NIC-vMotion-Konfiguration sähe demnach so aus:
Verbindungsgeschwindigkeit
Die maximal vier bzw. acht gleichzeitigen vMotion-Vorgänge auf einem Host mit einem Netzwerk von 1 GBit/s bzw. 10 GBit/s hängen von der erkannten Verbindungsgeschwindigkeit ab. Die Betonung liegt auf „erkannt“.
Als Beispiel sei HPEs Flex-Technologie angeführt. Diese setzt ein hartes Limit für die Flexibilität, was dazu führt, dass die gemeldete Verbindungsgeschwindigkeit der konfigurierten Bandbreite auf der virtuellen Flex-Verbindung entspricht oder sogar darunter liegt. In diesem Fall bietet HPE Flex zwar mehr Bandbreite pro VMotion-Prozess, erhöht jedoch nicht die Anzahl gleichzeitiger VMotion-Operationen.
Die vMotion-Grenzwerte für mehrere NICs werden immer von der langsamsten verfügbaren NIC bestimmt. Nimmt der Nutzer also eine 1Gb/s-Netzwerkkarte in seine 10-Gb/s-VMotion-Konfiguration auf, ist dieser Host auf maximal vier gleichzeitige VMotion-Vorgänge beschränkt.
Failover-Anordnung
Die vernünftigste Failover-Order bei Multiple-NIC-vMotion ist Active/Standby. Dabei drängt sich allerdings die Frage auf, warum nicht einfach Active/Unused nehmen? Schließlich ist das für iSCSI-Storage-Multipathing auf Basis des Software-iSCSI-Adapters und mehreren VMKnics für die so erzwungene dedizierte Portbindung so erforderlich.
Denkt man etwas genauer darüber nach, könnte man meinen, dass die Standby-Option keinen Vorteil bringt, weil der Lastausgleich ja gar nicht auf Basis der physischen Adapter abgewickelt wird und jeder VMKernel-Adapter ohnehin nur auf einer NIC arbeitet. Der Grund, trotzdem Active/Failover zu wählen, liegt in der Wahl des so genannten Default-Interfaces. Dazu müssen wir etwas ausholen.
Default-Interface
Für den Lastausgleich von VMotion ist ein eigener Algorithmus zuständig. Da sich vMotion auf die VMknic-Schicht statt auf die physische Schicht konzentriert, kümmert sich die vMotion-Lastausgleichslogik aber nicht um den Verbindungsstatus oder den Zustand der physischen Netzwerkkarte.
Der Algorithmus wählt einfach nur geeignete VMknics für die Verteilung von Netzwerkpaketen und geht dabei davon aus, dass die VMknics grundsätzlich Konnektivität haben. Allerdings deklariert der vMotion-Algorithmus, auch wenn er mehrere VMknics zum Lastausgleich des Datenverkehrs verwendet, immer genau einen davon als so genannte Standardschnittstelle und bevorzugt diese für die „Verwaltung“ der Verbindung.
Daher ist es bei VMKernel-Adaptern mit mehrere physische Netzwerkkarten sinnvoll, den Ausfall einer physischen Netzwerkkarte durch ein Standby-Interface zu kompensieren, weil das Default-Interface dann weiter verfügbar bleibt und keine Verbindungsprobleme auftreten, wenn das es eine physische Netzwerkkarte verliert.