Verfahren zur Isolierung und Wiederherstellung des CNDP-PCF-Standorts

Einleitung

In diesem Dokument wird die Isolierung und Wiederherstellung des Standorts der Cloud Native Deployment Platform (CNDP) Policy Control Function (PCF) beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Linux 
• Richtlinienkontrollfunktion
• Kubernetes

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• PCF
• Kubernetes

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Hintergrundinformationen

PCF wird normalerweise an zwei PCF-Standorten bereitgestellt, um ein geografisch redundantes Paar zu bilden. Für die Geo-Replikation (GR) müssen Sie zwei separate HA-PCF-Systeme (High Availability) unabhängig erstellen und Geo HA für die Kommunikation mit den Remote-Standorten konfigurieren.

PCF verfügt über zahlreiche externe Schnittstellen für den Eingangs- und Ausgangsverkehr zu und von PCF, darunter N7, N28, Rx und Lightweight Directory Access Protocol (LDAP) für Rest-, Durchmesser- und LDAP-Verkehr.

Problem

Wenn Sie geplante Aktivitäten (z. B. Upgrades und mehr) durchführen oder Probleme mit einem PCF-Standort feststellen, die Auswirkungen auf den Datenverkehr haben, was eine gewisse Zeit für die Behebung erfordert, muss der entsprechende PCF-Standort vom Datenverkehr isoliert werden, um geschäftliche Auswirkungen zu vermeiden.

Sobald die Aktivität abgeschlossen ist oder das PCF-Problem behoben wurde, müssen Sie den Standort wiederherstellen und den Datenverkehr einleiten.

Verfahren zur Isolierung und Wiederherstellung der PCF-Site

PCF-Standortisolierung

Schritt 1: Stellen Sie das System auf den Herunterfahrmodus ein.

Schritt 1.1: Melden Sie sich vom Master-1 des isolierten Standorts beim PCF-Betriebszentrum an.

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

Schritt 1.2: Konfigurieren Sie den PCF-Registrierungsstatus UNDISCOVERABLE.

Es ist erforderlich, den PCF-Registrierungsstatus als UNDISCOVERABLE bei der Network Repository Function (NRF) zu aktualisieren, um N7-Nachrichten zu verhindern, die von SMF zu den entsprechenden PCF fließen, wodurch wiederum der N7-Datenverkehr an einen geo-redundanten verbundenen Standort umgeleitet wird.

Um den PCF-Registrierungsstatus als nicht erkennbar zu konfigurieren, verwenden Sie die folgende Konfiguration im PCF-Betriebszentrum des primären Standorts:

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

  ・ config - Wechselt in den Konfigurationsmodus.
  ・ Service-Registrierung - Wechselt in den Konfigurationsmodus für die Service-Registrierung.
  ・ profile - Wechselt in den Profilkonfigurationsmodus.
  ・ nf-status { REGISTERED | UNDISCOVERABLE } - Gibt den PCF-Registrierungsstatus an. Setzen Sie für die Standortisolierungsfunktion den Status auf UNDISCOVERABLE. In diesem Zustand werden alle Vorgänge, die die PCF-Instanz betreffen, ausgesetzt.

Schritt 1.3: Konfigurieren Sie das System für shutdown Modus.

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

Warten Sie, bis das System zu 100 % ausgeführt wird.

Schritt 1.4: Überprüfen Sie, ob der Status des bereitgestellten Systems "false" lautet.

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

Schritt 1.5: Rufen Sie die Standort-ID des heruntergefahrenen Systems ab.

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

Schritt 2: Konfiguration der Ablaufbenachrichtigung für den CDL-Timer.

Schritt 2.1: Stellen Sie eine Verbindung mit Master-1 des aktiven Standorts (verbundener Standort) und mit dem PCF-Betriebszentrum her.

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

Schritt 2.2: Konfigurieren Sie die CDL des aktiven Standorts so, dass Zeitgeberablaufbenachrichtigungen für den isolierten Standort gesendet werden.

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

PCF-Standortwiederherstellung

Schritt 1: Konfiguration der Ablaufbenachrichtigung für den CDL-Timer deaktivieren

Schritt 1.1: Stellen Sie eine Verbindung mit Master-1 des aktiven Standorts und dem PCF-Betriebszentrum her.

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

Schritt 2.1: CDL muss so konfiguriert werden, dass keine Ablaufbenachrichtigungen für den Timer an den isolierten Standort gesendet werden.

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

Schritt 2: PCF KAFKA OFFSET einstellen.

Es ist erforderlich, die Kafka-Pods mit dem neuesten OFFSET zu konfigurieren, um die Integrität und Synchronisierung der CDL-Sitzung zu gewährleisten. Führen Sie diese Schritte vom aktiven PCF-Standort aus, bevor Sie versuchen, den anderen PCF-Standort in den aktiven Zustand zu versetzen.

Schritt 2.1: Holen Sie die Kafka-Hülsen von Master-1 der aktiven Seite ab.

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

Schritt 2.2: Melden Sie sich bei Kafka-0 an.

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

Schritt 2.3: Führen Sie einen Listenbefehl aus, um die Verbrauchergruppen in den Kafka-Gruppen zu finden.

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

Schritt 2.4: Hier erhalten Sie eine Beschreibung der Verbrauchergruppen in Kafka. Stellen Sie sicher, dass Sie den richtigen Consumergruppennamen aus der Ausgabe von Schritt 2.3 verwenden.

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

Erwartete Ausgabe:

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

Schritt 2.5: Überprüfen Sie die neuesten neuen OFFSET-Werte.

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

Erwartete Ausgabe:

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

Schritt 2.6: Setzen Sie den OFFSET auf die neuesten neuen Werte zurück.

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

Erwartete Ausgabe:

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

Schritt 2.7: Überprüfen Sie die aktuellen Nacheilungswerte.

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

Erwartete Ausgabe:

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

Schritt 3: Stellen Sie das System auf Running Modus

Schritt 3.1: Öffnen Sie vier Terminals, die mit dem isolierten Standort verbunden sind. Master-1 des Standorts ist ausgefallen.
Schritt 3.2: Stellen Sie auf dem ersten Terminal sicher, dass das Skript /home/cloud-user/rs_0.sh  befindet sich auf dem Master-Knoten.

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

Schritt 3.3: Führen Sie auf dem zweiten Terminal diesen Befehl aus, der zum Beenden von Rest-EP-PODs dient. Stellen Sie sicher, dass Sie den richtigen Namespace verwenden.

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

Schritt 3.4: Führen Sie dieses Skript aus, das dafür verantwortlich ist, Rx-Durchmesser-PoDs auf dem dritten Terminal zu beenden.

watch ./rs_0.sh

Schritt 3.5 Stellen Sie das System auf running Modus von der PCF-Betriebsmitte auf dem vierten 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.

Warten Sie, bis das System zu 100 % ausgeführt wird.

Schritt 3.6: Stellen Sie nun sicher, dass weder der Rx-Durchmesser noch der Pausendurchmesser ausgeführt wird.

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

Schritt 3.7: Stellen Sie eine Verbindung mit Master-1 beider Standorte her, und rufen Sie die db-Endpunkt-IP-Adresse des Remote-Standorts ab (IP-Adresse der Replikation für den verbundenen Standort).

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

Erwartete Ausgabe:

db-endpoint host xx.xx.xx.xx

Schritt 3.8 Überprüfen Sie die Anzahl der Verbindungen zwischen CDL-EP und der Replikations-IP des verbundenen Standorts (es müssen 5 Verbindungen vorhanden sein).

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

Erwartete Ausgabe:

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

Schritt 3.9: Vergewissern Sie sich, dass im CDL-EP keine aktuellen Fehlermeldungen wie "Die Verbindung mit der Remote-System-ID wurde unterbrochen" angezeigt werden.

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

Erwartete Ausgabe im ungestörten Zustand:

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

Erwartete Ausgabe bei einem Problem:

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

Schritt 3.10: Stellen Sie sicher, dass alle anderen PODs problemlos funktionieren.

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

Schritt 3.11: Überwachen Sie den Graph der CDLs und stellen Sie sicher, dass die Statistiken erfolgreiche Create-/Update-Statistiken anzeigen.

Schritt 3.12: Stellen Sie nach einigen Minuten sicher, dass die CDLs synchronisiert werden.

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

Erwartete Ausgabe:

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

Schritt 3.13: Überprüfen Sie vom Peer-Standort, ob der Spiegelhersteller aktiv ist, und running.

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

Schritt 3.14: Unterbrechen Sie das Skript an den anderen 3 Terminals der gerade aufgerufenen Seite.

Schritt 3.15: Führen Sie dieses Skript aus, um PCF Rx-Durchmesser-PODs neu zu erstellen.

./rs_1.sh

Schritt 3.16: Führen Sie diesen Befehl aus, um die PCF-Rest-EP-PODs neu zu erstellen.

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

Schritt 3.17: Nach der Fertigstellung ist darauf zu achten, dass der Durchmesser des Ruhezustands oder des Rx durchlaufen wird.

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

Schritt 3.18: Konfigurieren Sie auf dem vierten Terminal den PCF-Registrierungsstatus REGISTERED (REGISTRIERT).

Sobald die Aktivität abgeschlossen und das Problem behoben ist, muss der PCF-Registrierungsstatus als REGISTERED at Network Repository Function (NRF) aktualisiert werden, damit N7-Nachrichten von SMF zu den entsprechenden PCF fließen können.

Um den PCF-Registrierungsstatus auf REGISTERED (REGISTRIERT) zu konfigurieren, verwenden Sie die folgende Konfiguration im PCF-Betriebszentrum des primären Standorts:

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