Effectuer la maintenance du matériel dans les noeuds IMS 5G et UPF de données

Introduction

Ce document décrit la procédure à suivre pour effectuer des activités de maintenance dans les noeuds IMS (IP Multimedia Subsystem) et UPF (Data User Plane Function).

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• 5G-UPF
• Gestionnaire de configuration de redondance (RCM)
• Virtual Packet Core (VPC) - Instance unique (SI)
• Hyperviseur KVM basé sur le noyau

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Infrastructure de microservices des abonnés (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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Qu'est-ce que le protocole UPF ?

L'interface de plan utilisateur (UPF) est l'une des fonctions réseau (NF) du réseau principal 5G (5GC). Il est responsable du routage et du transfert de paquets, de l'inspection de paquets, de la gestion de la QoS et des sessions PDU externes pour interconnecter les réseaux de données (DN), dans l'architecture 5G.

Qu'est-ce que VPC-SI ?

VPC-SI consolide les opérations du châssis physique Cisco ASR 5500 qui exécute StarOS dans une machine virtuelle unique capable de s'exécuter sur des serveurs commerciaux standard (COTS). Chaque machine virtuelle VPC-SI fonctionne en tant qu'instance StarOS indépendante et intègre les fonctionnalités de gestion et de processus de session d'un châssis physique.

Qu'est-ce que l'hyperviseur KVM ?

KVM (Kernel-based Virtual Machine) est une technologie de virtualisation open source intégrée à Linux. Plus précisément, KVM vous permet de transformer Linux en hyperviseur qui permet à une machine hôte d'exécuter plusieurs environnements virtuels isolés appelés invités ou machines virtuelles (VM).

Qu'est-ce que l'ICSR ?

La fonctionnalité de récupération de session interchâssis (ICSR) est une fonctionnalité Cisco sous licence qui nécessite une licence distincte. Cette fonctionnalité offre la disponibilité la plus élevée possible pour un processus d'appel continu sans interruption des services des abonnés. ICSR permet à l'opérateur de configurer des passerelles à des fins de redondance. En cas de défaillance d'une passerelle, l'ICSR permet aux sessions d'être routées de manière transparente autour de la défaillance, assurant ainsi la continuité de l'expérience utilisateur. L'ICSR conserve également les informations et l'état de la session.

Problème

La maintenance du matériel, telle que la défaillance matérielle ou la mise à niveau logicielle/micrologiciel, et bien plus encore, nécessite des temps d'arrêt sur les serveurs. Cette procédure doit être suivie pour que la maintenance soit effectuée sur les serveurs sans système d'exploitation UPF et comment basculer gracieusement sur les services afin d'éviter les temps d'arrêt indésirables dans l'application UPF. 

Procédure de maintenance

Les noeuds UPF sont des machines virtuelles StarOS hébergées dans l'hyperviseur KVM. Un hyperviseur KVM héberge 2 instances de VM. Le protocole UPF IMS dispose d'une redondance 1:1, chaque instance active dispose d'une instance de secours. il utilise le protocole ICSR ainsi que le protocole SRP (Session Redundancy Protocol) pour gérer la redondance. SRP est utilisé pour échanger des messages Hello entre des châssis ICSR. Il échange également des informations d'état de session entre le châssis actif/de secours (données de point de contrôle). Les informations complètes de session d'abonné sont envoyées du châssis ACTIVE au châssis STANDBY sous la forme d'un enregistrement de récupération d'appel (CRR), via la liaison SRP.

Connectez-vous au noeud KVM et répertoriez les instances de VM à l'aide de la commande KVM virsh.

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

Connectez-vous à l'instance UPF et vérifiez l'état du châssis.

[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 

Vérifiez si le nombre de lignes est le même sur la paire active-veille ICSR pour 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

Vérifiez si le sessmgr SRP est à l'état actif-connecté avant la commutation SRP sur l'UPF actif et assurez-vous qu'il n'y a pas d'état en attente-actif.

[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

Vérifier si SRP sessmgr est à l'état actif-connecté avant la commutation SRP sur l'UPF de secours et s'assurer qu'il n'y a pas d'état en attente-actif

[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

Si l'un de ces deux états est actif, vous devez d'abord effectuer ces tâches avant de basculer :

[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

Avant l'arrêt de la machine virtuelle, vous devez vous assurer que les instances actives sont basculées en veille afin que les abonnés soient commutés avec grâce. Si l'instance est déjà en veille, aucune action n'est requise. Si l'instance est active, vérifiez les valeurs mises en surbrillance et assurez-vous que la veille est prête à prendre le relais.

Vérifiez les abonnés actuels dans l'instance UPF active.

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

Total Subscribers : 175024 
Active : 175024 Dormant : 0

Basculer l'instance active en veille.

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

Vérifiez l'état de la veille, qui serait devenue active à l'heure actuelle, et les sessions de l'abonné sont également déplacées vers la nouvelle instance active. Maintenant que les deux instances de VM sont en veille, elles sont correctes pour la maintenance du serveur. Utilisez les commandes virsh données pour arrêter les instances de VM et vérifier l'état.

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

Une fois le serveur rétabli après la maintenance, les machines virtuelles sont démarrées automatiquement. Les instances UPF restent en veille. vérifiez avec la commande donnée.

[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 

L'UPF de données utilise le RCM qui a une redondance N : M où N est un nombre d'UPF actifs et est inférieur à 10, et M un nombre d'UP de secours dans le groupe de redondance. RCM est un noeud propriétaire ou une fonction réseau (NF) de Cisco qui fournit une redondance pour les fonctions de plan utilisateur (UPF) basées sur StarOS. Il stocke ou met en miroir toutes les informations de session requises à partir de l'UPF actif. Sur un déclencheur de commutation, un UPF de secours est sélectionné pour recevoir les données de session appropriées à partir de l'emplacement commun. RCM s'exécute sur un cluster K3 sur une machine virtuelle. Le centre d'opérations configure le noeud RCM. 

Les noeuds UPF de données sont également identiques aux noeuds UPF IMS. La seule différence est la gestion de la redondance RCM. 

Vérifiez l'état de la machine virtuelle dans le noeud 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:~$

Après vous être connecté à l'instance UPF, vérifiez l'état de redondance RCM. Si l'instance est déjà en veille, aucune action n'est requise. S'il est actif, il doit être commuté gracieusement en veille.

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

Vérifiez si tous les sessmgr sont dans un état Actif.

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

 Identifiez le noeud RCM correspondant à partir du questionnaire d'information sur le client (CIQ) et vérifiez l'état du RCM. Notez que la commutation RCM ne peut être effectuée qu'à partir du noeud maître. Vérifiez que vous vous connectez au RCM principal.

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

Recherchez les noeuds UPF actifs et de secours avec la commande donnée (sortie tronquée) :

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

 Connectez-vous à l'instance UPF de secours avec l'adresse IP de gestion et vérifiez l'état

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

Après la vérification, passez gracieusement l'actif en veille. Assurez-vous d'utiliser l'adresse IP de gestion.

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

Note: Dans le cas où après la commutation, si le nouveau sessmgr Active UP est coincé dans l'état SERVER. Faire appel à l'assistance technique de Cisco. En cas de problème, sessmgr doit être tué, de sorte qu'il se reconnecte à RCM avec l'état correct de socket CLIENT et récupère. Tous les sessmgr doivent être dans l'état CLIENT. Vérifiez-le à l'aide de la commande donnée (en mode masqué).

# 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

Vérifiez que tous les sessmgr sont en état actif et prêt.

# 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

Vérifiez que les abonnés sont déplacés vers la nouvelle veille :

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

Total Subscribers : 62259 
Active : 62259 Dormant : 0

Lorsque les deux instances sont en veille, les machines virtuelles peuvent être arrêtées à partir de la machine virtuelle KVM avec des commandes 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:~$

Lorsque les machines virtuelles sont arrêtées, le noeud KVM (serveur physique) peut être arrêté pour maintenance. Une fois terminé, démarrez le serveur. Les machines virtuelles sont activées automatiquement. Les instances UPF deviennent autonomes. Vérifiez la même chose avec les commandes données.

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#

Dans le noeud RCM, le contrôleur rcm peut toujours afficher l'UPF de secours comme « en attente de secours ». Cela peut prendre entre 15 et 20 minutes pour passer en veille. Vérifiez la même chose avec les commandes données (sortie tronquée) :

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