Introdução
Este documento descreve a falha de atualização de UPF baseada em RCM devido à ausência da entrada do host no configmgr
Problema
Quando o controlador RCM (Redundancy Configuration Manager) inicia uma alternância planejada de UPF (User Plane Function) de UPF 1 (Ative) para UPF 2 (Standby), espera-se que o configmgr tenha o UPF 1 e o UPF 2 em sua lista de hosts. Mas, por algum motivo, o configmgr não tem o UPF 1 ativo em sua lista de hosts ativos, contradizendo com a lista de hosts.no controlador
E quando o RCM aciona o switchover de UPF 1 para UPF 2 em tal condição, o processo de switchover é iniciado. Durante o processo de switchover, o configmgr tenta encontrar os detalhes do host UPF 1 ativo em sua lista de hosts, mas não consegue localizá-los.
O processo de switchover de UPF falha com o motivo "Ativo antigo movido de PendingStandby para Ativo devido ao tempo limite no estado de espera de recebimento (switchover planejado)" e UPF1 é movido de PendingStandby para Ativo e UPF 2 de PendingActive para Standby.
//Como detectar uma falha de switchover devido a detalhes de host ausentes do configmgr em sua lista de hosts
No comando RCM tac dbg que aborda esses tempos de falha de switchover, procure o evento de log no log do pod do configmgr.
2024/01/12 09:08:26.878 rcm-configmgr [DEBUG] [sshclient.go:980] [rcm_grpc_ep.msg-process.Int] [RcmGenTrap]: Trap SNMP gerado: (SwitchoverFailure) - Switchover de 10.248.187.151:2 2 para 10.248.187.153:22 em Grupo:1 Falha! Motivo: ativo não encontrado
Se o comando rcm tac dbg NÃO estiver presente, você também poderá confirmar se o switchover de UPF falhou devido a esse problema procurando a armadilha snmp do centro de operações do controlador RCM.
a) Faça login no centro de operações do RCM ativo
b) Execute o comando rcm show-snmp-trap history
c) Examine a armadilha snmp presente
SwitchoverFailure 2024-01-18T05:19:45.Z 2024-01-18T05:19:45.Z rcm-configmgr Switchover de 10.244.127.23:22 para 10.244.127.29:22 no grupo:1 Falha! Motivo: ativo não encontrado
Solução
Até que a correção permanente venha através da ID de bug Cisco CSCwi70133 A solução alternativa é excluir o pod do configmgr do nó principal do K8s AIO (All In One) correspondente, usando kubectl delete <configmgr-pod-name> -n <k8-name-space>
Exemplo:
1. Como parte das pré-verificações do fluxo de trabalho de automação da atualização UPF, as verificações para comparar a lista de hosts do controlador e do configmgr podem ser feitas. Se um host estiver ausente na lista de hosts do configmgr, a exclusão do pod do configmgr pode ser feita para que o configmgr obtenha a lista completa de hosts recentemente do controlador.
2. Se o switchover UPF estiver sendo fornecido manualmente, colete 2 saídas de comandos CLI do RCM ativo e compare-as para descobrir se algum Host (Ativo/Em espera) está faltando na saída do host do configmgr. Se algum host estiver ausente, emita a exclusão do pod do configmgr do nó principal do RCM AIO K8s e verifique novamente o controlador e a lista de hosts do configmgr. Se os hosts corresponderem no controlador e no configmgr, continue com a alternância manual de UPFs do controlador.
a) rcm show-statistics controller
b) rcm show-statistics configmgr