Suporte ao VMware vSphere vMotion no Catalyst 9800

Introduction

Este documento descreve os testes feitos para verificar o suporte do vMotion para o C9800-CL executado no vSphere ESXi.

Prerequisites

O C9800-CL é o formato da máquina virtual do Catalyst 9800 Wireless LAN Controller. Você pode usar o VMware vSphere vMotion para executar uma migração ao vivo sem tempo de inatividade do Catalyst 9800-CL de um servidor host para outro. Esse recurso é possível em vSwitches e clusters. O objetivo é que, durante a migração ao vivo do C9800-CL, a rede sem fio permaneça ativa e os usuários sem fio continuem a ter a conectividade de que precisam.

O vMotion pode ser feito manualmente ou como parte de uma configuração do Distributed Resource Scheduler (DRS) do VMware vSphere. O DRS distribui as cargas de trabalho da máquina virtual pelos hosts do vSphere dentro de um cluster e monitora os recursos disponíveis para você. Com base em seu nível de automação, o DRS migra máquinas virtuais para outros hosts no cluster para maximizar o desempenho. Embora o DRS funcione em cima do vMotion e, portanto, a migração ao vivo funcione da mesma forma, os cenários específicos do DRS não foram testados neste momento e, portanto, não são oficialmente suportados.

Requirements

• Usar versões de software testadas recomendadas: 
  • ESXi vCenter 6.7 ou posterior
    
  • Software C9800-CL: 17.9.2 e posterior
    
• A latência (RTT) entre o armazenamento remoto e o servidor onde o C9800-CL é executado deve ser < 60 ms
• A VM C9800-CL não deve ter nenhuma correspondência específica de host ESXi, como CD/DVD, conexão de porta de console serial e assim por diante.
• Configure o vMotion de acordo com as diretrizes da VMware para host, armazenamento compartilhado remoto e rede aqui .
• Cumpra os requisitos de rede da VMware para o vMotion aqui .

Topologia

Para esses testes de verificação, foi usada uma topologia simples com três hosts de servidor diferentes e armazenamento remoto iSCSI (o armazenamento NFS também pode ser usado). O armazenamento remoto aproveita a conexão de 10 Gbps com os servidores. No host ESXi, uma VM C9800-CL é criada no modo autônomo e duas outras máquinas virtuais C9800-CL configuradas para alta disponibilidade de Stateful Switchover (SSO HA). O par HA é criado em dois servidores diferentes para redundância física e para poder migrar WLCs ativas e em standby separadamente. Cada VM C9800-CL é conectada ao switch virtual pelo uso de três portas: 

• Porta G1 > SP (opcional)
• G2 > Porta de tronco para VLAN de interface de gerenciamento sem fio (WMI) e VLANs de cliente, se presentes
• G3 > porta RP. Isso é para a criação do cluster SSO. Não conectado para o modo autônomo

Cada servidor host tem uma porta física dedicada e um switch dedicado (switch#1) para conectar as portas RP através de um link L2, através dos servidores. As outras duas portas físicas estão conectadas a um switch de uplink separado (switch#2). Um diagrama que representa a topologia de teste:

Resultados do teste

Para esses testes, foram considerados dois cenários de migração:

1. Um C9800-CL autônomo é migrado entre #1 de servidor e #2 de servidor
2. Um par de C9800-CL configurado como em alta disponibilidade de SSO. Nesse caso, primeiro o ativo é migrado entre o #1 do servidor e o #3 do servidor e, em seguida, o WLC em standby é migrado do #2 do servidor para o #3 do servidor

Em ambos os casos, todos os três tipos diferentes de migração do vMotion foram testados: somente recurso de computação, somente armazenamento, tanto computação quanto armazenamento.

Para ativar o vMotion, basta clicar com o botão direito do mouse na VM e clicar em migrar:

Selecione o tipo de migração e siga as etapas abaixo:

Veja o resultado de cada teste:

Teste	C9800-CL autônomo	Tipo vMotion	Observações/Comentários
1		Calcular somente recurso	Not Supported: Os APs e clientes são vistos em queda, que se recuperam após algum tempo, devido ao problema de Marcação de Convidado Virtual (VLAN 802.1q): artigo do KB Solução: Inicie o ping contínuo do controlador para qualquer dispositivo de rede com fio
2		Somente armazenamento	Supported: APs e clientes são estáveis, queda de ping único é vista
3		Recurso de computação e armazenamento	Not Supported: Os APs e clientes são vistos em queda, que se recuperam após algum tempo, devido ao problema de Marcação de Convidado Virtual (VLAN 802.1q): artigo do KB Solução: Inicie o ping contínuo do controlador para qualquer dispositivo de rede com fio
Teste	SSO Ativo Manutenção de atividade HA: 100 ms	Tipo vMotion
4		Calcular somente recurso	Compatível: O tráfego é estável no recarregamento ativo de mesclagem de pilha em espera visto devido a manutenções de atividades de RP de alta disponibilidade expiradas
5		Somente armazenamento	Compatível: O tráfego é estável, na maioria das vezes o RP surge antes que o temporizador de keepalives do RP expire, portanto, nenhuma mesclagem de pilha é vista
6		Recurso de computação e armazenamento	Compatível: O modo de espera foi para o estado de recuperação em espera e foi recarregado devido à mesclagem da pilha.
Teste	SSO Ativo Manutenção de atividade HA: 200 ms	Tipo vMotion
7		Calcular somente recurso	Compatível: Os APs e os Clientes são estáveis, um único descarte de ping é visto no estado ativo, em espera também estável
8		Somente armazenamento	Compatível: Os APs e os Clientes são estáveis, um único descarte de ping é visto em ativo, também permanece estável
9		Recurso de computação e armazenamento	Compatível: Os APs e os Clientes são estáveis, um único descarte de ping é visto em ativo, também permanece estável
Teste	SSO em espera Manutenção de atividade de HA - 100 ms	Tipo vMotion
10		Calcular somente recurso	Compatível: Os APs e os Clientes são estáveis quando ativos e também permanecem estáveis após a operação do vMotion; às vezes, a mesclagem da pilha em espera é recarregada.
11		Somente armazenamento	Compatível: Os APs e os Clientes são estáveis quando ativos e também permanecem estáveis após a operação do vMotion; às vezes, a mesclagem da pilha em espera é recarregada.
12		Recurso de computação e armazenamento	Compatível: Os APs e os Clientes são estáveis quando ativos e também permanecem estáveis após a operação do vMotion; às vezes, a mesclagem da pilha em espera é recarregada.
Teste	HA em espera keepalive de alta disponibilidade - 200 ms
13		Calcular somente recurso	Compatível: Os APs e os Clientes são estáveis quando ativos e também permanecem estáveis após a operação do vMotion
14		Somente armazenamento	Compatível: Os APs e os Clientes são estáveis quando ativos e também permanecem estáveis após a operação do vMotion
15		Recurso de computação e armazenamento	Compatível: Os APs e os Clientes são estáveis quando ativos e também permanecem estáveis após a operação do vMotion

Como visto nesta tabela, o vMotion falha no primeiro e terceiro cenários (#1 de teste e #3) com C9800-CL em modo autônomo, pois executa uma migração de computação ou computação e armazenamento; nesse caso, o endereço MAC e IP da WMI do C9800-CL é movido para o novo host e, portanto, para uma porta de switch diferente. O vMotion não pode enviar um RARP (Reverse Address Resolution Protocol) para a VLAN de gerenciamento sem fio do C9800-CL, pois o host ESXi não pode identificar qual VLAN operacional está em uso pelo convidado que é executado na máquina virtual. Para suportar esse cenário, você precisa implementar uma solução alternativa: iniciar um ping contínuo do C9800-CL para qualquer host com fio antes de executar a migração; isso aciona a rede do switch para aprender sobre o novo local (porta) da VM e, portanto, convergir mais rápido.

No caso de migração analógica com HA SSO (#4 de teste, por exemplo), a Redundancy Management Interface (RMI) é aproveitada para verificar o acesso ao gateway e entre Ativo e Standby e, portanto, gera o tráfego que mantém a tabela de endereços MAC no switch atualizada e o problema não acontece.

Recomendação: Para obter melhores resultados, é recomendável configurar os keepalives de porta RP para pelo menos duas vezes o keepalive padrão de 100 ms (defina-o para 200 ms). Se a rede entre o armazenamento e os hosts puder ficar ocupada e aumentar a latência, considere definir o temporizador de keepalives como 300 ms. Para configurar o temporizador keepalive na GUI, vá para Administration > Device > Redundancy:

Na CLI, use este comando no modo exec (não no modo de configuração!)

C9800-SSO#chassis redundancy keep-alive timer 3 

Para verificar, use 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 

Avisos resolvidos:

Estas são as advertências fixadas em 17.9.2:

ID de bug da Cisco CSCwd17349 - C9800: O chassi ativo pode ficar travado durante o failover do SSO em 17.9

Summary

O VMware vSphere vMotion pode ser utilizado para migrar a VM do C9800-CL de um host para o outro sem afetar as operações de rede sem fio. O vMotion é oficialmente suportado no C9800-CL a partir da versão 17.9.2.