Einleitung
In diesem Dokument wird der Fehler des RCM-basierten UPF-Upgrades beschrieben, da der Host-Eintrag im Konfigurationsmgr fehlt.
Problem
Wenn der RCM-Controller (Redundancy Configuration Manager) einen geplanten UPF-Switchover (Benutzerebenenfunktion) von UPF 1 (aktiv) zu UPF 2 (Standby) initiiert, muss der Konfigurationsmanager in seiner Hostliste sowohl UPF 1 als auch UPF 2 enthalten. Aus irgendeinem Grund enthält configmgr den aktiven UPF 1 nicht in der Liste der aktiven Hosts, was im Widerspruch zum Controller host list.on steht
Wenn der RCM in diesem Zustand einen Switchover von UPF 1 zu UPF 2 auslöst, wird der Switchover-Prozess initiiert. Während des Switchover-Prozesses versucht der Konfigurations-Manager, die Details des aktiven UPF 1-Hosts in seiner Hostliste zu finden, sucht jedoch nicht danach.
Der UPF-Switchover-Prozess schlägt fehl, weil "Old Active" aufgrund eines Timeouts beim Empfang des Standby-Status (geplanter Switchover) von "PendingStandby" nach "Active" und UPF1 von "PendingActive" nach "Standby" verschoben wurde.
// How to detect switchover failure is due to config mgr missing host details in its host list
Suchen Sie im RCM tac dbg, der solche Switchover-Ausfallzeiten abdeckt, im POD-Protokoll von configmgr nach Protokollereignissen.
2024/01/12 09:08:26.878 rcm-configmgr [DEBUG] [sshclient.go:980] [rcm_grpc_ep.msg-process.Int] [RcmGenTrap]: SNMP-Trap ausgelöst: (Switching choverFailure) - Wechsel von 10.248.187.151:22 auf 10.248.187.153:22 in Gruppe:1: Fehlgeschlagen! Grund: Aktiv nicht gefunden
Wenn rcm tac dbg NICHT vorhanden ist, können Sie auch bestätigen, dass der UPF-Switchover aufgrund dieses Problems fehlgeschlagen ist, indem Sie nach SNMP-Trap vom RCM Controller-Betriebscenter suchen.
a) Anmeldung bei aktivem RCM-Betriebszentrum
b) Führen Sie den Befehl rcm show-snmp-trap history aus
c) Suche in vorhandenen SNMP-Traps
SwitchoverFailure 2024-01-18T05:19:45.Z 2024-01-18T05:19:45.Z rcm-configmgr Switchover von 10.244.12 7.23:22 bis 10.244.127.29:22 in Gruppe:1: Fehlgeschlagen! Grund: Aktiv nicht gefunden
Lösung
Bis zur endgültigen Behebung des Fehlers: Cisco Bug-ID: CSCwi70133 Die Problemumgehung besteht darin, den configmgr-POD aus dem entsprechenden AIO (All In One) K8s-Master-Knoten zu löschen. Hierzu wird kubectl delete <configmgr-pod-name> -n <k8-name-space> verwendet.
Beispiel:
1. Im Rahmen der Vorabprüfungen des Automatisierungs-Workflows für das UPF-Upgrade können Prüfungen zum Vergleich des Controllers und der Host-Liste "configmgr" durchgeführt werden. Wenn ein Host in der configmgr-Hostliste fehlt, kann configmgr pod gelöscht werden, sodass configmgr die komplette Hostliste direkt vom Controller erhält.
2. Wenn ein UPF-Switchover manuell durchgeführt wird, sammeln Sie zwei CLI-Befehlsausgaben des aktiven RCM, und vergleichen Sie sie, um festzustellen, ob ein Host (Aktiv/Standby) in der Host-Ausgabe von configmgr fehlt. Falls ein Host fehlt, geben Sie den Befehl configmgr pod delete vom RCM AIO K8s-Master-Knoten ein, und überprüfen Sie erneut den Controller und die configmgr-Host-Liste. Wenn die Hosts auf dem Controller und dem Konfigurationsmanager übereinstimmen, fahren Sie mit dem manuellen Switchover der UPFs vom Controller fort.
a) RCM Show-Statistics-Controller
b) rcm show-statistics config-mgr