Compatibilidad con VMware vSphere vMotion en Catalyst 9800

Introducción

Este documento describe las pruebas realizadas para verificar la compatibilidad de vMotion con el C9800-CL que se ejecuta en vSphere ESXi.

Prerequisites

C9800-CL es el diseño de máquina virtual del controlador de LAN inalámbrica Catalyst 9800. Puede utilizar VMware vSphere vMotion para realizar una migración en tiempo real sin tiempo de inactividad de Catalyst 9800-CL de un servidor host a otro. Esta capacidad es posible en vSwitches y clústeres. El objetivo es que, durante la migración en tiempo real de C9800-CL, la red inalámbrica permanezca activa y los usuarios inalámbricos sigan disponiendo de la conectividad que necesitan.

vMotion se puede realizar manualmente o como parte de una configuración de VMware vSphere Distributed Resource Scheduler (DRS). DRS distribuye las cargas de trabajo de las máquinas virtuales entre los hosts de vSphere dentro de un clúster y supervisa los recursos disponibles para usted. En función de su nivel de automatización, DRS migra las máquinas virtuales a otros hosts del clúster para maximizar el rendimiento. Aunque DRS funciona sobre vMotion y, por lo tanto, la migración en vivo funciona igual, los escenarios específicos de DRS no se han probado en este momento y, por lo tanto, no se admiten oficialmente.

Requirements

• Utilizar versiones de software probadas recomendadas: 
  • ESXi vCenter 6.7 o posterior
    
  • Software C9800-CL: 17.9.2 y versiones posteriores
    
• La latencia (RTT) entre el almacenamiento remoto y el servidor donde se ejecuta C9800-CL debe ser < 60 ms
• La VM de C9800-CL no debe tener ninguna correspondencia específica de host de ESXi, como CD/DVD, conexión de puerto de consola serie, etc.
• Configure vMotion según las directrices de VMware para host, almacenamiento remoto compartido y redes aquí .
• Cumplir los requisitos de red de VMware para vMotion aquí .

Topología

Para estas pruebas de verificación se utilizó una topología simple con tres hosts de servidor diferentes y almacenamiento remoto iSCSI (también se puede utilizar el almacenamiento NFS). El almacenamiento remoto aprovecha la conexión de 10 Gbps a los servidores. En el host ESXi, se crea una máquina virtual C9800-CL en modo independiente y otras dos máquinas virtuales C9800-CL configuradas para la alta disponibilidad de conmutación stateful (SSO HA). El par de HA se crea a través de dos servidores diferentes para la redundancia física y para poder migrar el WLC activo y en espera por separado. Cada máquina virtual C9800-CL se conecta al switch virtual mediante el uso de tres puertos: 

• G1 > Puerto SP (opcional)
• G2 > Puerto troncal para VLAN de la interfaz de administración inalámbrica (WMI) y VLAN de cliente, si existen
• G3 > Puerto RP. Esto es para la creación del clúster de SSO. No conectado para el modo independiente

Cada servidor host tiene un puerto físico dedicado y un switch dedicado (switch n.º 1) para conectar los puertos RP a través de un enlace L2, a través de los servidores. Los otros dos puertos físicos están conectados a un switch de enlace ascendente separado (switch n.º 2). Un diagrama que representa la topología de prueba:

Resultados de la prueba

Para estas pruebas, se consideraron dos escenarios de migración:

1. Se migra un C9800-CL independiente entre el servidor #1 y el servidor #2
2. Un par de C9800-CL configurados como en alta disponibilidad SSO. En este caso, primero el WLC activo se migra entre el servidor #1 y el servidor #3 y luego el WLC en espera se migra del servidor #2 al servidor #3

En ambos casos, se probaron los tres tipos diferentes de migración de vMotion: solo recursos informáticos, solo almacenamiento, tanto informática como almacenamiento.

Para activar vMotion, haga clic con el botón derecho del ratón en la máquina virtual y haga clic en Migrar:

Seleccione el tipo de migración y realice los pasos siguientes:

Aquí está el resultado de cada prueba:

Prueba	C9800-CL independiente	Tipo de vMotion	Observaciones/comentarios
1		Sólo recurso de cálculo	Not Supported: Los AP y los clientes caen vistos, que se recuperan después de algún tiempo, debido al problema del etiquetado de invitado virtual (VLAN 802.1q): artículo de KB Solución Aternativa: Inicie un ping continuo desde el controlador a cualquier dispositivo de red con cables
2		Sólo almacenamiento	Supported: los AP y los clientes son estables, se ve una sola caída de ping
3		Recursos informáticos y almacenamiento	Not Supported: Los AP y los clientes caen vistos, que se recuperan después de algún tiempo, debido al problema del etiquetado de invitado virtual (VLAN 802.1q): artículo de KB Solución Aternativa: inicie un ping continuo desde el controlador a cualquier dispositivo de red con cables
Prueba	SSO activo keepalive de HA: 100 ms	Tipo de vMotion
4		Sólo recurso de cálculo	Admitido: El tráfico es estable en la recarga de combinación de pila en espera activa vista debido a que las señales de mantenimiento HA RP vencieron
5		Sólo almacenamiento	Admitido: El tráfico es estable, la mayor parte del tiempo el RP se activa antes de que caduque el temporizador de señales de mantenimiento RP, por lo que no se ve ninguna combinación de pila
6		Recursos informáticos y almacenamiento	Admitido: El modo en espera pasó al estado de recuperación en espera y a la recarga debido a la fusión de la pila.
Prueba	SSO activo keepalive de HA: 200 ms	Tipo de vMotion
7		Sólo recurso de cálculo	Admitido: Los AP y los clientes son estables, se ve una sola caída de ping en activo, en espera también estable
8		Sólo almacenamiento	Admitido: Los AP y los clientes son estables, se ve una sola caída de ping en la posición activa, también estable
9		Recursos informáticos y almacenamiento	Admitido: Los AP y los clientes son estables, se ve una sola caída de ping en la posición activa, también estable
Prueba	SSO en espera keepalive de HA: 100 ms	Tipo de vMotion
10		Sólo recurso de cálculo	Admitido: Los puntos de acceso y los clientes se mantienen estables en el modo activo y también se mantienen estables tras la operación de vMotion; a veces se ven recargas de combinación de pilas en espera.
11		Sólo almacenamiento	Admitido: Los puntos de acceso y los clientes se mantienen estables en el modo activo y también se mantienen estables tras la operación de vMotion; a veces se ven recargas de combinación de pilas en espera.
12		Recursos informáticos y almacenamiento	Admitido: Los puntos de acceso y los clientes se mantienen estables en el modo activo y también se mantienen estables tras la operación de vMotion; a veces se ven recargas de combinación de pilas en espera.
Prueba	HA en espera keepalive de HA: 200 ms
13		Sólo recurso de cálculo	Admitido: Los puntos de acceso y los clientes se mantienen estables en el modo activo y también se mantienen estables tras la operación de vMotion
14		Sólo almacenamiento	Admitido: Los puntos de acceso y los clientes se mantienen estables en el modo activo y también se mantienen estables tras la operación de vMotion
15		Recursos informáticos y almacenamiento	Admitido: Los puntos de acceso y los clientes se mantienen estables en el modo activo y también se mantienen estables tras la operación de vMotion

Como se puede ver en esta tabla, vMotion falla en el primer y tercer escenario (prueba #1 y #3) con el modo independiente C9800-CL, ya que realiza una migración informática y de almacenamiento; en este caso, la dirección MAC e IP de WMI del C9800-CL se mueve al nuevo host y, por lo tanto, a un puerto de switch diferente. vMotion no puede enviar un protocolo de resolución de dirección inversa (RARP) para la VLAN de administración inalámbrica del C9800-CL, ya que el host ESXi no puede identificar qué VLAN está utilizando el invitado sistema que se ejecuta en la máquina virtual. Para admitir este escenario, debe implementar una solución alternativa: iniciar un ping continuo desde el C9800-CL a cualquier host con cable antes de realizar la migración; esto hace que la red del switch detecte la nueva ubicación (puerto) de la VM y, por lo tanto, converja más rápido.

En el caso de migración analógica con HA SSO (prueba #4, por ejemplo), la interfaz de administración de redundancia (RMI) se aprovecha para comprobar la disponibilidad del gateway y entre activo y en espera, y por lo tanto genera el tráfico que mantiene actualizada la tabla de direcciones MAC en el switch y el problema no ocurre.

Recomendación: Para obtener los mejores resultados, se recomienda configurar los keepalives del puerto RP a por lo menos el doble del keepalive predeterminado de 100 ms (establézcalo en 200 ms). Si la red entre el almacenamiento y los hosts puede estar ocupada y aumentar la latencia, considere establecer el temporizador de señales de mantenimiento en 300 ms. Para configurar el temporizador de señal de mantenimiento en la GUI, vaya a Administration > Device > Redundancy:

En la CLI, utilice este comando en modo exec (¡no en modo de configuración!)

C9800-SSO#chassis redundancy keep-alive timer 3 

Para verificarlo, utilice este comando show:

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 

Advertencias resueltas:

Estas son las advertencias fijadas en 17.9.2:

ID de bug de Cisco CSCwd17349 - C9800: es posible que el chasis activo se atasque durante la conmutación por fallo de SSO en 17.9

Summary

VMware vSphere vMotion se puede aprovechar para migrar la máquina virtual C9800-CL de un host a otro sin que ello afecte a las operaciones de red inalámbrica. vMotion es compatible oficialmente con C9800-CL a partir de la versión 17.9.2.