vMotion: Verbindungsgeschwindigkeit, Failover-Anordnung, Standard-Schnittstelle Multi-NIC vMotion - Teil 2

Möchte man vMotion mit Last­ausgleich über mehrere VMKnic be­treiben, dann muss jede physische Netzwerk­karte im gesamten vMotion-Netzwerk auf allen Hosts eines Clusters auf die gleiche Weise konfiguriert sein. Zu den relevanten Para­metern zählen hier Ver­bindungs­geschwin­digkeit, 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 Band­breite. 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 Netzwerk­karten 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:

Der Lastausgleich erfolgt auf Ebene der VM-Kernel-Adapter und nicht der physischen NICs.

 

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 Verbindungs­geschwindig­keit 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 Verbindungs­geschwindig­keit 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-Netzwerk­karte 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 Verbindungs­status oder den Zustand der physischen Netzwerk­karte.

Ein physischer Standy-Adapter für einen VMotion-VMKernel-Adapter verhindert beim Ausfall einer physischen NIC, dass vMotion seinen Default-VMKernel-Adapter behält.

 

Der Algorithmus wählt einfach nur geeignete VMknics für die Verteilung von Netzwerk­paketen 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 Daten­verkehrs verwendet, immer genau einen davon als so genannte Standard­schnittstelle und bevorzugt diese für die „Verwaltung“ der Verbindung.

Daher ist es bei VMKernel-Adaptern mit  mehrere physische Netzwerk­karten sinnvoll, den Ausfall einer physischen Netzwerk­karte durch ein Standby-Interface zu kompensieren, weil das Default-Interface dann weiter verfügbar bleibt und keine Verbindungs­probleme auftreten, wenn das es eine physische Netzwerk­karte verliert.

Hier weiterlesen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.