Unterstützung von VMware vSphere vMotion auf Catalyst 9800

Einleitung

In diesem Dokument werden die Tests zur Überprüfung der vMotion-Unterstützung für den C9800-CL beschrieben, der auf vSphere ESXi ausgeführt wird.

Voraussetzungen

C9800-CL ist der Formfaktor virtueller Systeme für den Catalyst 9800 Wireless LAN Controller. Sie können VMware vSphere vMotion verwenden, um eine Live-Migration von Catalyst 9800-CL von einem Host-Server auf einen anderen ohne Ausfallzeiten durchzuführen. Diese Funktion ist über vSwitches und Cluster hinweg möglich. Das Ziel besteht darin, dass das Wireless-Netzwerk während der Live-Migration des C9800-CL verfügbar bleibt und die Wireless-Benutzer weiterhin über die erforderliche Konnektivität verfügen.

vMotion kann manuell oder als Teil einer VMware vSphere Distributed Resource Scheduler (DRS)-Konfiguration durchgeführt werden. DRS verteilt die Workloads der virtuellen Systeme auf die vSphere-Hosts in einem Cluster und überwacht die für Sie verfügbaren Ressourcen. Basierend auf Ihrer Automatisierungsstufe migriert DRS virtuelle Systeme zu anderen Hosts im Cluster, um die Leistung zu maximieren. Obwohl DRS zusätzlich zu vMotion und damit auch die Live-Migration funktioniert, wurden DRS-spezifische Szenarien noch nicht getestet und werden daher offiziell nicht unterstützt.

Anforderungen

• Verwendung der empfohlenen getesteten Softwareversionen: 
  • ESXi vCenter 6.7 oder höher
    
  • C9800-CL Software: 17.9.2 und höher
    
• Die Latenz (RTT) zwischen dem Remote-Speicher und dem Server, auf dem C9800-CL ausgeführt wird, muss < 60 ms betragen.
• Die virtuelle Maschine C9800-CL darf keine ESXi-Host-spezifische Korrespondenz wie CD/DVD, serielle Konsolenport-Verbindung usw. aufweisen.
• Konfigurieren Sie vMotion gemäß den VMware-Richtlinien für Host, Remote Shared Storage und Netzwerk hier .
• Die VMware-Netzwerkanforderungen für vMotion finden Sie hier .

Topologie

Für diese Verifizierungstests wurde eine einfache Topologie mit drei verschiedenen Server-Hosts und iSCSI-Remote-Speicher verwendet (NFS-Speicher kann ebenfalls verwendet werden). Der Remote-Speicher nutzt eine 10-Gbit/s-Verbindung zu den Servern. Auf dem ESXi-Host wird eine virtuelle C9800-CL-VM im Standalone-Modus erstellt, und zwei weitere virtuelle C9800-CL-Maschinen werden für Stateful Switchover High Availability (SSO HA) konfiguriert. Das HA-Paar wird aus Gründen der physischen Redundanz auf zwei verschiedenen Servern erstellt, sodass der aktive und der Standby-WLC separat migriert werden können. Jede virtuelle C9800-CL ist über drei Ports mit dem virtuellen Switch verbunden: 

• G1 > SP-Port (optional)
• G2 > Trunk-Port für WMI-VLAN (Wireless Management Interface) und Client-VLANs (falls vorhanden)
• G3 > RP-Port. Dies gilt für die Erstellung des SSO-Clusters. Im Standalone-Modus nicht verbunden

Jeder Host-Server verfügt über einen dedizierten physischen Port und einen dedizierten Switch (Switch Nr. 1), um die RP-Ports über einen L2-Link auf den Servern miteinander zu verbinden. Die beiden anderen physischen Ports sind mit einem separaten Uplink-Switch (Switch Nr. 2) verbunden. Ein Diagramm, das die Testtopologie darstellt:

Testergebnisse

Für diese Tests wurden zwei Migrationsszenarien berücksichtigt:

1. Ein eigenständiger C9800-CL wird zwischen Server #1 und Server #2 migriert.
2. Ein Paar C9800-CL, konfiguriert als SSO mit hoher Verfügbarkeit. In diesem Fall wird zuerst der aktive Server zwischen Server #1 und Server #3 migriert, und dann der Standby-WLC von Server #2 auf Server #3.

In beiden Fällen wurden alle drei verschiedenen Typen der vMotion-Migration getestet: nur Computing-Ressourcen, nur Storage, sowohl Computing als auch Storage.

Um vMotion auszulösen, klicken Sie mit der rechten Maustaste auf das virtuelle System, und klicken Sie auf "Migrieren":

Wählen Sie die Art der Migration aus, und gehen Sie wie folgt vor:

Hier das Ergebnis der einzelnen Tests:

Test	Standalone C9800-CL	vMotion-Typ	Beobachtungen/Kommentare
1		Nur Rechenressource	Nicht unterstützt: APs und Clients gehen verloren, die sich nach einiger Zeit aufgrund von Virtual Guest Tagging (802.1q VLAN)-Problemen erholen: KB-Artikel Problemumgehung: Kontinuierliches Ping-Signal vom Controller an ein beliebiges kabelgebundenes Netzwerkgerät starten
2		Nur Storage	Unterstützt: APs und Clients sind stabil, Single-Ping-Drop wird erkannt
3		Rechenressourcen und Speicher	Nicht unterstützt: APs und Clients gehen verloren, die sich nach einiger Zeit aufgrund von Virtual Guest Tagging (802.1q VLAN)-Problemen erholen: KB-Artikel Problemumgehung: Kontinuierliches Ping-Signal vom Controller an ein beliebiges kabelgebundenes Netzwerkgerät starten
Test	SSO aktiv HA-Keepalive: 100 ms	vMotion-Typ
4		Nur Rechenressource	Unterstützt: Datenverkehr ist bei aktivem Standby-Stack stabil, erneutes Laden wird aufgrund abgelaufener HA-RP-Keepalives erkannt
5		Nur Storage	Unterstützt: Der Datenverkehr ist stabil. Der RP wird meistens aktiviert, bevor der RP-Keepalives-Timer abgelaufen ist, sodass keine Stapelzusammenführung erkannt wird.
6		Rechenressourcen und Speicher	Unterstützt: Standby wechselte in den Standby-Wiederherstellungsstatus und wurde aufgrund der Stapelzusammenführung neu geladen.
Test	SSO aktiv HA-Keepalive: 200 ms	vMotion-Typ
7		Nur Rechenressource	Unterstützt: APs und Clients sind stabil, Single-Ping-Drop ist auf aktiv, Standby ebenfalls stabil
8		Nur Storage	Unterstützt: APs und Clients sind stabil, Single-Ping-Drop ist auf aktiv, Standby ebenfalls stabil
9		Rechenressourcen und Speicher	Unterstützt: APs und Clients sind stabil, Single-Ping-Drop ist auf aktiv, Standby ebenfalls stabil
Test	SSO-Standby HA-Keepalive - 100 ms	vMotion-Typ
10		Nur Rechenressource	Unterstützt: APs und Clients sind im aktiven Zustand stabil und stehen auch nach dem vMotion-Vorgang stabil. In manchen Fällen kann es vorkommen, dass Standby-Stack-Zusammenführungen neu geladen werden.
11		Nur Storage	Unterstützt: APs und Clients sind im aktiven Zustand stabil und stehen auch nach dem vMotion-Vorgang stabil. In manchen Fällen kann es vorkommen, dass Standby-Stack-Zusammenführungen neu geladen werden.
12		Rechenressourcen und Speicher	Unterstützt: APs und Clients sind im aktiven Zustand stabil und stehen auch nach dem vMotion-Vorgang stabil. In manchen Fällen kann es vorkommen, dass Standby-Stack-Zusammenführungen neu geladen werden.
Test	HA-Standby HA-Keepalive - 200 ms
13		Nur Rechenressource	Unterstützt: APs und Clients sind im aktiven Zustand stabil und stehen auch nach dem vMotion-Betrieb stabil
14		Nur Storage	Unterstützt: APs und Clients sind im aktiven Zustand stabil und stehen auch nach dem vMotion-Betrieb stabil
15		Rechenressourcen und Speicher	Unterstützt: APs und Clients sind im aktiven Zustand stabil und stehen auch nach dem vMotion-Betrieb stabil

Wie aus dieser Tabelle ersichtlich, schlägt vMotion im ersten und dritten Szenario (Test #1 und #3) mit dem Standalone-Modus C9800-CL fehl, da dieser eine Computing- oder Computing- und Storage-Migration durchführt. In diesem Fall werden die MAC- und IP-Adresse des WMI des C9800-CL auf den neuen Host und damit auf einen anderen Switch-Port verschoben. vMotion kann Reverse Address Resolution Protocol (RARP) für das drahtlose C9800-CL-Management-VLAN, da der ESXi-Host nicht erkennen kann, welches VLAN vom Gastbetriebssystem verwendet wird, das auf der virtuellen Maschine ausgeführt wird. Um dieses Szenario zu unterstützen, müssen Sie eine Problemumgehung implementieren: Starten Sie einen kontinuierlichen Ping vom C9800-CL zu einem beliebigen kabelgebundenen Host, bevor dieser die Migration durchführt. Dies veranlasst das Switch-Netzwerk, Informationen über den neuen Standort (Port) des virtuellen Systems zu erhalten und somit schneller zu konvergieren.

Im Fall der analogen Migration mit HA SSO (z. B. Test #4) wird die Redundanz-Management-Schnittstelle (RMI) verwendet, um die Erreichbarkeit zum Gateway sowie zwischen Active und Standby zu überprüfen. Dadurch wird der Datenverkehr generiert, der die MAC-Adresstabelle auf dem Switch aktualisiert, und das Problem tritt nicht auf.

Empfehlung: Für optimale Ergebnisse wird empfohlen, RP-Port-Keepalives auf mindestens das Doppelte des standardmäßigen 100 ms-Keepalive (200 ms) zu konfigurieren. Wenn das Netzwerk zwischen Speicher und Hosts ausgelastet werden und die Latenz erhöhen kann, sollten Sie den Keepalive-Timer auf 300 ms einstellen. Um den Keepalive-Timer in der GUI zu konfigurieren, gehen Sie zu Administration > Device > Redundancy:

Verwenden Sie diesen Befehl in der CLI im exec-Modus (nicht im Konfigurationsmodus).

C9800-SSO#chassis redundancy keep-alive timer 3 

Verwenden Sie den folgenden Befehl, um zu überprüfen:

C9800-SSO#sh chassis ha-status active  

 

                      My state = ACTIVE 

                    Peer state = STANDBY HOT 

        Last switchover reason = none 

          Last switchover time = none 

                 Image Version = 17.9.1 

 

Chassis-HA   Local-IP         Remote-IP        MASK             HA-Interface 

----------------------------------------------------------------------------- 

This Boot: 169.254.201.23   169.254.201.24   255.255.255.0                       

 

Next Boot: 169.254.201.23   169.254.201.24   255.255.255.0                       

 

 

Chassis-HA   Chassis#    Priority        IFMac Address         Peer-timeout(ms)*Max-retry 

Shape----------------------------------------------------------------------------------------- 

This Boot:    1             1                                      300*5 

 

Next Boot:    1             1                                      300*5 

Gelöste Vorbehalte:

Dies sind die in 17.9.2 behobenen Vorbehalte:

Cisco Bug-ID CSCwd17349 - C9800: Aktive Chassis bleiben möglicherweise während des SSO-Failovers auf 17.9 hängen

Zusammenfassung

VMware vSphere vMotion kann verwendet werden, um das virtuelle System C9800-CL von einem Host zum anderen zu migrieren, ohne dass dies Auswirkungen auf den Betrieb des Wireless-Netzwerks hat. vMotion wird auf dem C9800-CL ab Version 17.9.2 offiziell unterstützt.