Prise en charge de VMware vSphere vMotion sur Catalyst 9800

Introduction

Ce document décrit les tests effectués pour vérifier la prise en charge de vMotion pour le C9800-CL qui s'exécute sur vSphere ESXi.

Conditions préalables

C9800-CL est le format de machine virtuelle du contrôleur LAN sans fil Catalyst 9800. Vous pouvez utiliser VMware vSphere vMotion pour effectuer une migration dynamique sans temps d'arrêt du Catalyst 9800-CL d'un serveur hôte à un autre. Cette fonctionnalité est possible sur l'ensemble des commutateurs virtuels et des clusters. L'objectif est que, lors de la migration dynamique du C9800-CL, le réseau sans fil reste opérationnel et que les utilisateurs sans fil continuent à disposer de la connectivité dont ils ont besoin.

vMotion peut être effectué manuellement ou dans le cadre d'une configuration VMware vSphere Distributed Resource Scheduler (DRS). DRS répartit les charges de travail des machines virtuelles sur les hôtes vSphere au sein d'un cluster et surveille les ressources disponibles pour vous. En fonction de votre niveau d'automatisation, DRS migre les machines virtuelles vers d'autres hôtes au sein du cluster afin d'optimiser les performances. Bien que DRS fonctionne sur vMotion, et donc que la migration dynamique fonctionne de la même manière, les scénarios spécifiques à DRS n'ont pas été testés à ce stade et ne sont donc pas officiellement pris en charge.

Exigences

• Utilisez les versions logicielles testées recommandées : 
  • ESXi vCenter 6.7 ou plus tard
    
  • Logiciel C9800-CL : 17.9.2 et versions ultérieures
    
• La latence (RTT) entre le stockage distant et le serveur sur lequel le C9800-CL est exécuté doit être inférieure à 60 ms
• La machine virtuelle C9800-CL ne doit pas avoir de correspondance spécifique à l'hôte ESXi, comme un CD/DVD, une connexion de port de console série, etc.
• Configurez vMotion conformément aux directives VMware pour l'hôte, le stockage partagé distant et la mise en réseau ici .
• Respectez la configuration réseau VMware pour vMotion ici .

Topologie

Pour ces tests de vérification, une topologie simple a été utilisée avec trois hôtes de serveur différents et un stockage à distance iSCSI (le stockage NFS peut également être utilisé). Le stockage distant exploite une connexion 10 Gbit/s aux serveurs. Sur l'hôte ESXi, une machine virtuelle C9800-CL est créée en mode autonome et deux autres machines virtuelles C9800-CL sont configurées pour la haute disponibilité SSO (Stateful Switchover High Availability). La paire haute disponibilité est créée sur deux serveurs différents pour la redondance physique et pour pouvoir migrer à la fois le WLC actif et le WLC en veille séparément. Chaque machine virtuelle C9800-CL est connectée au commutateur virtuel à l'aide de trois ports : 

• G1 > port SP (facultatif)
• G2 > Port trunk pour VLAN WMI (Wireless Management Interface) et VLAN client, le cas échéant
• G3 > Port RP. Ceci est pour la création du cluster SSO. Non connecté pour le mode autonome

Chaque serveur hôte dispose d’un port physique dédié et d’un commutateur dédié (commutateur 1) pour connecter les ports RP via une liaison L2, sur l’ensemble des serveurs. Les deux autres ports physiques sont connectés à un commutateur de liaison ascendante séparé (commutateur 2). Diagramme représentant la topologie de test :

Résultats des tests

Pour ces tests, deux scénarios de migration ont été envisagés :

1. Un C9800-CL autonome est migré entre le serveur #1 et le serveur #2
2. Une paire de C9800-CL configurée comme SSO haute disponibilité. Dans ce cas, le WLC actif est d'abord migré entre le serveur #1 et le serveur #3, puis le WLC en veille est migré du serveur #2 vers le serveur #3

Dans les deux cas, les trois différents types de migration vMotion ont été testés : ressources de calcul uniquement, stockage uniquement, calcul et stockage.

Pour déclencher vMotion, cliquez avec le bouton droit sur la VM et cliquez sur migrer :

Sélectionnez le type de migration et procédez comme suit :

Voici le résultat de chaque test :

Essai	C9800-CL autonome	Type vMotion	Observations/commentaires
1		Ressource de calcul uniquement	Non pris en charge: Les points d'accès et les clients abandonnent vu, qui récupèrent après un certain temps, en raison de Virtual Guest Tagging (VLAN 802.1q) problème : article KB Solution de contournement: Lancez une requête ping continue du contrôleur vers n'importe quel périphérique réseau câblé
2		Stockage uniquement	Pris en charge: les points d'accès et les clients sont stables, une seule requête ping est envoyée
3		Ressources de calcul et stockage	Non pris en charge: Les points d'accès et les clients abandonnent vu, qui récupèrent après un certain temps, en raison de Virtual Guest Tagging (VLAN 802.1q) problème : article KB Solution de contournement: lancez une requête ping continue depuis le contrôleur vers n'importe quel périphérique réseau câblé
Essai	SSO actif HA keepalive : 100 ms	Type vMotion
4		Ressource de calcul uniquement	Pris en charge: Le trafic est stable lors du rechargement de fusion de pile en veille actif vu en raison de l'expiration des keepalives du RP HA
5		Stockage uniquement	Pris en charge: Le trafic est stable, la plupart du temps le RP apparaît avant l'expiration du minuteur de keepalives du RP, donc aucune fusion de pile n'est visible
6		Ressources de calcul et stockage	Pris en charge: Le mode veille est passé à l'état de récupération veille et a été rechargé en raison de la fusion de pile.
Essai	SSO actif HA keepalive : 200 ms	Type vMotion
7		Ressource de calcul uniquement	Pris en charge: Les points d'accès et les clients sont stables, une seule requête ping est vue sur active, standby également stable
8		Stockage uniquement	Pris en charge: Les points d'accès et les clients sont stables, une seule requête ping est vue sur active, et elle est également stable
9		Ressources de calcul et stockage	Pris en charge: Les points d'accès et les clients sont stables, une seule requête ping est vue sur active, et elle est également stable
Essai	SSO en veille HA keepalive - 100 ms	Type vMotion
10		Ressource de calcul uniquement	Pris en charge: Les points d'accès et les clients sont stables sur actif et sont également stables après l'opération vMotion ; parfois des rechargements de fusion de pile en veille sont observés.
11		Stockage uniquement	Pris en charge: Les points d'accès et les clients sont stables sur actif et sont également stables après l'opération vMotion ; parfois des rechargements de fusion de pile en veille sont observés.
12		Ressources de calcul et stockage	Pris en charge: Les points d'accès et les clients sont stables sur actif et sont également stables après l'opération vMotion ; parfois des rechargements de fusion de pile en veille sont observés.
Essai	Veille haute disponibilité HA keepalive - 200 ms
13		Ressource de calcul uniquement	Pris en charge: Les points d'accès et les clients sont stables sur actif et également stables après l'opération vMotion
14		Stockage uniquement	Pris en charge: Les points d'accès et les clients sont stables sur actif et également stables après l'opération vMotion
15		Ressources de calcul et stockage	Pris en charge: Les points d'accès et les clients sont stables sur actif et également stables après l'opération vMotion

Comme le montre ce tableau, vMotion échoue dans le premier et le troisième scénario (test #1 et #3) avec le mode autonome C9800-CL, car il effectue une migration de calcul ou de calcul et de stockage. Dans ce cas, l'adresse MAC et IP de l'interface WMI du C9800-CL se déplace vers le nouvel hôte et donc vers un port de commutateur différent. vMotion ne peut pas envoyer un protocole RARP (Reverse Address Resolution Protocol) pour le VLAN de gestion sans fil C9800-CL car l'hôte ESXi ne peut pas identifier quel VLAN est utilisé par le système d'exploitation invité qui s'exécute dans la machine virtuelle. Pour prendre en charge ce scénario, vous devez mettre en oeuvre une solution de contournement : lancer une requête ping continue à partir du C9800-CL vers n'importe quel hôte câblé avant d'effectuer la migration ; cela déclenche le réseau de commutation pour connaître le nouvel emplacement (port) de la VM et donc converger plus rapidement.

Dans le cas de la migration analogique avec HA SSO (test #4, par exemple), l'interface de gestion de redondance (RMI) est utilisée pour vérifier l'accessibilité à la passerelle et entre les modes actif et veille, et par conséquent, elle génère le trafic qui maintient la table d'adresses MAC sur le commutateur à jour et le problème ne se produit pas.

Recommandation: pour de meilleurs résultats, il est recommandé de configurer les keepalive de port RP au moins deux fois plus que le keepalive de 100 ms par défaut (défini sur 200 ms). Si le réseau entre le stockage et les hôtes peut devenir occupé et augmenter la latence, pensez à définir le compteur de test d'activité sur 300 ms. Pour configurer le minuteur de test d'activité sur l'interface utilisateur graphique, accédez à Administration > Device > Redundancy :

Sur l'interface de ligne de commande, utilisez cette commande en mode d'exécution (et non en mode de configuration !)

C9800-SSO#chassis redundancy keep-alive timer 3 

Pour vérifier, utilisez la commande show suivante :

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 

Mises en garde résolues :

Voici les avertissements corrigés dans la section 17.9.2 :

ID de bogue Cisco CSCwd17349 - C9800 : le châssis actif risque de se bloquer lors du basculement SSO sur 17.9

Résumé

VMware vSphere vMotion peut être utilisé pour migrer la machine virtuelle C9800-CL d'un hôte à l'autre sans impact sur les opérations du réseau sans fil. vMotion est officiellement pris en charge sur la machine virtuelle C9800-CL à partir de la version 17.9.2.