Procedimento para Isolamento e Restauração do Local de PCF do CNDP

Introduction

Este documento descreve o isolamento e a restauração do local da Policy Control Function (PCF) da Plataforma de Implantação Nativa em Nuvem (CNDP).

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Linux
• Função de Controle de Política
• Kubernetes

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• PCF
• Kubernetes

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

O PCF é normalmente implantado com dois locais de PCF para formar um par geograficamente redundante. Para a Replicação Geográfica (GR), você precisa criar dois sistemas PCF de Alta Disponibilidade (HA) separados de forma independente e configurar o Geo HA para comunicações com os locais remotos.

O PCF tem muitas interfaces externas para lidar com o tráfego de entrada e saída de e para o PCF, o que inclui N7, N28, Rx e Lightweight Diretory Access Protocol (LDAP) para lidar com o tráfego Rest, de diâmetro e LDAP.

Problema

Quando você executa atividades planejadas (por exemplo, atualização e outras) ou encontra problemas com um site do PCF que causam impacto no tráfego, o que requer algum tempo para resolução, é necessário isolar o respectivo site do PCF do tráfego para evitar qualquer impacto nos negócios.

Quando a atividade for concluída ou o problema do PCF for resolvido, você deverá restaurar o site e introduzir o tráfego.

Procedimento para isolar e restaurar o local do PCF

Isolamento de Site PCF

Etapa 1. Defina o sistema para o modo shutdown.

Etapa 1.1. Do Master-1 do site isolado, faça login no centro de operações do PCF.

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

Etapa 1.2. Configure o status de registro do PCF UNDISCOVERABLE.

É necessário atualizar o status de registro do PCF como NÃO DETECTÁVEL na Network Repository Function (NRF) para evitar mensagens N7 que fluem do SMF para o respectivo PCF, que, por sua vez, redireciona o tráfego N7 para o site acoplado com Redundância Geográfica.

Para configurar o status de registro do PCF como não detectável, use esta configuração do Centro de Operações do PCF do site primário:

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

  · config - Entra no modo de configuração.
  · service-registration - Entra no modo de configuração de registro de serviço.
  · profile - Entra no modo de configuração de perfil.
  · nf-status { REGISTERED | UNDISCOVERABLE } - Especifica o status de registro do PCF. Para o recurso de isolamento de site, defina o status como NÃO DESCOBERTO. Nesse estado, todas as operações que envolvem a instância do PCF são suspensas.

Etapa 1.3. Configure o sistema para shutdown modo.

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

Aguarde até que o sistema seja executado a 100%.

Etapa 1.4. Verifique se o status implantado do sistema é falso.

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

Etapa 1.5. Recupere o site-id do sistema que está desligado.

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

Etapa 2. Configuração de notificação de expiração do temporizador CDL.

Etapa 2.1. Conecte-se ao master-1 do site Ativo (site acasalado) e conecte-se ao centro de operações do PCF.

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

Etapa 2.2. Configure o CDL do site Ativo para enviar notificações de expiração do temporizador para o site Isolado.

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

Restauração do local do PCF

Etapa 1. Desabilite a configuração de notificação de expiração do temporizador CDL.

Etapa 1.1. Conecte-se ao master-1 do site Ativo e conecte-se ao centro de operações do PCF.

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

Etapa 2.1. O CDL deve ser configurado para que não envie notificações de expiração do temporizador para o site isolado.

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

Etapa 2. Defina PCF KAFKA OFFSET.

É uma ação necessária para definir os Kafka Pods com o OFFSET mais recente para manter a integridade e a sincronização da sessão CDL. Execute estas etapas a partir do site do PCF ativo antes de tentar colocar o outro site do PCF no estado ativo.

Etapa 2.1. Do Master-1 do site ativo, recupere os pods 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

Etapa 2.2. Faça login no pod Kafka-0.

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

Etapa 2.3. Execute um comando list para encontrar os grupos de consumidores nos Grupos 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

Etapa 2.4. Veja a descrição dos grupos de consumidores em Kafka. Certifique-se de usar o nome correto do grupo de consumidores na saída da Etapa 2.3.

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

Saída esperada:

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

Etapa 2.5. Verifique os novos valores mais recentes de 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

Saída esperada:

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

Etapa 2.6. Redefina o DESLOCAMENTO para os novos valores mais recentes.

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

Saída esperada:

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

Etapa 2.7. Verifique os valores de latência atuais.

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

Saída esperada:

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

Etapa 3. Defina o sistema como Running modo

Etapa 3.1. Abra quatro terminais conectados ao local isolado. O Master-1 do site está inoperante.
Etapa 3.2. No primeiro terminal. verifique o script /home/cloud-user/rs_0.sh  está no nó mestre.

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

Etapa 3.3. No segundo terminal, execute este comando, que é responsável por terminar os pods rest-ep. Certifique-se de usar o namespace correto.

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

Etapa 3.4. Execute este script, que é responsável por terminar pods de diâmetro Rx no terceiro terminal.

watch ./rs_0.sh

Etapa 3.5 Configurar o sistema para running do centro de operações do PCF no quarto 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.

Aguarde até que o sistema seja executado a 100%.

Etapa 3.6. Agora, certifique-se de que nem o diâmetro de repouso nem o diâmetro Rx estejam funcionando.

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

Etapa 3.7. Conecte-se ao Master-1 dos dois locais e recupere o endereço IP do ponto de extremidade do banco de dados do local remoto (endereço IP de replicação do local acoplado).

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

Saída esperada:

db-endpoint host xx.xx.xx.xx

Etapa 3.8 Verificar o número de conexões entre o CDL-EP e o IP de replicação do site acoplado (deve haver 5 conexões).

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

Saída esperada:

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

Etapa 3.9. Verifique se não há nenhuma mensagem de erro recente "Connection to remote systemID has been lost" no CDL-EP.

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

A saída esperada no estado limpo:

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

Saída esperada se houver um problema:

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

Etapa 3.10. Certifique-se de que todos os outros pods estejam funcionando bem sem problemas.

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

Etapa 3.11. Monitore o gráfico de grafana dos CDLs e verifique se as estatísticas mostram estatísticas de criação/atualização bem-sucedidas.

Etapa 3.12. Depois de alguns minutos, certifique-se de que os CDLs estejam sincronizados.

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

Saída esperada:

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

Etapa 3.13. A partir do site do peer, verifique se o fabricante do espelho está ativado e running.

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

Etapa 3.14. Interrompa o script nos outros 3 terminais do site que acabou de ser criado.

Etapa 3.15. Execute este script para recriar pods de diâmetro Rx do PCF.

./rs_1.sh

Etapa 3.16. Execute este comando para recriar os pods rest-ep PCF.

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

Etapa 3.17. Depois de concluído, certifique-se de que o diâmetro do ep ou Rx de repouso esteja em execução.

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

Etapa 3.18. No quarto terminal, configure o Status de Registro do PCF REGISTERED.

Quando a atividade for concluída e o problema for resolvido, será necessário atualizar o status de registro do PCF como REGISTERED at Network Repository Function (NRF) para permitir que as mensagens N7 fluam do SMF para o respectivo PCF.

Para configurar o status de registro do PCF como REGISTERED, use esta configuração do Centro de Operações do PCF do site primário:

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