Procedimiento para el Aislamiento y Restauración del Sitio de PCF CNDP

Introducción

En este documento se describe el aislamiento y la restauración del sitio de la función de control de políticas (PCF) de la plataforma de implementación nativa en la nube (CNDP).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Linux
• Función de control de políticas
• Kubernetes

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• PCF
• Kubernetes

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

PCF se implementa normalmente con dos sitios PCF para formar un Par Geográficamente Redundante. Para la replicación geográfica (GR), debe crear dos sistemas PCF de alta disponibilidad (HA) independientes y configurar el Geo HA para las comunicaciones con los sitios remotos.

PCF tiene muchas interfaces externas para manejar el tráfico de ingreso y egreso hacia y desde PCF, que incluye N7, N28, Rx y el protocolo ligero de acceso a directorios (LDAP) para manejar el tráfico Rest, de diámetro y LDAP.

Problema

Cuando realice cualquier actividad planificada (por ejemplo, una actualización o más) o encuentre cualquier problema con un sitio de PCF que cause impacto en el tráfico, lo que requiere cierto tiempo para la resolución, es necesario aislar el sitio de PCF respectivo del tráfico para evitar cualquier impacto en el negocio.

Una vez finalizada la actividad o resuelto el problema de PCF, debe restaurar el sitio e introducir el tráfico.

Procedimiento para aislar y restaurar el sitio de PCF

Aislamiento del sitio PCF

Paso 1. Establezca el sistema en modo de apagado.

Paso 1.1. Desde el Master-1 del sitio aislado, inicie sesión en el centro de operaciones de PCF.

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

Paso 1.2. Configure el estado de registro de PCF UNDISCOVERABLE.

Es necesario actualizar el estado de registro de PCF como NO DETECTABLE en la función de repositorio de red (NRF) para evitar mensajes N7 que fluyan desde SMF a la PCF respectiva, lo que a su vez redirige el tráfico N7 hacia el sitio Geo Redundant apareado.

Para configurar el estado de registro de PCF como no detectable, utilice esta configuración del Centro de operaciones de PCF del sitio primario:

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

  · config - Ingresa al modo de configuración.
  · service-registration: Ingresa en el modo de configuración de registro del servicio.
  · profile - Ingresa al modo de configuración del perfil.
  · nf-status { REGISTERED | UNDISCOVERABLE } - Especifica el estado de registro de PCF. Para la función de aislamiento de sitios, establezca el estado en NO DETECTABLE. En este estado, todas las operaciones que involucran la instancia PCF se suspenden.

Paso 1.3. Configure el 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.

Espere a que el sistema funcione al 100%.

Paso 1.4. Compruebe que el estado de implementación del sistema es falso.

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

Paso 1.5. Recupere el id. de sitio del sistema que está apagado.

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

Paso 2. Configuración de notificación de vencimiento del temporizador CDL.

Paso 2.1. Conéctese al master-1 del sitio activo (sitio asociado) y conéctese al centro de operaciones PCF.

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

Paso 2.2. Configure la CDL del sitio activo para enviar notificaciones de vencimiento del temporizador para el sitio aislado.

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

Restauración del sitio de PCF

Paso 1. Deshabilitar la configuración de notificación de vencimiento del temporizador CDL.

Paso 1.1. Conéctese al master-1 del sitio activo y conéctese al centro de operaciones PCF.

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

Paso 2.1. La CDL debe configurarse de modo que no envíe notificaciones de vencimiento del temporizador al sitio aislado.

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

Paso 2. Ajuste el AJUSTE PCF KAFKA.

Es una acción necesaria establecer las vainas Kafka con el OFFSET más reciente para mantener la integridad y sincronización de la sesión CDL. Ejecute estos pasos desde el sitio PCF activo antes de intentar llevar el otro sitio PCF al estado activo.

Paso 2.1. Desde el Master-1 del sitio activo, recupere las vainas 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

Paso 2.2. Inicie sesión en Kafka-0 pod.

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

Paso 2.3. Ejecute un comando list para buscar los grupos de consumidores en los 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

Paso 2.4. Obtenga la descripción de los grupos de consumidores en Kafka. Asegúrese de utilizar el nombre de grupo de consumidores correcto del resultado del paso 2.3.

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

Resultado esperado:

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

Paso 2.5. Compruebe los nuevos valores OFFSET más recientes.

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

Resultado esperado:

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

Paso 2.6. Restablezca OFFSET a los nuevos valores más recientes.

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

Resultado esperado:

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

Paso 2.7. Compruebe los valores de posposición actuales.

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

Resultado esperado:

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

Paso 3. Establezca el sistema en Running modo

Paso 3.1. Abra cuatro terminales conectados al sitio aislado. El Master-1 del sitio está inactivo.
Paso 3.2. En el primer terminal. asegúrese de que el script /home/cloud-user/rs_0.sh  se encuentra en el nodo maestro.

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

Paso 3.3. En el segundo terminal, ejecute este comando, que es responsable de terminar las vainas rest-ep. Asegúrese de utilizar el espacio de nombres correcto.

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

Paso 3.4. Ejecute este script que es responsable de terminar las vainas de diámetro Rx en el tercer terminal.

watch ./rs_0.sh

Paso 3.5 Establezca el sistema en running desde el centro de operaciones PCF en el cuarto 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.

Espere a que el sistema funcione al 100%.

Paso 3.6. Ahora asegúrese de que no se ejecute ni rest-ep ni Rx.

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

Paso 3.7. Conéctese al maestro 1 de ambos sitios y recupere la dirección IP del extremo de base de datos del sitio remoto (dirección IP de replicación para el sitio asociado).

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

Resultado esperado:

db-endpoint host xx.xx.xx.xx

Paso 3.8 Compruebe el número de conexiones entre la IP de replicación de sitio asociado y CDL-EP (debe haber 5 conexiones).

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

Resultado esperado:

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

Paso 3.9. Verifique que no haya ningún mensaje de error reciente "Connection to remote systemID has been lost" en el 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

El resultado esperado en el estado limpio:

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

Resultado esperado si hay un problema:

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

Paso 3.10. Asegúrese de que todas las demás vainas funcionen correctamente sin ningún problema.

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

Paso 3.11. Supervise el gráfico de grafana de las CDL y asegúrese de que las estadísticas muestren las estadísticas de creación/actualización correctas.

Paso 3.12. Después de un par de minutos, asegúrese de que las listas CDL estén sincronizadas.

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

Resultado esperado:

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

Paso 3.13. Desde el sitio del par, verifique que el fabricante de espejos esté activo y running.

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

Paso 3.14. Interrumpa el guión en los otros 3 terminales del sitio que acaba de aparecer.

Paso 3.15. Ejecute este script para recrear las vainas de diámetro PCF Rx.

./rs_1.sh

Paso 3.16. Ejecute este comando para recrear los Pods rest-ep de PCF.

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

Paso 3.17. Una vez terminado, asegúrese de ejecutar el diámetro rest-ep o 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

Paso 3.18. En el cuarto terminal, configure el estado de registro de PCF REGISTERED.

Una vez que se completa la actividad y se resuelve el problema, es necesario actualizar el estado de registro de PCF como REGISTERED at Network Repository Function (NRF) para permitir que los mensajes N7 fluyan desde SMF al PCF respectivo.

Para configurar el estado de registro de PCF en REGISTERED (REGISTRADO), utilice esta configuración del Centro de operaciones de PCF del sitio principal:

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