目录

简介

先决条件

要求

拓扑

测试结果

摘要

简介

本文档介绍为验证在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)。表示测试拓扑的图：

测试结果

对于这些测试，需要考虑两种迁移方案：

1. 独立C9800-CL在服务器接口和服务器#1口之间迁#2

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。