CNDP PCF 사이트 분리 및 복원 절차

소개

이 문서에서는 CNDP(Cloud Native Deployment Platform) PCF(Policy Control Function) 사이트 격리 및 복원에 대해 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• Linux
• 정책 제어 기능
• 쿠베르네테스

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• PCF
• 쿠베르네테스

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

PCF는 일반적으로 지리적으로 이중화된 쌍을 형성하기 위해 두 개의 PCF 사이트와 함께 구축됩니다. GR(Geo Replication)의 경우 두 개의 개별 HA(High Availability) PCF 시스템을 독립적으로 생성하고 원격 사이트와의 통신을 위해 Geo HA를 구성해야 합니다.

PCF에는 PCF로 드나드는 인그레스 및 이그레스 트래픽을 처리할 수 있는 많은 외부 인터페이스가 있습니다. 여기에는 N7, N28, Rx 및 LDAP(Lightweight Directory Access Protocol)가 포함되어 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)을 구성합니다.

SMF에서 각 PCF로 흐르는 N7 메시지를 방지하고 N7 트래픽을 Geo Redundant Mated Site로 다시 라우팅하려면 PCF 등록 상태를 NRF(Network Repository Function)에서 UNDISCOVERABLE로 업데이트해야 합니다.

PCF 등록 상태를 검색 불가능으로 구성하려면 기본 사이트의 PCF 운영 센터에서 다음 컨피그레이션을 사용합니다.

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

  · config - 컨피그레이션 모드로 들어갑니다.
  · service-registration - 서비스 등록 컨피그레이션 모드를 시작합니다.
  · profile - 프로필 컨피그레이션 모드로 들어갑니다.
  · nf-status { 등록 | UNDISCOVERABLE } - PCF 등록 상태를 지정합니다. 사이트 격리 기능의 경우 상태를 검색 불가능으로 설정합니다. 이 상태에서는 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단계. 활성 사이트의 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 세션 무결성 및 동기화를 유지하기 위해 최신 OFFSET으로 Kafka Pod를 설정하는 데 필요한 작업입니다. 다른 PCF 사이트를 활성 상태로 만들기 전에 활성 PCF 사이트에서 다음 단계를 실행합니다.

2.1단계. 활성 사이트의 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 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단계. 현재 지연 값을 확인합니다.

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단계. 두 번째 터미널에서 rest-ep Pod를 종료하는 이 명령을 실행합니다. 올바른 네임스페이스를 사용하십시오.

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

3.4단계. 세 번째 터미널에서 Rx 직경 포드를 종료하는 이 스크립트를 실행합니다.

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-엔드포인트 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에 최근 "원격 시스템 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단계. 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 포드를 다시 생성합니다.

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 등록 상태를 NRF(Network Repository Function)에 REGISTERED로 업데이트하여 N7 메시지가 SMF에서 각 PCF로 흐르도록 해야 합니다.

PCF 등록 상태를 REGISTERED로 구성하려면 기본 사이트의 PCF 운영 센터에서 다음 컨피그레이션을 사용합니다.

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