Sommario

Introduzione

Prerequisiti

Requisiti

Topologia

Risultati dei test

Riepilogo

Introduzione

Questo documento descrive i test eseguiti per verificare il supporto vMotion per il modello C9800-CL in esecuzione su vSphere ESXi.

Prerequisiti

C9800-CL è il fattore di forma della macchina virtuale del controller LAN wireless Catalyst 9800. È possibile utilizzare VMware vSphere vMotion per eseguire una migrazione in tempo reale senza interruzione delle attività di Catalyst 9800-CL da un server host all'altro. Questa funzionalità è disponibile su tutti i vSwitch e i cluster. L'obiettivo è che, durante la migrazione in tempo reale di C9800-CL, la rete wireless rimanga attiva e gli utenti wireless continuino a disporre della connettività necessaria.

vMotion può essere eseguito manualmente o come parte di una configurazione di VMware vSphere Distributed Resource Scheduler (DRS). DRS distribuisce i carichi di lavoro delle macchine virtuali tra gli host vSphere all'interno di un cluster e controlla le risorse disponibili. In base al livello di automazione, DRS esegue la migrazione delle macchine virtuali ad altri host all'interno del cluster per ottimizzare le prestazioni. Sebbene DRS funzioni su vMotion, e quindi la migrazione in tempo reale funziona allo stesso modo, gli scenari specifici DRS non sono stati testati in questo momento e quindi non sono ufficialmente supportati.

Requisiti

- Usare le versioni software consigliate:

- ESXi vCenter 6.7 o successiva

- Software C9800-CL: versione 17.9.2 e successive

- Latenza (RTT) tra lo storage remoto e il server in cui viene eseguito C9800-CL deve essere < 60 ms

- C9800-CL VM non deve avere alcuna corrispondenza specifica dell'host ESXi come CD/DVD, connessione alla porta della console seriale e così via.

- Configurare qui vMotion in base alle linee guida VMware per host, storage condiviso remoto e reti.

- Conformarsi qui ai requisiti di rete VMware per vMotion.

Topologia

Per questi test di verifica è stata utilizzata una topologia semplice con tre diversi host server e storage remoto iSCSI (è possibile utilizzare anche lo storage NFS). Lo storage remoto sfrutta la connessione a 10 Gb/s ai server. Sull'host ESXi, una VM C9800-CL viene creata in modalità standalone e altre due macchine virtuali C9800-CL configurate per lo switching stateful ad alta disponibilità (SSO HA). La coppia HA viene creata su due server diversi per la ridondanza fisica e per essere in grado di migrare separatamente il WLC attivo e quello in standby. Ogni VM C9800-CL è collegata allo switch virtuale tramite l'utilizzo di tre porte:

- G1 > Porta SP (opzionale)

- G2 > Porta trunk per VLAN WMI (Wireless Management Interface) e VLAN client, se presenti

- G3 > Porta RP. Questa operazione è destinata alla creazione di cluster SSO. Non connesso per la modalità standalone

Ogni server host dispone di una porta fisica dedicata e di uno switch dedicato (switch n. 1) per collegare le porte RP tra loro tramite un collegamento L2 tra i server. Le altre due porte fisiche sono collegate a uno switch di uplink separato (switch n. 2). Diagramma che rappresenta la topologia di test:

Risultati dei test

Per questi test sono stati presi in considerazione due scenari di migrazione:

1. Viene eseguita la migrazione di un C9800-CL standalone tra il server 1 e il server 2

2. Coppia di C9800-CL configurata come opzione di elevata disponibilità SSO. In questo caso, viene eseguita prima la migrazione del WLC attivo tra il server 1 e il server 3, quindi viene eseguita la migrazione del WLC in standby dal server 2 al server 3

In entrambi i casi, sono stati testati tutti e tre i diversi tipi di migrazione vMotion: solo risorse di elaborazione, solo storage, sia elaborazione che storage.

Per attivare vMotion, è sufficiente fare clic con il pulsante destro del mouse sulla VM e scegliere migra:

Selezionare il tipo di migrazione ed eseguire i passaggi seguenti:

Di seguito è riportato il risultato di ciascun test:

Test

Standalone C9800-CL

Tipo vMotion

Osservazioni/Commenti

1

Solo risorsa di calcolo

Non supportata: I punti di accesso e i client vengono interrotti, che vengono ripristinati dopo un certo periodo di tempo, a causa del problema di Virtual Guest Tagging (VLAN 802.1q): articolo della Knowledge Base

Soluzione alternativa: Avviare il ping continuo dal controller a qualsiasi dispositivo di rete cablato

2

Solo storage

Supportato: i punti di accesso e i client sono stabili. Viene visualizzato un unico ping

3

Risorse di elaborazione e storage

Non supportata: I punti di accesso e i client vengono interrotti, che vengono ripristinati dopo un certo periodo di tempo, a causa del problema di Virtual Guest Tagging (VLAN 802.1q): articolo della Knowledge Base

Soluzione alternativa: avvia il ping continuo dal controller a qualsiasi dispositivo di rete cablato

Test

SSO attivo

HA keepalive: 100 ms

Tipo vMotion

4

Solo risorsa di calcolo

Supportato: Il traffico è stabile in modalità attiva, il ricaricamento dell'unione dello stack in standby è stato rilevato a causa della scadenza dei pacchetti keepalive HA RP

5

Solo storage

Supportato: Il traffico è stabile; per lo più l'RP rimane attivo prima della scadenza del timer di mantenimento pacchetti RP, quindi non viene rilevata alcuna unione dello stack

6

Risorse di elaborazione e storage

Supportato: Lo standby è passato allo stato di ripristino di standby ed è stato ricaricato a causa dell'unione dello stack.

Test

SSO attivo

HA keepalive: 200 ms

Tipo vMotion

7

Solo risorsa di calcolo

Supportato: I punti di accesso e i client sono stabili, viene rilevato un singolo ping mentre è attivo e lo standby è stabile

8

Solo storage

Supportato: I punti di accesso e i client sono stabili, viene rilevata una singola perdita di ping sul supporto attivo e stabile

9

Risorse di elaborazione e storage

Supportato: I punti di accesso e i client sono stabili, viene rilevata una singola perdita di ping sul supporto attivo e stabile

Test

Standby SSO

HA keepalive - 100 ms

Tipo vMotion

10

Solo risorsa di calcolo

Supportato: I punti di accesso e i client sono stabili su attivi e stabili anche dopo l'operazione vMotion; a volte, l'unione dello stack in standby viene ricaricata.

11

Solo storage

Supportato: I punti di accesso e i client sono stabili su attivi e stabili anche dopo l'operazione vMotion; a volte, l'unione dello stack in standby viene ricaricata.

12

Risorse di elaborazione e storage

Supportato: I punti di accesso e i client sono stabili su attivi e stabili anche dopo l'operazione vMotion; a volte, l'unione dello stack in standby viene ricaricata.

Test

Standby HA

HA keepalive-200 ms

13

Solo risorsa di calcolo

Supportato: I punti di accesso e i client sono stabili in posizione attiva e sono stabili anche dopo l'operazione vMotion

14

Solo storage

Supportato: I punti di accesso e i client sono stabili in posizione attiva e sono stabili anche dopo l'operazione vMotion

15

Risorse di elaborazione e storage

Supportato: I punti di accesso e i client sono stabili in posizione attiva e sono stabili anche dopo l'operazione vMotion

Come mostrato nella tabella, vMotion non riesce nel primo e nel terzo scenario (test n. 1 e n. 3) con la modalità standalone C9800-CL, in quanto esegue una migrazione di calcolo o calcolo e storage; in questo caso l'indirizzo MAC e IP di WMI di C9800-CL si sposta sul nuovo host e quindi su una porta switch diversa. vMotion non è in grado di inviare un protocollo RARP (Reverse Address Resolution Protocol) per la VLAN di gestione wireless C9800-CL, in quanto l'host ESXi non è in grado di identificare la VLAN utilizzata dal sistema operativo guest che esegue macchina virtuale. Per supportare questo scenario, è necessario implementare una soluzione alternativa: avviare un ping continuo dal C9800-CL a qualsiasi host cablato prima di eseguire la migrazione; in questo modo la rete dello switch viene avviata per conoscere la nuova posizione (porta) della VM e, di conseguenza, convergere più rapidamente.

Nel caso della migrazione analogica con HA SSO (test n. 4, ad esempio), l'interfaccia RMI (Redundancy Management Interface) viene utilizzata per verificare la raggiungibilità del gateway e tra le modalità Attiva e Standby, e quindi genera il traffico che mantiene aggiornata la tabella degli indirizzi MAC sullo switch e impedisce il verificarsi del problema.

Suggerimento: per ottenere risultati ottimali, si consiglia di configurare la porta RP come keepalive ad almeno due volte il valore predefinito di 100 ms (impostarlo su 200 ms). Se la rete tra lo storage e gli host può diventare occupata e aumentare la latenza, si consiglia di impostare il timer keepalive su 300 ms. Per configurare il timer keepalive sulla GUI, selezionare Amministrazione > Dispositivo > Ridondanza:

Dalla CLI, usare questo comando in modalità di esecuzione (non in modalità di configurazione!)

C9800-SSO#chassis redundancy keep-alive timer 3

Per verificarlo, utilizzare questo 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

Avvertenze risolte:

Queste sono le avvertenze fissate nella sezione 17.9.2:

ID bug Cisco CSCwd17349 - C9800: lo chassis attivo potrebbe bloccarsi durante il failover SSO della versione 17.9

Riepilogo

VMware vSphere vMotion può essere utilizzato per migrare la VM C9800-CL da un host all'altro senza alcun impatto sulle operazioni di rete wireless. vMotion è ufficialmente supportato sul C9800-CL a partire dalla versione 17.9.2.