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.

VMware-Funktionen wie vMotion, Snapshot, Distributed Resource Scheduler (DRS), vNIC Teaming und der SR-IOV-Modus werden unterstützt. Das Klonen aus Snapshots wird jedoch nicht unterstützt.

Außerdem werden vMotion, DRS, Snapshots und vNIC-Teaming nicht unterstützt, wenn der SR-IOV-Modus aktiviert ist.

Weitere Informationen finden Sie im Datenblatt zum Cisco Catalyst 9800-CL Wireless Controller for Cloud.

Anforderungen

• Verwendung der empfohlenen getesteten Softwareversionen: 
  • ESXi vCenter 6.7 oder höher
    
  • Software C9800-CL: 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 hier vMotion gemäß den VMware-Richtlinien für Host, Remote Shared Storage und Netzwerk.
• 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 Arten der vMotion-Migration getestet: nur Rechenressourcen, nur Speicher, sowohl Rechenressourcen als auch Speicher.

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:

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 eine Computing- oder Computing- und Storage-Migration durchgeführt wird. 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 kein Reverse Address Resolution Protocol (RARP) für das drahtlose C9800-CL-Management-VLAN senden, 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: einen kontinuierlichen Ping vom C9800-CL zu einem beliebigen kabelgebundenen Host zu starten, bevor die Migration durchgeführt wird; Dadurch erfährt das Switch-Netzwerk mehr über den neuen Standort (Port) der VM und kann daher schneller 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 können während des SSO-Failovers auf 17.9 stecken bleiben

Zusammenfassung

VMware vSphere vMotion kann verwendet werden, um die virtuelle Maschine C9800-CL von einem Host zum anderen zu migrieren, ohne den Betrieb des Wireless-Netzwerks zu beeinträchtigen.  vMotion wird vom C9800-CL ab Version 17.9.2 unterstützt.