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:
- Viene eseguita la migrazione di un C9800-CL standalone tra il server 1 e il server 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.