Executar Manutenção de Hardware em Nós IMS 5G e UPF de Dados

Introduction

Este documento descreve o procedimento para executar atividades de manutenção nos nós IMS (IP Multimedia Subsystem) e UPF (Data User Plane Function).

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• 5G-UPF
• Gerenciador de Configuração de Redundância (RCM)
• Núcleo do Pacote Virtual (VPC) - Instância única (SI)
• Hipervisor de máquina virtual (KVM) baseado em kernel

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Infraestrutura de Microserviços de Assinante (SMI) 2020.02.2.35
• Star OS 21.22

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

O que é UPF?

A User Plane Interface (UPF) é uma das funções de rede (NFs) da rede central 5G (5GC). Ele é responsável pelo roteamento e encaminhamento de pacotes, inspeção de pacotes, QoS de tratamento e sessões de PDU externas para interconectar Redes de Dados (DN), na arquitetura 5G.

O que é VPC-SI?

O VPC-SI consolida as operações do chassi físico do Cisco ASR 5500 que executa o StarOS em uma única máquina virtual (VM) capaz de ser executada em servidores comerciais (COTS). Cada VM VPC-SI opera como uma instância independente do StarOS e incorpora os recursos de gerenciamento e processo de sessão de um chassi físico.

O que é o hipervisor KVM?

A KVM (Kernel-based Virtual Machine, Máquina virtual baseada em kernel) é uma tecnologia de virtualização de código aberto incorporada ao Linux. Especificamente, o KVM permite que você transforme o Linux em um hipervisor que permite que uma máquina host execute vários ambientes virtuais isolados chamados de convidados ou máquinas virtuais (VMs).

O que é ICSR?

O Interchassis Session Recovery (ICSR) é um recurso licenciado da Cisco que requer uma licença separada; esse recurso fornece a maior disponibilidade possível para o processo de chamada contínua sem interrupção dos serviços de assinante. O ICSR permite que o operador configure gateways para fins de redundância. No caso de uma falha de gateway, o ICSR permite que as sessões sejam roteadas de forma transparente em torno da falha, mantendo assim a experiência do usuário. O ICSR também preserva as informações e o estado da sessão.

Problema

A manutenção de hardware, como falha de hardware ou atualização de software/firmware, e outros, precisam de tempo de inatividade nos servidores. Este procedimento precisa ser seguido para que a manutenção seja executada nos servidores UPF baremetal e como alternar os serviços normalmente para evitar tempo de inatividade indesejado no aplicativo UPF. 

Procedimento de manutenção

Os nós UPF são VMs StarOS hospedadas no hipervisor KVM. Um hipervisor KVM hospeda 2 instâncias de VM. O IMS UPF tem redundância de 1:1. Cada instância ativa tem uma instância em espera. ele usa ICSR junto com o Session Redundancy Protocol (SRP) para lidar com a redundância. O SRP é usado para trocar mensagens hello entre chassis ICSR. Ele também troca informações de estado da sessão entre o chassi ativo/standby (dados de ponto de verificação). As informações completas da Sessão do Assinante são enviadas do Chassi ATIVO para o Chassi STANDBY na forma de um Registro de Recuperação de Chamada (CRR), através do link SRP.

Faça login no nó KVM e liste as instâncias de VM com o comando virsh KVM.

cloud-user@podname-upf-ims-kvmnode-1:~$ sudo virsh list --all
Id Name State
----------------------------------------------------
1 imsupf01 running
4 imsupf10 running

cloud-user@podname-upf-ims-kvmnode-1:~$

Faça login na instância do UPF e verifique o status do chassi.

[local]imsupf10# show srp info
Friday July 22 15:50:24 UTC 2022
Service Redundancy Protocol:
-------------------------------------------------------------------------------
Context: srp 
Local Address: 10.x.x.74
Chassis State: Standby 
Chassis Mode: Backup 
Chassis Priority: 2 
Local Tiebreaker: 02-7E-35-53-F9-F1
Route-Modifier: 9 

Peer Remote Address: 10.x.x.73
Peer State: Active 
Peer Mode: Primary 
Peer Priority: 1 
Peer Tiebreaker: 02-11-59-73-87-35
Peer Route-Modifier: 8 
Last Hello Message received: Fri Jul 22 15:50:21 2022 (3 seconds ago)
Peer Configuration Validation: Complete 
Last Peer Configuration Error: None 
Last Peer Configuration Event: Fri Jul 22 15:50:22 2022 (2 seconds ago)
Last Validate Switchover Status: None 
Connection State: Connected 

[local]imsupf01# show srp info
Friday July 22 15:31:20 UTC 2022
Service Redundancy Protocol:
-------------------------------------------------------------------------------
Context: srp 
Local Address: 10.x.x.66
Chassis State: Active 
Chassis Mode: Backup 
Chassis Priority: 2 
Local Tiebreaker: 02-7C-1A-62-FA-3C
Route-Modifier: 5 

Peer Remote Address: 10.x.x.65
Peer State: Standby 
Peer Mode: Primary 
Peer Priority: 1 
Peer Tiebreaker: 02-87-33-98-6D-08
Peer Route-Modifier: 6 
Last Hello Message received: Fri Jul 22 15:31:20 2022 (1 seconds ago)
Peer Configuration Validation: Complete 
Last Peer Configuration Error: None 
Last Peer Configuration Event: Fri Jul 22 15:20:13 2022 (668 seconds ago)
Last Validate Switchover Status: None 
Connection State: Connected 

Verifique se o número de linhas é o mesmo no par ICSR ativo-em espera para IMS UPF.

Active node 
# show configuration | grep -n -E "^end$" 
Thursday July 21 07:30:17 UTC 2022
14960:end

Standby Node
# show configuration | grep -n -E "^end$" 
Thursday July 21 07:31:02 UTC 2022
14959:end

Verifique se o sessmgr do SRP está no estado conectado ativo antes da alternância do SRP no UPF ativo e verifique se não há um estado ativo pendente.

[local]imsupf01# show srp checkpoint statistics active 
Thursday July 21 07:38:04 UTC 2022
Number of Sessmgrs: 20
Sessmgrs in Active-Connected state: 20
Sessmgrs in Standby-Connected state: 0
Sessmgrs in Pending-Active state: 0

Verifique se o Sessmgr do SRP está no estado conectado ativo antes do switchover do SRP no UPF em standby e verifique se não há um estado ativo pendente

[local]imsupf02# show srp checkpoint statistics active
Thursday July 21 07:40:03 UTC 2022
Number of Sessmgrs: 20
Sessmgrs in Active-Connected state: 0
Sessmgrs in Standby-Connected state: 20
Sessmgrs in Pending-Active state: 0

Se qualquer um desses dois estiver em um estado Ativo, você precisará executar primeiro estas tarefas antes da alternância:

[upf-ims]# save config /flash/xxx_production.cfg. --> Replace xxx with the desired name of the config
[upf-ims]# srp validate-configuration
[upf-ims]# srp validate-switchover

Antes do desligamento da VM, você precisa garantir que as instâncias Ativas sejam comutadas para espera para que os assinantes sejam alternados normalmente. Se a instância já estiver em standby, nenhuma ação será necessária. Se a instância estiver ativa, verifique os valores destacados e se o standby está pronto para assumir o controle.

Verifique os assinantes atuais na instância ativa do UPF.

[local]imsupf01# show subscribers data-rate summary 
Friday July 22 16:01:37 UTC 2022

Total Subscribers : 175024 
Active : 175024 Dormant : 0

Alterne a instância ativa para standby.

[context-name]<hostname># srp initiate-switchover

Verifique o status do standby, que já teria se tornado ativo, e as sessões do assinante também serão movidas para a nova instância ativa. Agora, como as duas instâncias de VM estão no estado de espera, elas estão prontas para serem desativadas para manutenção do servidor. Use determinados comandos virsh para encerrar as instâncias da VM e verificar o status.

cloud-user@podname-upf-ims-kvmnode-1:~$ sudo virsh shutdown imsupf01
Domain imsupf01 is being shutdown
cloud-user@podname-upf-ims-kvmnode-1:~$ sudo virsh shutdown imsupf10
Domain imsupf10 is being shutdown
cloud-user@podname-upf-ims-kvmnode-1:~$ sudo virsh list --all
Id Name State
----------------------------------------------------
1 imsupf01 shut off
4 imsupf10 shut off

cloud-user@podname-upf-ims-kvmnode-1:~$

Quando o servidor é retornado após a manutenção, as VMs são iniciadas automaticamente. As instâncias do UPF permanecem em espera. verificar com o comando fornecido.

[local]imsupf10# show srp info
Friday July 22 15:50:24 UTC 2022
Service Redundancy Protocol:
-------------------------------------------------------------------------------
Context: srp 
Local Address: 10.x.x.74
Chassis State: Standby 
Chassis Mode: Backup 
Chassis Priority: 2 
Local Tiebreaker: 02-7E-35-53-F9-F1
Route-Modifier: 9 

Peer Remote Address: 10.x.x.73
Peer State: Active 
Peer Mode: Primary 
Peer Priority: 1 
Peer Tiebreaker: 02-11-59-73-87-35
Peer Route-Modifier: 8 
Last Hello Message received: Fri Jul 22 15:50:21 2022 (3 seconds ago)
Peer Configuration Validation: Complete 
Last Peer Configuration Error: None 
Last Peer Configuration Event: Fri Jul 22 15:50:22 2022 (2 seconds ago)
Last Validate Switchover Status: None 
Connection State: Connected 

A UPF de Dados usa o RCM que tem redundância N:M, em que N é um número de UPFs Ativos e é menor que 10, e M é um número de UPs em Espera no grupo de redundância. O RCM é um nó proprietário ou função de rede (NF) da Cisco que fornece redundância para UPFs baseadas em StarOS. Ele armazena ou espelha todas as informações de sessão necessárias de todo o UPF Ativo. Em um gatilho de alternância, uma UPF em Espera é selecionada para receber os dados de sessão apropriados do local comum. O RCM é executado em um cluster K3 em uma VM. O Centro de Operações configura o nó RCM. 

Os nós UPF de dados também são os mesmos que os nós UPF do IMS. A única diferença é o gerenciamento de redundância RCM. 

Verifique o status da VM no nó KVM.

cloud-user@podname-upf-data-kvmnode-1:~$ sudo virsh list --all
Id Name State
----------------------------------------------------
1 dataupf20 running
2 dataupf11 running

cloud-user@podname-upf-data-kvmnode-1:~$

Após fazer login na instância UPF, verifique o status de redundância RCM. Se a instância já estiver em standby, nenhuma ação será necessária. Se estiver ativo, ele precisará ser alternado normalmente para standby.

[local]dataupf11# show rcm info
Friday July 22 17:23:17 UTC 2022
Redundancy Configuration Module:
-------------------------------------------------------------------------------
Context: rcm 
Bind Address: 10.x.x.75
Chassis State: Active 
Session State: SockActive 
Route-Modifier: 26 
RCM Controller Address: 10.x.x.163
RCM Controller Port: 9200 
RCM Controller Connection State: Connected 
Ready To Connect: Yes 
Management IP Address: 10.x.x.149
Host ID: DATAUPF15
SSH IP Address: 10.x.x.158 (Activated)
SSH IP Installation: Enabled

[local]dataupf11#

Verifique se todos os sessmgr estão em um estado Conectado ativo.

local]dataupf11# show rcm checkpoint statistics active
Thursday July 21 07:47:03 UTC 2022
Number of Sessmgrs: 22
Sessmgrs in Active-Connected state: 22
Sessmgrs in Standby-Connected state: 0
Sessmgrs in Pending-Active state: 0

 Identifique o nó RCM correspondente do CIQ (Questionário de informações do cliente) e verifique o status do RCM. Observe que o switchover de RCM pode ser feito somente a partir do nó mestre. Certifique-se de fazer login no RCM mestre.

[podname-aio-1/dcrm01] rcm# rcm show-status
message :
{"status":"MASTER"}
[podname-aio-1/dcrm01] rcm# 

Localize os nós UPF ativo e standby com o comando fornecido (saída truncada):

[podname-aio-1/dcrm01] rcm# rcm show-statistics controller 
message :
{
"keepalive_version": "e7386cb81b1fefc3396dfd1d528e0d2a27de80d5de6a78364caf938a0d2149b6",
"keepalive_timeout": "20s",
"num_groups": 2,
"groups": [
{
"groupid": 1,
"endpoints_configured": 7,
"standby_configured": 1,
"pause_switchover": false,
"active": 6,
"standby": 1,
"endpoints": [
{
"endpoint": "10.x.x.75",
"bfd_status": "STATE_UP",
"upf_registered": true,
"upf_connected": true,
"upf_state_received": "UpfMsgState_Active",
"bfd_state": "BFDState_UP",
"upf_state": "UPFState_Active",
"route_modifier": 26,
"pool_received": true,
"echo_received": 142354,
"management_ip": "10.x.x.149",
"host_id": "DATAUPF15",
"ssh_ip": "10.x.x.158",
"force_nso_registration": false

....

....

 {
"endpoint": "10.x.x.77",
"bfd_status": "STATE_UP",
"upf_registered": true,
"upf_connected": true,
"upf_state_received": "UpfMsgState_Standby",
"bfd_state": "BFDState_UP",
"upf_state": "UPFState_Standby",
"route_modifier": 50,
"pool_received": false,
"echo_received": 3673,
"management_ip": "10.x.x.153",
"host_id": "",
"ssh_ip": "10.x.x.186",
"force_nso_registration": false
},

 Faça login na instância UPF standby com o IP de gerenciamento e verifique o status

[local]dataupf13# show rcm info
Friday July 22 17:36:04 UTC 2022
Redundancy Configuration Module:
-------------------------------------------------------------------------------
Context: rcm 
Bind Address: 10.x.x.77
Chassis State: Standby 
Session State: SockStandby 
Route-Modifier: 50 
RCM Controller Address: 10.x.x.163
RCM Controller Port: 9200 
RCM Controller Connection State: Connected 
Ready To Connect: Yes 
Management IP Address: 10.x.x.153
Host ID: 
SSH IP Address: 10.x.x.186 (Activated)
SSH IP Installation: Enabled

[local]dataupf13#

Após a verificação, mude tranquilamente o ativo para o standby. Certifique-se de usar o IP de gerenciamento.

[podname-aio-1/dcrm01] rcm# rcm switchover-mgmt-ip source 10.x.x.149 destination 10.x.x.153 

Note: No caso após switchover, se o novo Ative UP sessmgr estiver preso no estado SERVER. Entre em contato com o suporte técnico da Cisco. Em caso de ocorrências problemáticas, o sessmgr deve ser eliminado, assim ele se reconecta ao RCM com o estado de soquete CLIENT apropriado e se recupera. Todo o sessmgr precisa estar no estado CLIENT. Verifique-o com o comando fornecido (no modo oculto).

# show session subsystem facility sessmgr all debug-info | grep -E "SessMgr|Mode:" 
Thursday July 21 07:56:26 UTC 2022
SessMgr: Instance 5000
Mode: UNKNOWN State: SRP_SESS_STATE_SOCK_ACTIVE
SessMgr Activity Detected: FALSE
SessMgr: Instance 22
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE
SessMgr Activity Detected: TRUE
SessMgr: Instance 21
Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE
SessMgr Activity Detected: TRUE

verifique se todos os sessmgr estão nos estados ativo e pronto.

# show rcm checkpoint statistics verbose 
Thursday July 21 07:52:29 UTC 2022
smgr state peer recovery pre-alloc chk-point rcvd chk-point sent
inst conn records calls full micro full micro
---- ------- ----- ------- -------- ----- ----- ----- ----
1 Actv Ready 0 0 1731 68120 3107912 409200665
2 Actv Ready 0 0 1794 70019 3060062 408647685
3 Actv Ready 0 0 1753 68793 3078531 406227415
4 Actv Ready 0 0 1744 67585 3080952 410218643
5 Actv Ready 0 0 1749 69155 3096067 404944553
6 Actv Ready 0 0 1741 68805 3067392 407133464
7 Actv Ready 0 0 1744 67963 3084023 406772101
8 Actv Ready 0 0 1748 68702 3009558 408073589
9 Actv Ready 0 0 1736 68169 3030624 405679108
10 Actv Ready 0 0 1707 67386 3071592 406000628
11 Actv Ready 0 0 1738 68086 3052899 407991476
12 Actv Ready 0 0 1720 68500 3102045 408803079
13 Actv Ready 0 0 1772 69683 3082235 406426650
14 Actv Ready 0 0 1727 66900 2873736 392352402
15 Actv Ready 0 0 1739 68465 3032395 409603844
16 Actv Ready 0 0 1756 69221 3063447 411445527
17 Actv Ready 0 0 1755 68708 3051573 406333047
18 Actv Ready 0 0 1698 66328 3066983 407320405
19 Actv Ready 0 0 1736 68030 3037073 408215965
20 Actv Ready 0 0 1733 67873 3069116 405634816
21 Actv Ready 0 0 1763 69259 3074942 409802455
22 Actv Ready 0 0 1748 68228 3051222 406470380

Verifique se os assinantes foram movidos para o novo standby:

[local]dataupf11# show subscribers data-rate summary 
Friday July 22 17:40:18 UTC 2022

Total Subscribers : 62259 
Active : 62259 Dormant : 0

Quando ambas as instâncias estão em espera, as VMs podem ser desligadas do KVM com comandos virsh.

cloud-user@podname-upf-data-kvmnode-1:~$ sudo virsh shutdown dataupf20
Domain dataupf20 is being shutdown
cloud-user@podname-upf-data-kvmnode-1:~$ sudo virsh shutdown dataupf11
Domain dataupf11 is being shutdown
cloud-user@podname-upf-data-kvmnode-1:~$ sudo virsh list --all
Id Name State
----------------------------------------------------
1 dataupf20 shut off
4 dataupf11 shut off

cloud-user@podname-upf-data-kvmnode-1:~$

Quando as VMs são desligadas, o nó KVM (servidor físico) pode ser desativado para manutenção. Depois de concluído, inicie o servidor. As VMs são ativadas automaticamente. As instâncias do UPF ficam em espera por conta própria. Verifique o mesmo com os comandos fornecidos.

cloud-user@podname-upf-data-kvmnode-1:~$ sudo virsh list --all
Id Name State
----------------------------------------------------
1 dataupf20 running
2 dataupf11 running

cloud-user@podname-upf-data-kvmnode-1:~$

[local]dataupf11# show rcm info
Friday July 22 17:36:04 UTC 2022
Redundancy Configuration Module:
-------------------------------------------------------------------------------
Context: rcm 
Bind Address: 10.x.x.77
Chassis State: Standby 
Session State: SockStandby 
Route-Modifier: 50 
RCM Controller Address: 10.x.x.163
RCM Controller Port: 9200 
RCM Controller Connection State: Connected 
Ready To Connect: Yes 
Management IP Address: 10.x.x.153
Host ID: 
SSH IP Address: 10.x.x.186 (Activated)
SSH IP Installation: Enabled

[local]dataupf13#

No nó RCM, o controlador rcm ainda pode mostrar o UPF em espera como "standby pendente". Isso pode levar de 15 a 20 minutos para transformar em standby. Verifique o mesmo com os comandos fornecidos (saída truncada):

[podname-aio-1/dcrm01] rcm# rcm show-statistics controller 
message :
{
"keepalive_version": "e7386cb81b1fefc3396dfd1d528e0d2a27de80d5de6a78364caf938a0d2149b6",
"keepalive_timeout": "20s",
"num_groups": 2,
"groups": [
{
"groupid": 1,
"endpoints_configured": 7,
"standby_configured": 1,
"pause_switchover": false,
"active": 6,
"standby": 1,
"endpoints": [
....
....
{
"endpoint": "10.x.x.77",
"bfd_status": "STATE_UP",
"upf_registered": true,
"upf_connected": true,
"upf_state_received": "UpfMsgState_Standby",
"bfd_state": "BFDState_UP",
"upf_state": "UPFState_Standby",
"route_modifier": 50,
"pool_received": false,
"echo_received": 3673,
"management_ip": "10.x.x.153",
"host_id": "",
"ssh_ip": "10.x.x.186",
"force_nso_registration": false
},