Procédure d'isolation et de restauration de site PCF CNDP

Introduction

Ce document décrit l'isolation et la restauration du site de la fonction de contrôle des politiques (PCF) de la plate-forme de déploiement native du cloud (CNDP).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Linux
• Fonction de contrôle des politiques
• Kubernetes

Composants utilisés

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

• PCF
• Kubernetes

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

PCF est normalement déployé avec deux sites PCF pour former une paire géographiquement redondante. Pour la géo-réplication (GR), vous devez créer deux systèmes PCF haute disponibilité (HA) distincts indépendamment et configurer la géo-disponibilité pour les communications avec les sites distants.

PCF dispose de nombreuses interfaces externes pour gérer le trafic entrant et sortant vers et depuis PCF, qui inclut N7, N28, Rx et LDAP (Lightweight Directory Access Protocol) pour gérer le trafic Rest, le diamètre et LDAP.

Problème

Lorsque vous effectuez des activités planifiées (par exemple, une mise à niveau, etc.) ou que vous rencontrez des problèmes avec un site PCF qui entraînent un impact sur le trafic, ce qui nécessite un certain temps de résolution, il est nécessaire d'isoler le site PCF concerné du trafic afin d'éviter tout impact sur l'entreprise.

Une fois l'exercice terminé ou le problème PCF résolu, vous devez restaurer le site et introduire le trafic.

Procédure d'isolation et de restauration du site PCF

Isolation de site PCF

Étape 1. Définissez le système en mode d'arrêt.

Étape 1.1. À partir de Master-1 du site isolé, connectez-vous au centre opérationnel PCF.

ssh -p 2024 admin@`kubectl get svc -A | grep " ops-center-pcf" | awk '{print $4}'`

Étape 1.2. Configurez l'état d'enregistrement PCF UNDISCOVERABLE.

Il est nécessaire de mettre à jour l'état d'enregistrement PCF UNDISCOVERABLE au niveau de la fonction NRF (Network Repository Function) afin d'empêcher les messages N7 qui circulent de SMF vers le PCF correspondant, qui à son tour réachemine le trafic N7 vers le site associé Geo Redundant.

Afin de configurer l'état de l'enregistrement PCF sur undiscoverable, utilisez cette configuration à partir du centre d'opérations PCF du site principal :

config
  service-registration 
    profile
      nf-status UNDISCOVERABLE
    top
  commit 
end

  · config - Passe en mode de configuration.
  · service-registration - Passe en mode de configuration d'enregistrement de service.
  · profile - Passe en mode de configuration de profil.
  · nf-status { ENREGISTRÉ | UNDISCOVERABLE } - Spécifie l'état d'enregistrement PCF. Pour la fonction d'isolation de site, définissez l'état sur UNDISCOVERABLE. Dans cet état, toutes les opérations impliquant l'instance PCF sont suspendues.

Étape 1.3. Configurez le système pour shutdown mode.

[pcf01/pcfapp] pcf# config terminal 
Entering configuration mode terminal
[pcf01/pcfapp] pcf(config)# system mode shutdown 
[pcf01/pcfapp] pcf(config)# commit
Commit complete.

Attendez que le système fonctionne à 100 %.

Étape 1.4. Vérifiez que l'état du système déployé est false.

[pcf01/pcfapp] pcf# show system status 
system status deployed false
system status percent-ready 100.0

Étape 1.5. Récupérez l'ID de site du système qui est arrêté.

[pcf01/pcfapp] pcf# show running-config cdl system-id
cdl system-id {siteID}

Étape 2. Configuration de notification d'expiration du minuteur CDL.

Étape 2.1. Connectez-vous au maître-1 du site actif (site associé) et au centre opérationnel PCF.

ssh -p 2024 admin@`kubectl get svc -A | grep " ops-center-pcf" | awk '{print $4}'`

Étape 2.2. Configurez la CDL du site actif pour envoyer des notifications d'expiration du minuteur pour le site isolé.

[pcf01/pcfapp] pcf# config terminal 
Entering configuration mode terminal
[pcf01/pcfapp] pcf(config)# cdl datastore session 
[pcf01/pcfapp] pcf(config-datastore-session)# slot notification remote-system-id [ siteID ]
[pcf01/pcfapp] pcf(config-datastore-session)# commit
Commit complete.

Restauration de site PCF

Étape 1. Désactivez la configuration de notification d'expiration du minuteur CDL.

Étape 1.1. Connectez-vous au maître-1 du site actif et au centre opérationnel PCF.

ssh -p 2024 admin@`kubectl get svc -A | grep " ops-center-pcf" | awk '{print $4}'`

Étape 2.1. La CDL doit être configurée de manière à ne pas envoyer de notifications d'expiration de minuteur au site isolé.

[pcf01/pcfapp] pcf# config terminal 
Entering configuration mode terminal
[pcf01/pcfapp] pcf(config)# no cdl datastore session slot notification remote-system-id
[pcf01/pcfapp] pcf(config-datastore-session)# commit
Commit complete.

Étape 2. Définissez PCF KAFKA OFFSET.

Il est nécessaire de configurer les modules Kafka avec la dernière OFFSET pour maintenir l'intégrité et la synchronisation de la session CDL. Exécutez ces étapes à partir du site PCF actif avant d'essayer de mettre l'autre site PCF à l'état actif.

Étape 2.1. À partir de Master-1 du site actif, récupérez les pods Kafka.

cloud-user@pcf01-master1:~$ kubectl get pods -A | grep -i kafka
pcf-pcfapp kafka-0 2/2 Running 0 22m
pcf-pcfapp kafka-1 2/2 Running 0 20m
pcf-pcfapp kafka-2 2/2 Running 0 20m

Étape 2.2. Connectez-vous à Kafka-0 pod.

kubectl exec -it -n pcf-pcfapp kafka-0 bash

Étape 2.3. Exécutez une commande list pour rechercher les groupes de consommateurs dans les groupes Kafka.

kafka@kafka-0:/opt/kafka$ cd bin
kafka@kafka-0:/opt/kafka/bin$ ./kafka-consumer-groups.sh --list --bootstrap-server localhost:9092
test-group
c1-c2-consumer-group

Étape 2.4. Obtenez la description des groupes de consommateurs à Kafka. Assurez-vous d'utiliser le nom de groupe de consommateurs correct à partir du résultat de l'étape 2.3.

kafka@kafka-0:/opt/kafka/bin$ ./kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group c1-c2-consumer-group

Résultats attendus :

GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID
c1-c2-consumer-group kv.kafka.shard.1.1.1 0 1774202721 1774213158 10437 c1-c2-consumer-group-0-65c85cd5-f43d-4767-971a-f8b53164538a /xx.xx.xx.xx c1-c2-consumer-group-0
c1-c2-consumer-group kv.kafka.shard.1.1.9 0 1638393629 1638393987 358 c1-c2-consumer-group-3-2822cebd-5c98-4dbd-8d49-31d4b80bd415 /xx.xx.xx.xx c1-c2-consumer-group-3
c1-c2-consumer-group kv.kafka.shard.1.1.6 0 1718659693 1718660429 736

Étape 2.5. Vérifiez les dernières nouvelles valeurs OFFSET.

kafka@kafka-0:/opt/kafka/bin$ ./kafka-consumer-groups.sh --bootstrap-server localhost:9092 --reset-offsets --group c1-c2-consumer-group --all-topics --to-latest --dry-run

Résultats attendus :

GROUP TOPIC PARTITION New-OFFSET 
c1-c2-consumer-group kv.kafka.shard.1.1.1 0 1774213158 
c1-c2-consumer-group kv.kafka.shard.1.1.9 0 1638393987 
c1-c2-consumer-group kv.kafka.shard.1.1.6 0 1718660429 
c1-c2-consumer-group kv.kafka.shard.1.1.2 0 1913886111

Étape 2.6. Réinitialisez le décalage avec les dernières nouvelles valeurs.

kafka@kafka-0:/opt/kafka/bin$ ./kafka-consumer-groups.sh --bootstrap-server localhost:9092 --reset-offsets --group c1-c2-consumer-group --all-topics --to-latest --execute

Résultats attendus :

GROUP TOPIC PARTITION New-OFFSET 
c1-c2-consumer-group kv.kafka.shard.1.1.1 0 1774213158 
c1-c2-consumer-group kv.kafka.shard.1.1.9 0 1638393987 
c1-c2-consumer-group kv.kafka.shard.1.1.6 0 1718660429

Étape 2.7. Vérifiez les valeurs de décalage actuelles.

kafka@kafka-0:/opt/kafka/bin$ ./kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group c1-c2-consumer-group

Résultats attendus :

GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID
c1-c2-consumer-group kv.kafka.shard.1.1.1 0 1774202721 1774213158 10437 c1-c2-consumer-group-0-65c85cd5-f43d-4767-971a-f8b53164538a /xx.xx.xx.xx c1-c2-consumer-group-0
c1-c2-consumer-group kv.kafka.shard.1.1.9 0 1638393629 1638393987 358 c1-c2-consumer-group-3-2822cebd-5c98-4dbd-8d49-31d4b80bd415 /xx.xx.xx.xx c1-c2-consumer-group-3

Étape 3. Définissez le système sur Running mode

Étape 3.1. Ouvrir quatre terminaux connectés au site isolé. Master-1 du site est en panne.
Étape 3.2. Sur le premier terminal. vérifiez le script /home/cloud-user/rs_0.sh  se trouve sur le noeud maître.

ls -lrt /home/cloud-user/rs_0.sh

Étape 3.3. Sur le deuxième terminal, exécutez cette commande qui est responsable de terminer rest-ep pods. Assurez-vous d'utiliser l'espace de noms correct.

watch kubectl scale --replicas=0 deployment/pcf-rest-ep -n pcf-pcf

Étape 3.4. Exécutez ce script qui est chargé de terminer les pods de diamètre Rx sur le troisième terminal.

watch ./rs_0.sh

Étape 3.5 Définissez le système sur running mode à partir du centre d'opérations PCF sur le quatrième terminal.

[pcf01/pcf01] pcf# 
[pcf01/pcf01] pcf# config 
Entering configuration mode terminal
[pcf01/pcf01] pcf(config)# system mode running
[pcf01/pcf01] pcf(config)# commit
Commit complete.

Attendez que le système fonctionne à 100 %.

Étape 3.6. Assurez-vous maintenant que ni le diamètre rest-ep ni le diamètre Rx ne sont exécutés.

cloud-user@pcf01-master-1:~$ kubectl get pods -A | egrep "diameter|rest-ep"

Étape 3.7. Connectez-vous au Master-1 des deux sites et récupérez l'adresse IP du point d'extrémité de la base de données du site distant (adresse IP de réplication pour le site associé).

ssh -p 2024 admin@`kubectl get svc -A | grep " ops-center-pcf" | awk '{print $4}'` 'show running-config | inc "db-endpoint host"'

Résultats attendus :

db-endpoint host xx.xx.xx.xx

Étape 3.8 Vérifiez le nombre de connexions entre le CDL-EP et l’adresse IP de réplication du site associé (il doit y avoir 5 connexions).

for CDLEP in `kubectl get pods -A | grep cdl-ep | awk '{print $2}'`;do echo $CDLEP; kubectl exec -it $CDLEP -n `kubectl get namespaces | grep "pcf-" | awk '{print $1}'` -- netstat -anp | grep 10.169.149.34| wc -l ; done

Résultats attendus :

cdl-ep-session-c1-d0-56995765b5-l2kz6
5
cdl-ep-session-c1-d0-56995765b5-mlxdx
5

Étape 3.9. Vérifiez qu'aucun message d'erreur récent « Connection to remote systemID has been lost » (Connexion à l'ID système distant perdue) n'apparaît sur le CDL-EP.

for CDLEP in `kubectl get pods -A | grep cdl-ep | awk '{print $2}'`;do echo $CDLEP; kubectl logs $CDLEP -n `kubectl get namespaces | grep "pcf-" | awk '{print $1}'` --since=15m| grep "has been lost" ; done

Le résultat attendu à l'état propre :

cdl-ep-session-c1-d0-56995765b5-l2kz6
cdl-ep-session-c1-d0-56995765b5-mlxdx
cdl-ep-session-c1-d0-56995765b5-nptr9
cdl-ep-session-c1-d0-56995765b5-rm7hh

Résultat attendu en cas de problème :

2022/06/24 22:21:08.242 [ERROR] [RemoteEndointConnection.go:619] [datastore.ep.session] Connection to remote systemID 2 has been lost

Étape 3.10. Assurez-vous que tous les autres pods fonctionnent correctement sans aucun problème.

cloud-user@pcf01-master-1:~$ kubectl get pods -A

Étape 3.11. Surveillez le graphique de grafana des CDL et assurez-vous que les statistiques indiquent les statistiques de création/mise à jour réussies.

Étape 3.12. Après quelques minutes, assurez-vous que les CDL sont synchronisées.

cloud-user@pcf01-master-1:~$ for i in `kubectl get pods -A | awk '{print $2}' | grep cdl-ep` ; do echo $i ; kubectl exec -it $i -n `kubectl get namespaces | grep pcf- | awk '{print $1}'` -- ./verify_geo_sync ; done

Résultats attendus :

2022/03/05 02:31:56 Geo sync is successful

Étape 3.13. À partir du site homologue, vérifiez que le fabricant de miroirs est activé et running.

pcf-pcf01 mirror-maker-0 1/1 Running 1 24d

Étape 3.14. Interrompre le script sur les 3 autres terminaux du site qui vient d'être mis en place.

Étape 3.15. Exécutez ce script pour recréer des pods de diamètre PCF Rx.

./rs_1.sh

Étape 3.16. Exécutez cette commande pour recréer les modules PCF rest-ep.

kubectl scale --replicas=8 deployment/pcf-rest-ep -n pcf-pcf

Étape 3.17. Une fois terminé, assurez-vous que le diamètre rest-ep ou Rx est exécuté.

cloud-user@pcf01-master-1:~$ kubectl get pods -A | egrep "diameter|rest-ep|ldap"
pcf-pcf01 diameter-ep-rx-rx-584cd76c75-kwmhh1/1 Running 0 2m
pcf-pcf01 diameter-ep-rx2-rx-64cd75b7f6-drjrz 1/1 Running 0 2m
pcf-pcf01 diameter-ep-rx3-rx-544d4f9bf7-gfb9c 1/1 Running 0 2m
pcf-pcf01 ldap-pcf-pcf01-cps-ldap-ep-5884c6d76d-5tchw 1/1 Running 0 2m
pcf-pcf01 ldap-pcf-pcf01-cps-ldap-ep-5884c6d76d-6wtnm 1/1 Running 0 2m
pcf-pcf01 pcf-rest-ep-86b546f9db-5wzp6 1/1 Running 0 2m
pcf-pcf01 pcf-rest-ep-86b546f9db-6prmd 1/1 Running 0 2m
pcf-pcf01 pcf-rest-ep-86b546f9db-6pstm 1/1 Running 0 2m
pcf-pcf01 pcf-rest-ep-86b546f9db-dsz6c 1/1 Running 0 2m
pcf-pcf01 pcf-rest-ep-86b546f9db-dzlkw 1/1 Running 0 2m

Étape 3.18. Sur le quatrième terminal, configurez l'état d'enregistrement PCF REGISTERED.

Une fois l'activité terminée et le problème résolu, il est nécessaire de mettre à jour l'état d'enregistrement PCF en tant que REGISTERED au niveau de la fonction NRF (Network Repository Function) pour permettre aux messages N7 de circuler de SMF vers le PCF correspondant.

Afin de configurer l'état d'enregistrement PCF sur REGISTERED, utilisez cette configuration à partir du centre d'opérations PCF du site principal :

config
  service-registration 
    profile
      nf-status REGISTERED
    top
  commit
end