Solución de Problemas de Recuperación de VM del Administrador de Sesión PCRF - Openstack

Introducción

Este documento describe el procedimiento de recuperación del administrador de sesiones implementado en implementaciones Ultra-M/Openstack.

Troubleshoot

Procedimientos de recuperación de instancia del administrador de sesiones

Encender el administrador de sesiones desde el estado SHUTOFF

Si alguna instancia se encuentra en estado SHUTOFF debido a un apagado planeado o a algún otro motivo, utilice este procedimiento para iniciar la instancia y habilitar el monitoreo it’s en ESC.

1. Verifique el estado de la instancia a través de OpenStack
   
   

   source /home/stack/destackovsrc-Pcrf
   nova list --fields name,host,status | grep sm-s1
   | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | SHUTOFF|

2. Compruebe si el equipo está disponible y asegúrese de que el estado esté activo.
   
   

   source /home/stack/destackovsrc
   nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
   | state                     | up                                       |
   | status                    | enabled                                  |

3. Inicie sesión en Elastic Services Controller (ESC) Master como usuario administrador y verifique el estado de la instancia en opdata. 
   
   

   /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0
   SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE

4. Encienda la instancia desde openstack
   
   

   source /home/stack/destackovsrc-Pcrf
   nova start SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

   .
5. Espere cinco minutos para que se inicie la instancia y llegue al estado activo.
   
   

   source /home/stack/destackovsrc-Pcrf
   nova list –fields name,status | grep sm-s1_0
   | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |

6. Habilite el monitor de VM en ESC después de que la instancia esté en estado activo.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

Para obtener más información sobre la recuperación de configuraciones de instancia, consulte los procedimientos específicos de tipo de instancia que se proporcionan en la siguiente sección.

Recuperar cualquier instancia del estado de ERROR

Este procedimiento se puede utilizar si el estado de la instancia de CPS en openstack es ERROR:

1. Compruebe el estado de la instancia en OpenStack.
   
   

   source /home/stack/destackovsrc-Pcrf
   nova list --fields name,host,status | grep sm-s1
   | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | ERROR|

2. Compruebe si el ordenador está disponible y funciona correctamente.
   
   

   source /home/stack/destackovsrc
   nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
   | state                     | up                                       |
   | status                    | enabled                                  |

3. Inicie sesión en ESC Master como usuario administrador y verifique el estado de la instancia en opdata.
   
   

   /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0
   
   SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE

4. Reinicie el estado de la instancia para obligar a la instancia de nuevo a un estado activo en lugar de a un estado de error, una vez hecho, reinicie la instancia.
   
   

   source /home/stack/destackovsrc-Pcrf
   
   nova reset-state –active SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
   nova reboot –-hard  SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

5. Espere cinco minutos para que la instancia se inicie y llegue al estado activo.
   
   

   source /home/stack/destackovsrc-Pcrf
   nova list –fields name,status | grep sm
   | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |

6. Si, Cluster Manager cambia el estado a ACTIVE después del reinicio, Enable VM Monitor in ESC después de que la instancia del Cluster Manager esté en estado activo.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

Post recovery to running/active state, consulte el procedimiento específico del tipo de instancia para recuperar config/data de backup.

Recuperación del administrador de sesiones/MongoDB

Session Manager proporciona la capa de base de datos al Cluster Policy Suite en esta sección, se discute la recuperación de bases de datos en una instancia recientemente recuperada del administrador de sesiones:

Miembro del conjunto de réplicas en estado fuera de línea

Si los miembros de un conjunto de réplicas están en estado sin conexión, utilice este procedimiento:

1. Verifique el estado del conjunto de réplicas usando este comando en el Administrador de clústeres.

diagnostics.sh --get_replica_status

2. Enumera todos los miembros OFF-LINE en todos los conjuntos de réplicas.
   
   
3. Ejecute el comando en Cluster Manager.

cd /var/qps/bin/support/mongo
build_set.sh --all --create-scripts

4. Proteja el shell a las VM de session mgr e inicie el proceso mongo.

ssh sessionmgrXX
/etc/init.d/sessionmgr-XXXXX start

Miembro(s) del conjunto de réplicas atascado en estado de inicio2/recuperación para un estado de tiempo prolongado

Si los miembros de un conjunto de réplicas están atascados en el estado de inicio 2 o recuperación y el primario está disponible en el conjunto de réplicas, utilice este procedimiento:

1. Verifique el estado del conjunto de réplicas usando este comando en el Administrador de clústeres.

diagnostics.sh --get_replica_status

2. Lista todos los miembros en todos los conjuntos de réplicas.

3. Proteja el shell a las VM de sessionmgr y obtenga la ubicación de almacenamiento del proceso mongo.Como se muestra en el ejemplo dbpath es /var/data/sessions.1/b para el proceso mongo que se ejecuta en sessionmgr01 en el puerto 37717.

ssh sessionmgr01
ps -ef | grep mongo | grep 37717
root      2572     1 25 Feb11 ?        24-11:43:43 /usr/bin/mongod --ipv6 --nojournal --storageEngine mmapv1 --noprealloc --smallfiles --port 37717 --dbpath=/var/data/sessions.1/b --replSet set01b --fork --pidfilepath /var/run/sessionmgr-37717.pid --oplogSize 5120 --logpath /var/log/mongodb-37717.log --logappend --quiet --slowms 500

4. Detenga el proceso mongo y limpie el contenido en dbpath:

/etc/init.d/sessionmgr-xxxxx stop
rm -rf /var/data/sessions.1/b/*

5. Inicie el proceso mongo, esto hace que el miembro del conjunto de réplicas sincronice todos los datos de la base de datos primaria y no el registro.

/etc/init.d/sessionmgr-xxxxx start

El paso 5 puede tardar bastante tiempo en sincronizarse en todos los datos desde el primario, dependiendo del tamaño de la base de datos.

Conjuntos de réplicas de reconstrucción

Debido a algunas interrupciones, puede que sea necesario reconstruir algunos o todos los conjuntos de réplicas. Sin embargo, antes de tomar la decisión de reconstruir algunos o todos los conjuntos de réplicas, se puede observar que se podrían perder todos los datos de estos conjuntos de réplicas. La disponibilidad de las copias de seguridad debe verificarse cruzada para estas bases de datos:

• Admin (generalmente en 27721)
• Saldo (generalmente en el puerto 27718)
• SPR (generalmente en el puerto 27720)

Una vez que se verifican las copias de seguridad y se toma la decisión de volver a crear conjuntos de réplicas de bases de datos, utilice este procedimiento:

1. Compruebe el contenido de /etc/broadhop/mongoConfig.cfg, LLD debe tener información sobre qué configuración debe estar presente en este archivo o puede utilizar un archivo de copia de seguridad.
   

2. El comando build_set.sh —<db-name> —create debe ejecutarse en Cluster Manager, que depende de la base de datos que se pretende reconstruir. Crea todos los conjuntos de réplicas relacionados con esa base de datos.

Nota: El comando para crear todos los dbs en un conjunto de réplicas limpia la base de datos. Se perdería todo el contenido del conjunto de réplicas.

3. Si desea reconstruir un conjunto de réplicas específico para una base de datos, utilice este comando:

build_set.sh --
     
     
       --create --setname 
       
     

4. Si desea reconstruir todos los conjuntos de réplicas para todas las bases de datos, utilice este comando:

build_set.sh --all --create 

Restauración de la Base de Datos desde el Conjunto de Réplica de Post de Respaldo

Una vez que todos los miembros del conjunto de réplicas están en línea y uno de los miembros es primario, mongoDB se puede restaurar desde la copia de seguridad a través de este procedimiento.

1. Para restaurar todas las bases de datos desde la copia de seguridad, utilice este comando:

config_br.py --action import --mongo-all  /mnt/backup/
     
      

2. Para restaurar una base de datos específica desde la copia de seguridad a través de config_br.py estas opciones están disponibles:

• SPR

config_br.py --action import --mongo-all --spr /mnt/backup/
     
     

config_br.py --action import  --mongo-all --admin  /mnt/backup/
      
      

config_br.py --action import  --mongo-all --balance  /mnt/backup/
       
        

config_br.py --action import  --mongo-all --report  /mnt/backup/
       
       

mongorestore --host 
        
        
          --port 
         
           --db 
          
            --