簡介
本文檔描述由於configmgr缺少主機條目而導致的基於RCM的UPF升級失敗
問題
當RCM(冗餘配置管理器)控制器啟動計畫的UPF(使用者平面功能)從UPF 1(活動)切換到UPF 2(備用)時,configmgr應在其主機清單中同時包含UPF 1和UPF 2。但由於某種原因,configmgr在其活動主機清單中沒有活動UPF 1,與控制器上的主機清單衝突。
並且當RCM觸發UPF 1切換到UPF 2時,切換過程被啟動。在切換過程中,configmgr會嘗試在其主機清單中查詢活動UPF 1主機詳細資訊,但查詢失敗。
UPF切換過程失敗,原因是「Old Active由於接收待機狀態超時(計畫的切換)而從PendingStandby移動到Active」,並且UPF1從PendingStandby移動到Active,UPF 2從PendingActive移動到Standby。
//如何檢測切換故障是由於configmgr在其主機清單中缺少主機詳細資訊
在涵蓋此類切換失敗時間的RCM tac dbg中,在configmgr pod日誌中查詢日誌事件。
2024/01/12 09:08:26.878 rcm-configmgr [DEBUG] [sshclient.go:980] [rcm_grpc_ep.msg-process.Int] [RcmGenTrap]:引發的SNMP陷阱:(切換失敗) — 從10.248.187.151:22 到10.248.18 Group:1中的153:22失敗!原因:找不到活動
如果rcm tac dbg不存在,您還可以通過從RCM控制器ops-center查詢snmp陷阱來確認由於此問題導致的UPF切換失敗。
a)登入到活動RCM運營中心
b)運行命令rcm show-snmp-trap history
c)檢視存在的snmp陷阱陷阱
切換故障2024-01-18T05:19:45.Z 2024-01-18T05:19:45.Z rcm-configmgr 從組:10.244.127.23:22到組:1中10.247.29:22的切換失敗!原因:找不到活動
解決方案
永久修正之前可通過思科錯誤ID CSCwi70133 解決方法是使用kubectl delete <configmgr-pod-name> -n <k8-name-space>,從相應的AIO(一體化)K8s主節點中刪除configmgr pod
範例:
1.作為UPF升級自動化工作流的預檢查的一部分,可以進行檢查以比較控制器和configmgr主機清單。如果configmgr主機清單中缺少主機,可以完成configmgr pod刪除,以便configmgr從控制器獲取完整的主機清單。
2.如果手動提供UPF切換,請從活動RCM收集2個CLI命令輸出並進行比較,以查詢configmgr主機輸出中是否缺少任何主機(活動/備用)。如果缺少任何主機,請從RCM AIO K8的主節點發出configmgr pod delete命令,並重新檢查控制器和configmgr主機清單。如果控制器和configmgr上的主機匹配,請繼續從控制器手動切換UPF。
a)rcm show-statistics控制器
b)rcm show-statistics configmgr