Esecuzione della manutenzione hardware in nodi IMS 5G e UPF di dati

Introduzione

In questo documento viene descritta la procedura per eseguire le attività di manutenzione nei nodi IP Multimedia Subsystem (IMS) e Data User Plane Function (UPF).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• 5G-UPF
• Redundancy Configuration Manager (RCM)
• Virtual Packet Core (VPC) - Istanza singola (SI)
• Hypervisor KVM (Virtual Machine) basato su kernel

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Subscriber Microservices Infrastructure (SMI) 2020.02.2.35
• Star OS 21.2

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Informazioni sulla UPF

L'interfaccia UPF (User Plane Interface) è una delle funzioni di rete (NF) della rete centrale 5G (5GC). È responsabile del routing e dell'inoltro dei pacchetti, dell'ispezione dei pacchetti, della gestione di QoS e di sessioni PDU esterne per l'interconnessione delle reti di dati (DN), nell'architettura 5G.

Cos'è VPC-SI?

VPC-SI consolida le operazioni dello chassis fisico Cisco ASR 5500 con StarOS in una singola macchina virtuale (VM) in grado di essere eseguita su server COTS (Commercial Off The Shelf). Ciascuna VM VPC-SI opera come istanza StarOS indipendente e incorpora le funzionalità di gestione e di processo di sessione di uno chassis fisico.

Che cos'è l'hypervisor KVM?

La tecnologia KVM (Kernel-based Virtual Machine) è una tecnologia di virtualizzazione open-source integrata in Linux. In particolare, la tecnologia KVM consente di trasformare Linux in un hypervisor che consente a un computer host di eseguire più ambienti virtuali isolati denominati guest o macchine virtuali (VM).

Che cos'è l'ICSR?

Interchassis Session Recovery (ICSR) è una funzione Cisco con licenza che richiede una licenza separata; questa funzione assicura la massima disponibilità possibile per il processo di chiamata continuo senza interruzione dei servizi dell'utente. L'ICSR consente all'operatore di configurare i gateway a scopo di ridondanza. In caso di errore di un gateway, ICSR consente di instradare in modo trasparente le sessioni intorno all'errore, mantenendo così l'esperienza utente. L'ICSR conserva inoltre le informazioni e lo stato della sessione.

Problema

La manutenzione dell'hardware, ad esempio un guasto dell'hardware o l'aggiornamento di software e firmware, e altro ancora, richiede tempi di inattività dei server. Questa procedura è necessaria per eseguire la manutenzione nei server baremetal UPF e per passare normalmente da un servizio all'altro in modo da evitare downtime indesiderati nell'applicazione UPF. 

Procedura di manutenzione

I nodi UPF sono VM StarOS ospitate nell'hypervisor KVM. Un hypervisor KVM ospita 2 istanze di VM. IMS UPF ha ridondanza 1:1, Ogni istanza attiva ha un'istanza in standby. per gestire la ridondanza, utilizza l'ICSR insieme al protocollo SRP (Session Redundancy Protocol). Il protocollo SRP viene utilizzato per lo scambio di messaggi di saluto tra chassis ICSR. Scambia inoltre le informazioni sullo stato della sessione tra lo chassis attivo/standby (dati del checkpoint). Le informazioni complete sulla sessione dell'abbonato vengono inviate dallo chassis ATTIVO allo chassis STANDBY sotto forma di record di recupero della chiamata (CRR), tramite il collegamento SRP.

Accedere al nodo KVM ed elencare le istanze di VM con il 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:~$

Accedere all'istanza UPF e verificare lo stato dello chassis.

[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 

Verificare se il numero di righe è lo stesso sulla coppia ICSR in standby attiva per 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

Verificare se il gestore di sessione SRP si trova nello stato di connessione attiva prima del passaggio SRP all'UPF attivo e assicurarsi che non vi sia uno stato di connessione attiva in sospeso.

[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

Verificare se lo stato di sessmgr SRP è attivo prima del passaggio a SRP in modalità di standby UPF e assicurarsi che non vi sia uno stato in sospeso-attivo

[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 uno dei due è nello stato Attivo, è necessario eseguire le seguenti attività prima del passaggio:

[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

Prima di arrestare la VM, è necessario verificare che le istanze attive siano passate alla modalità standby in modo che i sottoscrittori vengano passati normalmente. Se l'istanza è già in standby, non è necessaria alcuna azione. Se la variante è attiva, controllate i valori evidenziati e assicuratevi che lo standby sia pronto a subentrare.

Controllare i sottoscrittori correnti nell'istanza UPF attiva.

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

Total Subscribers : 175024 
Active : 175024 Dormant : 0

Passare all'istanza attiva in standby.

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

Controllare lo stato della modalità standby che sarebbe diventata attiva e le sessioni sottoscrittore vengono spostate nella nuova istanza attiva. Ora, poiché entrambe le istanze di VM sono in stato di standby, è consigliabile disattivarle per la manutenzione del server. Utilizzare i comandi virsh forniti per arrestare le istanze della VM e verificare lo stato.

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:~$

Una volta ripristinato il server dopo la manutenzione, le VM vengono avviate automaticamente. Le istanze UPF rimangono in standby. verificare con il comando specificato.

[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 

Data UPF utilizza RCM con ridondanza N:M, dove N è un numero di UPF attivi inferiore a 10 e M è un numero di UP in standby nel gruppo di ridondanza. RCM è un nodo proprietario di Cisco o funzione di rete (NF) che fornisce ridondanza per le funzioni UPF (User Plane Functions) basate su StarOS. Memorizza o esegue il mirroring di tutte le informazioni sulla sessione richieste da tutti i file UPF attivi. In un trigger di switchover, viene selezionato un UPF di standby per ricevere i dati della sessione appropriati dalla posizione comune. RCM viene eseguito in un cluster K3 su una macchina virtuale. Il centro operativo configura il nodo RCM. 

I nodi UPF di dati sono anche gli stessi dei nodi UPF di IMS. L'unica differenza è rappresentata dalla gestione della ridondanza di RCM. 

Controllare lo stato della VM nel nodo 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:~$

Dopo aver effettuato l'accesso all'istanza UPF, controllare lo stato di ridondanza di RCM. Se l'istanza è già in standby, non è necessaria alcuna azione. Se è attiva, deve essere passata normalmente alla modalità 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#

Verificare se tutti i sessmgr si trovano in uno stato di connessione attiva.

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

 Identificare il nodo RCM corrispondente dal CIQ (Customer Information Questionnaire) e controllare lo stato di RCM. Il passaggio a RCM può essere eseguito solo dal nodo master. Accertarsi di accedere a RCM master.

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

Trovare i nodi UPF attivo e in standby con il comando specificato (output troncato):

[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
},

 Accedere all'istanza UPF in standby con l'indirizzo IP di gestione e verificare lo stato

[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#

Dopo la verifica, passare con grazia alla modalità di standby attiva. Assicurarsi di utilizzare l'indirizzo IP di gestione.

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

Nota: Nel caso dopo il passaggio se la nuova sessione attiva è bloccata nello stato SERVER. Contattare il supporto tecnico Cisco. In caso di problemi, sessmgr deve essere terminato, quindi si riconnette a RCM con il corretto stato del socket del CLIENT e viene ripristinato. Tutti i programmi di gestione sessione devono essere in stato CLIENT. Verificare con il comando specificato (in modalità nascosta).

# 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

Verificare che lo stato di tutti gli oggetti sessmgr sia attivo 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

Verificare che i sottoscrittori vengano spostati nel nuovo standby:

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

Total Subscribers : 62259 
Active : 62259 Dormant : 0

Quando entrambe le istanze sono in standby, le VM possono essere chiuse da KVM con comandi 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 le VM vengono spente, il nodo KVM (server fisico) può essere disattivato per manutenzione. Al termine, avviare il server. Le VM vengono attivate automaticamente. Le istanze UPF diventano in standby singolarmente. Verificare lo stesso con i comandi specificati.

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#

Nel nodo RCM, il controller rcm può ancora visualizzare il file UPF di standby come "standby in sospeso". L'operazione può richiedere da 15 a 20 minuti per passare alla modalità standby. Verificare la stessa condizione con i comandi specificati (output troncato):

[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
},