Solución de Problemas de PCRF VM Recovery-Arbiter- Openstack

Introducción

Este documento describe cómo recuperar instancias de Cisco Virtual Policy and Charging Rules Function (vPCRF) implementadas en la implementación de Ultra-M/Openstack.

Colaborado por Nitesh Bansal, Cisco Advance Services.

Prerequisites

Requirements

Cisco recomienda que conozca estos temas:

• Openstack
• CPS
• Ya está disponible el cálculo en el que se implementaron las instancias afectadas.
• Los recursos de cálculo están disponibles en la misma zona de disponibilidad que la instancia afectada.

Componentes Utilizados

La información en este documento se basa en CPS y se aplica a todas las versiones.

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. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.  

Troubleshoot

Poder del árbitro del estado de SHUTOFF

Si alguna instancia se encuentra en estado SHUTOFF debido a un apagado planificado o a algún otro motivo, utilice el siguiente procedimiento para iniciar la instancia y habilitar su supervisión en el controlador de servicio elástico (ESC).

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

source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep arbiter
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | destackovs-compute-2  | SHUTOFF|

Paso 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                                  |

Paso 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 arbiter
r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE

Paso 4. Encienda la instancia desde openstack.

source /home/stack/destackovsrc-Pcrf
nova start r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Paso 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 cm
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | ACTIVE |

Paso 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 r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Para obtener más información sobre la recuperación de configuraciones de instancias, consulte los procedimientos específicos del tipo de instancia que se proporcionan a continuación.

Recuperar cualquier instancia del estado de ERROR

Si el estado de la instancia de CPS en openstack está en estado ERROR, utilice el siguiente procedimiento para iniciar la instancia:

Paso 1. 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 r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
nova reboot –-hard  r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Paso 2. 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 arbiter
r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE

Paso 3. 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                                  |

 Paso 4. Compruebe el estado de la instancia en OpenStack.

source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep arbiter
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | destackovs-compute-2  | ERROR|

Paso 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 arbiter
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | ACTIVE |

 Paso 6. Si Cluster Manager cambia el estado a ACTIVE después del reinicio, habilita VM Monitor en 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 r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

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

Arbiter de recuperación/arbitervip

Si una instancia/pcrfclient del árbitro se recupera recientemente y el árbitro no se encuentra en el resultado diagnostics.sh get_réplica_status , siga este procedimiento.

Si la implementación tiene una VM de árbitro dedicada, utilice los pasos 1 a 3 , para que arbitervip ejecute adicionalmente el paso 4, ejecute estos pasos:

1. En el cluster manager, ejecute este comando para crear los scripts mongodb start/stop basados en la configuración del sistema:
   
   

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

2.  En PCRFCLIENTXX o (y) árbitro ejecute este comando para enumerar todos los procesos que necesita iniciar.

cd etc/init.d/
ll | grep sessionmgr

3.  En PCRFCLIENTXX o (y) árbitro para cada archivo enumerado en la última salida, ejecute este comando, reemplace xxxxx por números de puerto, ejemplo para 27717 aquí:

/etc/init.d/sessionmgr-xxxxx start
Example:
/etc/init.d/sessionmgr-27717 start

  

4. Si se utiliza la vip del árbitro, verifique si alguno de los recursos de pcs en pcrfclient01 requiere limpieza con la ayuda de estos comandos:
   
   

   pcs resource show | grep –v started

Si el comando devuelve algún resultado en el paso 4, limpie el recurso de pcs mediante el siguiente comando, para varios recursos de pcs que no se iniciaron, repita el comando para cada recurso:

pcs resource cleanup 
     
     

Verificación

Verifique el estado de la réplica :

Run diagnostics.sh on pcrfclient01

Si el árbitro se ejecuta como árbitro y no como árbitro/pcrfclient, entonces para verificar si la VM está totalmente recuperada o no, puede realizar estos pasos:

1. En el árbitro primario, todos los procesos mongo deben ejecutarse y se puede verificar con este comando en el árbitro:
   
   

   ps –aef | grep mongo

2. Verifique que todos los procesos bajo supervisión monit estén en buen estado (Ejecución/Supervisión) para el árbitro.
   
   

   monit summary