Procedura per l'isolamento e il ripristino del sito PCF CNDP

Introduzione

In questo documento viene descritto l'isolamento e il ripristino del sito PCF (Policy Control Function) della piattaforma di distribuzione nativa del cloud (CNDP).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Linux
• Funzione di controllo delle policy
• Kubernetes

Componenti usati

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

• PCF
• Kubernetes

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

PCF viene normalmente implementato con due siti PCF per formare una coppia ridondante geograficamente. Per Geo Replication (GR), è necessario creare due sistemi PCF ad alta disponibilità (HA) separati in modo indipendente e configurare Geo HA per le comunicazioni con i siti remoti.

PCF dispone di molte interfacce esterne per gestire il traffico in entrata e in uscita da e verso PCF, che include N7, N28, Rx e il protocollo LDAP (Lightweight Directory Access Protocol) per gestire il traffico Rest, il diametro e LDAP.

Problema

Quando si eseguono attività pianificate (ad esempio, aggiornamenti e altro ancora) o si verificano problemi con un sito PCF che causano un impatto sul traffico e richiedono un certo tempo per la risoluzione, è necessario isolare il sito PCF dal traffico per evitare qualsiasi impatto aziendale.

Una volta terminata l'attività o risolto il problema PCF, è necessario ripristinare il sito e introdurre il traffico.

Procedura per isolare e ripristinare il sito PCF

Isolamento sito PCF

Passaggio 1. Impostare il sistema sulla modalità di arresto.

Passaggio 1.1. Dal master-1 del sito isolato, eseguire il login al centro operativo PCF.

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

Passaggio 1.2. Configurare lo stato di registrazione PCF UNDISCOVERABLE.

È necessario aggiornare lo stato di registrazione PCF come UNDISCOVERABLE at Network Repository Function (NRF) per impedire che i messaggi N7 passino da SMF al rispettivo PCF, che a sua volta reindirizza il traffico N7 verso il sito di accoppiamento con ridondanza geografica.

Per configurare lo stato di registrazione PCF su non individuabile, utilizzare questa configurazione dal centro operativo PCF del sito primario:

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

  · config - Attiva la modalità di configurazione.
  · service-registration - Accede alla modalità di configurazione service registration.
  · profile - Attiva la modalità di configurazione del profilo.
  · nf-status { REGISTRATO | UNDISCOVERABLE } - Specifica lo stato di registrazione PCF. Per la funzione di isolamento del sito, impostare lo stato su UNDISCOVERABLE. In questo stato, tutte le operazioni che interessano l'istanza PCF vengono sospese.

Passaggio 1.3. Configurare il sistema shutdown modalità.

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

Attendere che il sistema venga eseguito al 100%.

Passaggio 1.4. Verificare che lo stato di distribuzione del sistema sia false.

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

Passaggio 1.5. Recuperare l'ID sito del sistema che è stato arrestato.

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

Passaggio 2. Configurazione della notifica di scadenza del timer CDL.

Passaggio 2.1. Connettersi al master-1 del sito attivo (sito accoppiato) e al centro operativo PCF.

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

Passaggio 2.2. Configurare la libreria a dischi del sito attivo per l'invio di notifiche di scadenza del timer per il sito isolato.

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

Ripristino sito PCF

Passaggio 1. Disabilita la configurazione della notifica di scadenza del timer CDL.

Passaggio 1.1. Connettersi al master-1 del sito attivo e al centro operativo PCF.

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

Passaggio 2.1. È necessario configurare CDL in modo che non invii notifiche di scadenza del timer al sito isolato.

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

Passaggio 2. Imposta OFFSET KAFKA PCF.

Per mantenere l'integrità e la sincronizzazione della sessione CDL, è necessario impostare i Kafka Pod con l'ultimo OFFSET. Eseguire la procedura seguente dal sito PCF attivo prima di tentare di attivare l'altro sito PCF.

Passaggio 2.1. Dal Master-1 del sito Attivo, recuperare i Kafka pod.

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

Passaggio 2.2. Accedi a Kafka-0 pod.

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

Passaggio 2.3. Eseguire un comando list per trovare i gruppi di consumer nei gruppi 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

Passaggio 2.4. Ottenere la descrizione dei gruppi di consumer in Kafka. Assicurarsi di utilizzare il nome del gruppo di consumer corretto dall'output del passo 2.3.

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

Output previsto:

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

Passaggio 2.5. Controllare i nuovi valori di OFFSET più recenti.

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

Output previsto:

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

Passaggio 2.6. Reimpostate OFFSET sui nuovi valori più recenti.

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

Output previsto:

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

Passaggio 2.7. Controllare i valori di ritardo correnti.

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

Output previsto:

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

Passaggio 3. Impostare il sistema su Running modalità

Passaggio 3.1. Aprire quattro terminali collegati al sito isolato. Il master-1 del sito non è attivo.
Passaggio 3.2. Sul primo terminale. assicurarsi che lo script /home/cloud-user/rs_0.sh  si trova nel nodo master.

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

Passaggio 3.3. Sul secondo terminale eseguire questo comando che è responsabile della chiusura dei pod rest-ep. Assicurarsi di utilizzare lo spazio dei nomi corretto.

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

Passaggio 3.4. Eseguire questo script che è responsabile di terminare i perni di diametro Rx sul terzo terminale.

watch ./rs_0.sh

Passaggio 3.5 Impostare il sistema su running dal centro operativo PCF sul quarto terminale.

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

Attendere che il sistema venga eseguito al 100%.

Passaggio 3.6. Verificare ora che non venga eseguito rest-ep né il diametro Rx.

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

Passaggio 3.7. Connettersi al master-1 di entrambi i siti e recuperare l'indirizzo IP dell'endpoint database del sito remoto (indirizzo IP di replica per il sito associato).

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

Output previsto:

db-endpoint host xx.xx.xx.xx

Passaggio 3.8 Verificare il numero di connessioni tra CDL-EP e IP di replica del sito associato (devono essere presenti 5 connessioni).

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

Output previsto:

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

Passaggio 3.9. Verificare che non vi siano messaggi di errore recenti relativi alla perdita della connessione al systemID remoto nel 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

L'output previsto è nello stato pulito:

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

Output previsto in caso di problemi:

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

Passaggio 3.10. Assicurarsi che tutti gli altri supporti funzionino correttamente senza problemi.

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

Passaggio 3.11. Monitorare il grafico CDL grafana e verificare che le statistiche mostrino uno stato di creazione/aggiornamento corretto.

Passaggio 3.12. Dopo un paio di minuti, assicurarsi che i CDL siano sincronizzati.

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

Output previsto:

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

Passaggio 3.13. Dal sito peer, verificare che il creatore di mirroring sia attivo e running.

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

Passaggio 3.14. Interrompere lo script sugli altri 3 terminali del sito che è appena sollevato.

Passaggio 3.15. Eseguire questo script per ricreare i pod di diametro Rx PCF.

./rs_1.sh

Passaggio 3.16. Eseguire questo comando per ricreare i pod pod rest-ep PCF.

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

Passaggio 3.17. Una volta terminato, verificare che venga eseguito il diametro rest-ep o Rx.

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

Passaggio 3.18. Sul quarto terminale, configurare lo stato di registrazione PCF REGISTRATO.

Una volta completata l'attività e risolto il problema, è necessario aggiornare lo stato di registrazione PCF come REGISTRATO nella funzione NRF (Network Repository Function) per consentire il flusso dei messaggi N7 da SMF al rispettivo PCF.

Per configurare lo stato di registrazione PCF su REGISTRATO, utilizzare questa configurazione dal centro operativo PCF del sito principale:

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