简介
本文档介绍为验证在vSphere ESXi上运行的C9800-CL的vMotion支持而进行的测试。
先决条件
C9800-CL是Catalyst 9800无线LAN控制器的虚拟机外形。您可以使用VMware vSphere vMotion执行Catalyst 9800-CL从一个主机服务器到另一个主机服务器的零停机实时迁移。此功能可在vSwitch和集群中实现。其目标是,在C9800-CL实时迁移期间,无线网络保持运行,无线用户继续拥有所需的连接。
vMotion可以手动完成,也可以作为VMware vSphere分布式资源调度程序(DRS)配置的一部分。DRS在集群内的vSphere主机上分散虚拟机工作负载,并监控可用的资源。根据您的自动化级别,DRS将虚拟机迁移至集群中的其他主机,以最大限度地提高性能。虽然DRS在vMotion上工作,因此实时迁移也一样,但DRS特定的场景目前尚未经过测试,因此没有得到正式支持。
要求
- 使用推荐的经测试的软件版本:
- ESXi vCenter 6.7 或更高
- C9800-CL软件:17.9.2及更高版本
- 从远程存储到运行C9800-CL的服务器的延迟(RTT)必须小于60毫秒
- C9800-CL VM不得有任何与ESXi主机相关的通信,如CD/DVD、串行控制台端口连接等。
- 根据VMware关于主机、远程共享存储和网络方面的指导原则,在此处配置vMotion。
- 在此处符合vMotion的VMware网络要求。
拓扑
对于这些验证测试,将一个简单的拓扑用于三个不同的服务器主机和iSCSI远程存储(也可以使用NFS存储)。远程存储利用与服务器的10 Gbps连接。在ESXi主机上,一个C9800-CL虚拟机在独立模式下创建,另外两个C9800-CL虚拟机配置为状态切换高可用性(SSO HA)。HA对跨两个不同的服务器创建,以实现物理冗余,并能够分别迁移主用和备用WLC。每个C9800-CL VM使用三个端口连接到虚拟交换机:
- G1 > SP端口(可选)
- G2 >无线管理接口(WMI)VLAN和客户端VLAN的中继端口(如果有)
- G3 > RP端口。这用于SSO群集创建。未连接独立模式
每台主机服务器都有一个专用物理端口和专用交换机(交换机1),用于通过L2链路跨服务器将RP端口连接在一起。另外两个物理端口连接到一个单独的上行链路交换机(switch#2)。表示测试拓扑的图:
测试结果
对于这些测试,需要考虑两种迁移方案:
- 独立C9800-CL在服务器接口和服务器#1口之间迁#2
- 配置为SSO高可用性的一对C9800-CL。在这种情况下,首先在服务器ID和服务器ID之间迁移#1动的WLC,然#3将备用WLC从服务器ID迁移#2服务器ID#3
在这两种情况下,对三种不同类型的vMotion迁移都进行了测试:仅计算资源、仅存储、计算和存储。
要触发vMotion,只需右键点击VM,然后点击migrate:
选择迁移类型并完成以下步骤:
以下是每个测试的结果:
测试 |
独立C9800-CL |
vMotion类型 |
意见/评论 |
1 |
|
仅计算资源 |
Not Supported: 由于虚拟访客标记(802.1q VLAN)问题,AP和客户端丢失,稍后恢复:知识库文章 解决方法: 开始从控制器对任何有线网络设备进行连续ping |
2 |
|
仅存储 |
受支持:AP和客户端稳定,出现单一ping丢弃 |
3 |
|
计算资源和存储 |
Not Supported: 由于虚拟访客标记(802.1q VLAN)问题,AP和客户端丢失,稍后恢复:知识库文章 解决方法:从控制器持续向任何有线网络设备发出ping命令 |
测试 |
SSO活动 HA keepalive:100毫秒 |
vMotion类型 |
|
4 |
|
仅计算资源 |
受支持: 由于HA RP keepalives已过期,导致活动备用堆栈合并重新加载时流量稳定 |
5 |
|
仅存储 |
受支持: 流量是稳定的,RP在RP keepalives计时器过期之前出现的大部分时间,因此不会看到堆栈合并 |
6 |
|
计算资源和存储 |
受支持: 由于堆栈合并,备用设备进入备用恢复状态并重新加载。 |
测试 |
SSO活动 HA keepalive:200毫秒 |
vMotion类型 |
|
7 |
|
仅计算资源 |
受支持: AP和客户端是稳定的,单个ping丢弃在主用和备用上也是稳定的 |
8 |
|
仅存储 |
受支持: AP和客户端是稳定的,单个ping丢弃在活动时可见,站也稳定 |
9 |
|
计算资源和存储 |
受支持: AP和客户端是稳定的,单个ping丢弃在活动时可见,站也稳定 |
测试 |
SSO备用 HA keepalive - 100毫秒 |
vMotion类型 |
|
10 |
|
仅计算资源 |
受支持: AP和客户端在活动状态下是稳定的,在vMotion操作后也保持稳定;有时可以看到备用堆栈合并重新加载。 |
11 |
|
仅存储 |
受支持: AP和客户端在活动状态下是稳定的,在vMotion操作后也保持稳定;有时可以看到备用堆栈合并重新加载。 |
12 |
|
计算资源和存储 |
受支持: AP和客户端在活动状态下是稳定的,在vMotion操作后也保持稳定;有时可以看到备用堆栈合并重新加载。 |
测试 |
HA备用 HA keepalive-200ms |
|
|
13 个 |
|
仅计算资源 |
受支持: AP和客户端在活动状态下是稳定的,在vMotion操作后也保持稳定 |
14 |
|
仅存储 |
受支持: AP和客户端在活动状态下是稳定的,在vMotion操作后也保持稳定 |
15 |
|
计算资源和存储 |
受支持: AP和客户端在活动状态下是稳定的,在vMotion操作后也保持稳定 |
如下表所示,vMotion在执行计算或计算和存储迁移时,在独立模式C9800-CL的第一个和第三种方案(测试#1和#3)中失败;在这种情况下,C9800-CL的WMI的MAC和IP地址移动到新主机,因此移动到不同的交换机端口。vMotion无法为C9800-CL无线管理VLAN发送反向地址解析协议(RARP),因为ESXi主机无法识别哪个VLAN是在虚拟机中运行的来宾操作系统。要支持此场景,您需要实施一种解决方法:在执行迁移之前,从C9800-CL对任何有线主机进行连续ping;这会触发交换机网络了解虚拟机的新位置(端口),从而更快地收敛。
在使用HA SSO的模拟迁移案例(例如,测试#4)中,冗余管理接口(RMI)用于检查到网关以及主用和备用之间的连通性,因此它会生成使交换机上的MAC地址表保持更新的流量,并且不会发生问题。
建议:为了获得最佳效果,建议将RP端口keepalive配置为至少是默认100毫秒keepalive的两倍(将其设置为200毫秒)。如果存储设备和主机之间的网络可能变得繁忙并延长延迟,请考虑将keepalives计时器设置为300毫秒。要在GUI上配置keepalive计时器,请转至Administration > Device > Redundancy:
在CLI上,在执行模式(非配置模式!)下使用此命令
C9800-SSO#chassis redundancy keep-alive timer 3
要验证,请使用以下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
已解决的警告:
以下是17.9.2中修复的警告:
Cisco Bug ID CSCwd17349 - C9800:在17.9上的SSO故障转移期间,主用机箱可能会卡住
摘要
可以使用VMware vSphere vMotion将C9800-CL VM从一台主机迁移到另一台主机,而不会影响无线网络操作。C9800-CL从版本17.9.2开始正式支持vMotion。