CNDP PCFサイトの分離と復元の手順

概要

このドキュメントでは、Cloud Native Deployment Platform(CNDP)Policy Control Function(PCF)サイトの分離と復元について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Linux
• ポリシー制御機能
• クベルネテス

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• PCF
• クベルネテス

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

PCFは通常、地理的に冗長なペアを形成するために2つのPCFサイトとともに導入されます。Geoレプリケーション(GR)では、2つの独立した高可用性(HA)PCFシステムを個別に作成し、リモートサイトとの通信のためにGeo HAを設定する必要があります。

PCFには、PCFとの間でやり取りされる入力および出力トラフィックを処理するための多くの外部インターフェイスがあります。これには、N7、N28、Rx、およびRest、diameter、およびLDAPトラフィックを処理するためのLightweight Directory Access Protocol(LDAP)が含まれます。

問題

計画されたアクティビティ（アップグレードなど）を実行する場合、または1つの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に設定します。

SMFから各PCFにN7メッセージが流れ、N7トラフィックがGeo Redundant対応サイトに再ルーティングされることを防ぐために、Network Repository Function(NRF)でPCF登録ステータスをUNDISCOVERABLEに更新する必要があります。

PCF登録ステータスを検出不能に設定するには、プライマリサイトの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}

ステップ 2：CDLタイマー期限切れ通知の設定

ステップ 2.1：アクティブサイト（合致サイト）のmaster-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：Activeサイトのmaster-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を設定します。

CDLセッションの整合性と同期を維持するために、Kafkaポッドを最新のOFFSETに設定することが必要なアクションです。他のPCFサイトをアクティブ状態にする前に、アクティブPCFサイトから次の手順を実行します。

ステップ 2.1：ActiveサイトのMaster-1から、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

ステップ 2.2：Kafka-0ポッドにログインします。

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

ステップ 2.3：リストコマンドを実行して、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：隔離されたサイトに接続された4つのターミナルを開きます。サイトのMaster-1がダウンしています。
ステップ 3.2：最初の端末で実行します。スクリプトが /home/cloud-user/rs_0.sh  マスターノード上にあります。

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

ステップ 3.3：2番目の端末で、このコマンドを実行します。このコマンドは、rest-epポッドを終了します。正しい名前空間を使用してください。

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

ステップ 3.4：このスクリプトを実行して、3番目の端末でRx直径ポッドを終端させます。

watch ./rs_0.sh

ステップ3.5システムをに設定する running 4番目のターミナルの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 diameterのどちらも実行されていないことを確認します。

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

ステップ 3.7：両方のサイトのMaster-1に接続し、リモートサイトのDBエンドポイントの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」エラーメッセージがないことを確認します。

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：4番目の端末で、PCF登録ステータスをREGISTEREDに設定します。

アクティビティが完了し、問題が解決したら、PCF登録ステータスをREGISTERED at Network Repository Function(NRF)として更新して、N7メッセージがSMFからそれぞれのPCFにフローできるようにする必要があります。

PCF登録ステータスをREGISTEREDに設定するには、プライマリサイトのPCF Ops Centerから次の設定を使用します。

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