Inleiding
In dit document worden de tests beschreven die zijn uitgevoerd om de ondersteuning van vMotion te controleren voor de C9800-CL die op vSphere ESXi wordt uitgevoerd.
Voorwaarden
C9800-CL is de virtuele machinevorm van de Catalyst 9800 draadloze LAN-controller. U kunt VMware vSphere vMotion gebruiken om een nul-downtime live-migratie van Catalyst 9800-CL uit te voeren van de ene hostserver naar de andere. Dit is mogelijk voor alle vSwitches en clusters. Het doel is dat, tijdens de live migratie van de C9800-CL, het draadloze netwerk in gebruik blijft en dat draadloze gebruikers over de nodige connectiviteit blijven beschikken.
vMotion kan handmatig worden uitgevoerd of als onderdeel van een configuratie van VMware vSphere Distributed Resource Scheduler (DRS). DRS verspreidt de werkbelasting van virtuele machines over vSphere-hosts binnen een cluster en bewaakt de beschikbare bronnen voor u. Op basis van uw automatiseringsniveau migreert DRS virtuele machines naar andere hosts binnen het cluster voor maximale prestaties. Hoewel DRS op vMotion werkt en dus ook live migratie werkt, zijn de specifieke DRS-scenario's op dit moment nog niet getest en daarom niet officieel ondersteund.
Vereisten
- Gebruik de aanbevolen geteste softwarereleases:
- ESXi vCenter 6.7 of later
- C9800-CL-software: 17.9.2 en hoger
- Latentie (RTT) tussen de externe opslag en de server waarop C9800-CL draait, moet < 60 ms zijn
- De C9800-CL VM mag geen enkele ESXi-host-specifieke correspondentie hebben, zoals CD/DVD, seriële console-poortverbinding, enzovoort.
- vMotion configureren volgens de VMware-richtlijnen voor host, externe gedeelde opslag en netwerken hier.
- Voldoen aan de netwerkvereisten van VMware voor vMotion hier.
Topologie
Voor deze verificatietests werd een eenvoudige topologie gebruikt met drie verschillende serverhosts en iSCSI externe opslag (NFS-opslag kan ook worden gebruikt). De externe opslag maakt gebruik van een 10 Gbps verbinding met de servers. Op de ESXi-host wordt één C9800-CL VM gemaakt in de standalone modus en worden twee andere C9800-CL virtuele machines geconfigureerd voor Stateful Switchover High Availability (SSO HA). Het HA-paar wordt over twee verschillende servers gemaakt voor fysieke redundantie en om zowel actieve als stand-by WLC afzonderlijk te kunnen migreren. Elke C9800-CL VM is met de virtuele switch verbonden via drie poorten:
- G1 > SP-poort (optioneel)
- G2 > Trunk-poort voor Wireless Management Interface (WMI) VLAN en client-VLAN’s (indien aanwezig)
- G3 > RP-poort. Dit is voor de SSO-clustervorming. Niet verbonden voor de standalone modus
Elke hostserver heeft een speciale fysieke poort en speciale switch (switch #1) om de RP-poorten samen te verbinden via een L2-link, over de servers. De andere twee poorten zijn verbonden met een aparte uplink-switch (switch #2). Een diagram dat de testtopologie weergeeft:
Testresultaten
Voor deze tests worden twee migratiescenario's overwogen:
- Een standalone C9800-CL is gemigreerd tussen #1 en #2
- Een paar C9800-CL geconfigureerd zoals in SSO hoge beschikbaarheid. In dit geval wordt eerst het actieve systeem gemigreerd tussen #1 en server #3 en wordt vervolgens de standby WLC gemigreerd van server #2 naar server #3
In beide gevallen werden alle drie de verschillende soorten vMotion-migratie getest: alleen compute resource, alleen opslag, zowel computing als opslag.
Om vMotion te activeren, klikt u met de rechtermuisknop op de VM en klikt u op migreren:
Selecteer het type migratie en ga door de stappen:
Dit is het resultaat van elke test:
Testen |
Standalone C9800-CL |
Type vMotion |
Opmerkingen/opmerkingen |
1 |
|
Alleen computing-bron |
Niet ondersteund: AP's en clients drop gezien, die herstellen na enige tijd, als gevolg van Virtual Guest Tagging (802.1q VLAN) probleem: KB artikel Tijdelijke oplossing: Doorlopende ping starten van de controller op een bekabeld netwerkapparaat |
2 |
|
Alleen opslag |
Ondersteunde producten: AP's en clients zijn stabiel, één ping drop wordt gezien |
3 |
|
Bereken bronnen en opslag |
Niet ondersteund: AP's en clients drop gezien, die herstellen na enige tijd, als gevolg van Virtual Guest Tagging (802.1q VLAN) probleem: KB artikel Tijdelijke oplossing: Continu starten met pingen van de controller naar een bekabeld netwerkapparaat |
Testen |
SSO actief HA keepalive: 100ms |
Type vMotion |
|
4 |
|
Alleen computing-bron |
Ondersteund: Het verkeer is stabiel op actieve, standby stack merge reload gezien als gevolg van HA RP keepalives verlopen |
5 |
|
Alleen opslag |
Ondersteund: Het verkeer is stabiel, het grootste deel van de tijd RP komt omhoog voordat RP keepalives timer verlopen zodat geen stack samenvoeging wordt gezien |
6 |
|
Bereken bronnen en opslag |
Ondersteund: Stand-by ging naar stand-by herstelstatus en herladen door stack samenvoegen. |
Testen |
SSO actief HA keepalive: 200ms |
Type vMotion |
|
7 |
|
Alleen computing-bron |
Ondersteund: APs en Clients zijn stabiel, single ping drop wordt gezien op actieve, stand-by ook stabiel |
8 |
|
Alleen opslag |
Ondersteund: APs en Clients zijn stabiel, single ping drop wordt gezien op actief, stand ook stabiel |
9 |
|
Bereken bronnen en opslag |
Ondersteund: APs en Clients zijn stabiel, single ping drop wordt gezien op actief, stand ook stabiel |
Testen |
SSO-stand-by HA keepalive- 100 ms |
Type vMotion |
|
10 |
|
Alleen computing-bron |
Ondersteund: APs en Clients zijn stabiel op actieve en staan ook stabiel na de vMotion-operatie; soms stand-by stack herladen gezien. |
11 |
|
Alleen opslag |
Ondersteund: APs en Clients zijn stabiel op actieve en staan ook stabiel na de vMotion-operatie; soms stand-by stack herladen gezien. |
12 |
|
Bereken bronnen en opslag |
Ondersteund: APs en Clients zijn stabiel op actieve en staan ook stabiel na de vMotion-operatie; soms stand-by stack herladen gezien. |
Testen |
HA-stand-by HA keepalive-200 ms |
|
|
13 |
|
Alleen computing-bron |
Ondersteund: AP's en clients zijn stabiel op actief en staan ook stabiel na de vMotion-handeling |
14 |
|
Alleen opslag |
Ondersteund: AP's en clients zijn stabiel op actief en staan ook stabiel na de vMotion-handeling |
15 |
|
Bereken bronnen en opslag |
Ondersteund: AP's en clients zijn stabiel op actief en staan ook stabiel na de vMotion-handeling |
Zoals in deze tabel te zien is, faalt vMotion in het eerste en derde scenario (test #1 en #3) met standalone modus C9800-CL, aangezien het een compute of compute en opslagmigratie uitvoert; in dit geval gaat het MAC- en IP-adres van de WMI van de C9800-CL naar de nieuwe host en dus naar een andere switch poort. vMotion kan geen omgekeerde adresresolutie-protocol (RARP) verzenden voor het C9800-CL Wireless Management VLAN, omdat de ESXi-host niet kan identificeren welk VLAN wordt gebruikt door het gastbesturingssysteem dat wordt uitgevoerd in de virtuele machine die werkt in het virtuele machine die werkt in het virtuele . Om dit scenario te ondersteunen, moet u een tijdelijke oplossing implementeren: start een continue ping van de C9800-CL naar elke bekabelde host voordat deze de switch uitvoert; hierdoor wordt het migratienetwerk geactiveerd om meer te weten te komen over de nieuwe locatie (poort) van de VM en dus sneller samen te komen.
In de analoge migratiecase met HA SSO (test #4, bijvoorbeeld) wordt de Redundancy Management Interface (RMI) gebruikt om de bereikbaarheid van de gateway en tussen Active en Standby te controleren, en zo wordt het verkeer gegenereerd dat de MAC-adrestabel op de switch bijgewerkt houdt en het probleem niet gebeurt.
Aanbeveling: Voor het beste resultaat is het aan te raden om RP-poortkeepalives te configureren tot ten minste tweemaal de standaard 100 ms keepalive (ingesteld op 200 ms). Als het netwerk tussen opslag en hosts bezet kan worden en de latentie kan vergroten, kunt u overwegen om de keepalives timer in te stellen op 300 ms. Om de keepalive timer op de GUI te configureren, gaat u naar Beheer > Apparaat > Redundantie:
Gebruik deze opdracht op de CLI in exec-modus (niet in configuratiemodus!)
C9800-SSO#chassis redundancy keep-alive timer 3
Om te verifiëren, gebruik dit showbevel:
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
Opgeloste voorbehouden:
Dit zijn de in 17.9.2 vastgestelde voorbehouden:
Cisco fout-id CSCwd17349 - C9800: actief chassis kan vastlopen tijdens de SSO-failover op 17.9
Samenvatting
VMware vSphere vMotion kan worden gebruikt om de C9800-CL VM van de ene host naar de andere te migreren zonder de werking van het draadloze netwerk te beïnvloeden. vMotion wordt vanaf release 17.9.2 officieel ondersteund op de C9800-CL.