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
Remarque : Cisco recommande que vous ayez un accès utilisateur racine privilégié à l'interface de ligne de commande CPS.
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
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
Remarque : attendez une minute ou deux et effectuez les étapes suivantes.
· 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.
Remarque : siteID est l'ID récupéré à partir du site d'isolation à l'étape 1.5.
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.
Remarque : vérifiez les détails des réplicas de site pour un certain nombre de réplicas rest-ep et vous devez utiliser l'espace de noms correct.
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