CNDP PCF站點隔離和恢復程式

簡介

本檔案介紹雲原生部署平台(CNDP)原則控制功能(PCF)站點隔離和還原。

必要條件

需求

思科建議您瞭解以下主題：

• Linux
• 策略控制功能
• 庫伯內特斯

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• PCF
• 庫伯內特斯

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

PCF通常與兩個PCF站點一起部署以形成地理冗餘對。對於異地複製(GR)，您必須單獨建立兩個獨立的高可用性(HA)PCF系統，並配置異地複製用於與遠端站點通訊。

PCF有許多外部介面來處理進出該PCF的入口和出口流量，其中包括N7、N28、Rx和輕量型目錄訪問協定(LDAP)，以處理其餘流量、直徑流量和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)，以防止N7消息從SMF流到各自的PCF，從而將N7流量重新路由到Geo Redundant匹配站點。

要將PCF註冊狀態配置為不可發現，請從主站點的PCF運營中心使用此配置：

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

  · config — 進入配置模式。
  ·服務註冊 — 進入服務註冊配置模式。
  ·配置檔案 — 進入配置檔案配置模式。
  · nf-status {已註冊 | 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}

步驟2.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.

步驟2.設定PCF KAFKA偏移。

使用最新的OFFSET設定Kafka Pod以維護CDL會話完整性和同步是必須執行的操作。嘗試將另一個PCF站點置於活動狀態之前，請從活動PCF站點運行這些步驟。

步驟2.1.從活動站點的Master-1，取回卡夫卡包。

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艙。

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.檢查當前滯後值。

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

步驟3.將系統設定為 Running 模式

步驟3.1.開啟連線到隔離站點的四個終端。網站一號主站已關閉。
步驟3.2.在第一台終端機上，確保指令碼 /home/cloud-user/rs_0.sh  在主節點上。

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

步驟3.3.在第二個終端上運行此命令，該命令負責終止rest-ep pods。請確保使用正確的名稱空間。

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，並檢索遠端站點db-endpoint 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.確保所有其它電源盒運行正常，沒有任何問題。

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

步驟3.11.監視CDLs grafana圖形並確保統計資料顯示成功的建立/更新狀態。

步驟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註冊狀態REGISTERED。

一旦活動完成且問題得到解決，需要將PCF註冊狀態更新為REGISTERED at Network Repository Function(NRF)，以允許N7消息從SMF流到各自的PCF。

要將PCF註冊狀態配置為REGISTERED，請從主站點的PCF運營中心使用此配置：

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