簡介
本文檔介紹為驗證在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)。表示測試拓撲的圖:
測試結果
對於這些測試,需要考慮兩種遷移方案:
- 獨立C9800-CL在伺服器交換機和伺服器#1間進行遷#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。