目錄

簡介

必要條件

需求

拓撲

測試結果

摘要

簡介

本文檔介紹為驗證在vSphere ESXi上運行的C9800-CL的vMotion支援而進行的測試。

必要條件

C9800-CL是Catalyst 9800無線LAN控制器的虛擬機器外形。您可以使用VMware vSphere vMotion執行Catalyst 9800-CL從一個主機伺服器到另一個主機伺服器的零停機即時遷移。vSwitch和集群中均可實現此功能。其目標是，在C9800-CL即時遷移期間，無線網路保持運行，無線使用者繼續擁有所需的連線。

vMotion可以手動完成，也可以作為VMware vSphere Distributed Resource Scheduler(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關於主機、遠端共用儲存和網路的VMware准則在此處配置vMotion。

- 在此處符合vMotion的VMware網路要求。

拓撲

對於這些驗證測試，使用了一個簡單的拓撲結構，用於三個不同的伺服器主機和iSCSI遠端儲存（也可以使用NFS儲存）。遠端儲存利用與伺服器的10 Gbps連線。在ESXi主機上，一個C9800-CL虛擬機器在獨立模式下建立，另外兩個為狀態切換高可用性(SSO HA)配置的C9800-CL虛擬機器。HA對是在兩個不同的伺服器之間建立，以實現實體備援，而且可以分別遷移作用中WLC和備用WLC。每個C9800-CL虛擬機器都使用三個埠連線到虛擬交換機：

- G1 > SP埠（可選）

- G2 >無線管理介面(WMI)VLAN和客戶端VLAN的中繼埠（如果存在）

- G3 > RP埠。這是用於建立SSO群集的。未連線到獨立模式

每台主機伺服器都有一個專用物理埠和專用交換機（交換機1），用於通過L2鏈路跨伺服器將RP埠連線在一起。另外兩個物理埠連線到一個單獨的上行鏈路交換機（交換機2）。表示測試拓撲的圖：

測試結果

對於這些測試，需要考慮兩種遷移方案：

1. 獨立C9800-CL在伺服器交換機和伺服器#1間進行遷#2

2. 配置為SSO高可用性的一對C9800-CL。在此案例中，首先在伺服器介面和伺服器介面之間#1移作用中#3WLC，然後將待命WLC從伺服器介面移#2到伺服器介#3面

在這兩種情況下，所有三種不同型別的vMotion遷移都經過測試：僅計算資源、僅儲存、計算和儲存。

要觸發vMotion，只需右鍵點選虛擬機器，然後點選遷移：

選擇遷移型別並完成以下步驟：

以下是每個測試的結果：

測試

獨立C9800-CL

vMotion型別

意見/評論

1

僅計算資源

不支援: 由於虛擬訪客標籤(802.1q VLAN)問題，AP和客戶端被丟棄，並在一段時間後恢復：知識庫文章

因應措施: 開始從控制器對任意有線網路裝置執行ping操作

2

僅儲存

支援:AP和客戶端穩定，出現單一ping丟棄

3

計算資源和儲存

不支援: 由於虛擬訪客標籤(802.1q VLAN)問題，AP和客戶端被丟棄，並在一段時間後恢復：知識庫文章

因應措施：開始從控制器對任意有線網路裝置執行ping操作

測試

SSO活動

HA keepalive:100毫秒

vMotion型別

4

僅計算資源

支援 : 由於HA RP keepalive已過期，導致在活動狀態時流量穩定，出現備用堆疊合併重新載入

5

僅儲存

支援 : 流量穩定，大部分時間在RP keepalive計時器到期之前RP啟動，因此不會看到堆疊合併

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操作後也保持穩定

如下表所示，在獨立模式C9800-CL的第一和第三場景(測試#1和#3)中，vMotion在執行計算或計算和儲存遷移時失敗；在這種情況下，C9800-CL的WMI的MAC和IP地址移動到新主機，因此移動到不同的交換機埠。vMotion無法為C9800-CL無線管理VLAN傳送反向地址解析協定(RARP)，因為ESXi主機無法識別哪個VLAN是運行在虛擬機器中的來賓作業系統。要支援此場景，您需要實施一種變通方法：從C9800-CL連續不斷地向任何有線主機執行ping操作，然後再執行遷移；這會觸發交換機網路瞭解VM的新位置（埠），從而更快地收斂。

在使用HA SSO的類比遷移案例(例如測試#4)中，會利用備援管理介面(RMI)來檢查閘道以及主動和備用之間的連線能力，因此它會產生保持交換器上MAC位址表更新的流量，且不會發生問題。

建議：為了獲得最佳結果，建議將RP埠keepalive配置為至少是預設100 ms keepalive的兩倍（將其設定為200 ms）。如果儲存器和主機之間的網路可能會變得繁忙並延長延遲，請考慮將keepalive計時器設定為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中修復的警告：

思科錯誤ID CSCwd17349 - C9800：在17.9上的SSO故障切換期間，主用機箱可能會停滯

摘要

可以使用VMware vSphere vMotion將C9800-CL VM從一個主機遷移到另一個主機，而不會影響無線網路操作。自17.9.2版起，C9800-CL正式支援vMotion。