Contents

Introduction

Prerequisites

Requirements

Topologia

Resultados do teste

Summary

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.