CNDP PCF站点隔离和恢复程序

简介

本文档介绍云本地部署平台(CNDP)策略控制功能(PCF)站点隔离和恢复。

先决条件

要求

Cisco 建议您了解以下主题：

• Linux
• 策略控制功能
• 库伯内特斯

使用的组件

本文档中的信息基于以下软件和硬件版本：

• PCF
• 库伯内特斯

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

PCF通常与两个PCF站点一起部署以形成地理冗余对。对于地域复制(GR)，您必须单独创建两个独立的高可用性(HA)PCF系统，并配置地域复制用于与远程站点通信。

PCF有许多外部接口用于处理进出PCF的入口和出口流量，其中包括N7、N28、Rx和轻量级目录访问协议(LDAP)，用于处理Rest、diameter和LDAP流量。

问题

当您执行任何计划活动（例如，升级等）或遇到一个PCF站点出现导致流量影响的任何问题（需要一些时间才能解决）时，需要将相应的PCF站点与流量隔离，以避免任何业务影响。

完成活动或PCF问题解决后，您必须恢复站点并引入流量。

隔离和恢复PCF站点的过程

PCF站点隔离

步骤1:将系统设置为关闭模式。

步骤 1.1从隔离站点的Master-1登录到PCF运行中心。

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

步骤 1.2将PCF注册状态配置为UNDISCOVERABLE。

需要将PCF注册状态更新为UNDISCOVERABLE at Network Repository Function(NRF)，以阻止从SMF流向相应PCF的N7消息，后者反过来会将N7流量重新路由到Geo Redundant匹配站点。

要将PCF注册状态配置为undiscoverable，请从主站点的PCF运营中心使用此配置：

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

  · config — 进入配置模式。
  · service-registration — 进入服务注册配置模式。
  · profile — 进入配置文件配置模式。
  · nf-status { REGISTERED | UNDISCOVERABLE } — 指定PCF注册状态。对于站点隔离功能，请将状态设置为UNDISCOVERABLE。在此状态下，将暂停涉及PCF实例的所有操作。

步骤 1.3将系统配置为 shutdown 模式。

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

等待系统运行至100%。

步骤 1.4验证系统部署状态是否为false。

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

步骤 1.5检索已关闭的系统的站点ID。

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

第二步：CDL计时器到期通知配置。

步骤 2.1连接到主用站点（匹配站点）的主用站点1并连接到PCF运营中心。

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

步骤 2.2配置活动站点CDL以发送隔离站点的计时器到期通知。

[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站点恢复

步骤1:禁用CDL计时器到期通知配置。

步骤 1.1连接到活动站点的主机1并连接到PCF运营中心。

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

步骤 2.1必须配置CDL，使其不会向隔离站点发送计时器到期通知。

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

第二步：设置PCF KAFKA偏移。

使用最新的OFFSET设置Kafka Pod以维护CDL会话完整性和同步是一项必需操作。在您尝试将另一个PCF站点置于活动状态之前，请从活动PCF站点运行这些步骤。

步骤 2.1从活动站点的Master-1检索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

步骤 2.2登录Kafka-0 pod。

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

步骤 2.3运行list命令以查找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

步骤 2.4获取Kafka格式的消费者组说明。确保使用步骤2.3输出中的正确使用者组名称。

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

预期输出：

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

步骤 2.5检查最新的新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

预期输出：

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

步骤 2.6将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 --execute

预期输出：

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

步骤 2.7检查当前lag值。

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

预期输出：

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

第三步：将系统设置为 Running 模式

步骤 3.1打开连接到隔离站点的四个终端。站点的主机1已关闭。
步骤 3.2在第一个终端上，确保脚本 /home/cloud-user/rs_0.sh  在主节点上。

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

步骤 3.3在第二个终端上，运行负责终止rest-ep pod的命令。请确保使用正确的命名空间。

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

步骤 3.4运行此脚本，该脚本负责终止第三端上的Rx diameter pod。

watch ./rs_0.sh

第3.5步将系统设置为 running 模式从第四个终端上的PCF运营中心。

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

等待系统运行至100%。

步骤 3.6现在请确保未运行rest-ep和Rx直径。

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

步骤 3.7连接到两个站点的Master-1，并检索远程站点数据库终端IP地址（匹配站点的复制IP地址）。

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

预期输出：

db-endpoint host xx.xx.xx.xx

第3.8步检查CDL-EP和配对站点复制IP之间的连接数（必须有5个连接）。

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

预期输出：

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

步骤 3.9验证CDL-EP中最近是否出现任何“Connection to remote systemID has been lost（与远程系统ID的连接已丢失）”错误消息。

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

处于清理状态的预期输出：

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

如果存在问题，则预期输出：

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

步骤 3.10确保所有其他Pod都运行正常且没有任何问题。

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

步骤 3.11监控CDLgrafana图并确保统计数据显示成功的创建/更新统计信息。

步骤 3.12几分钟后，确保CDL同步。

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

预期输出：

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

步骤 3.13从对等站点，验证镜像生成器已启动并且 running.

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

步骤 3.14中断刚启动的站点其他3个终端上的脚本。

步骤 3.15运行此脚本以重新创建PCF Rx直径面板。

./rs_1.sh

步骤 3.16运行此命令以重新创建PCF rest-ep Pod。

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

步骤 3.17完成后，确保运行rest-ep或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

步骤 3.18在第四个终端上，配置PCF Registration Status REGISTERED。

完成练习并解决问题后，需要将PCF注册状态更新为REGISTERED at Network Repository Function(NRF)，以允许N7消息从SMF流到各自的PCF。

要将PCF注册状态配置为REGISTERED，请从主站点的PCF运营中心使用此配置：

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