Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Troubleshoot

Ligar o árbitro do estado SHUTOFF

Recuperar qualquer instância do estado ERROR

Recuperar Arbiter/arbitervip

Verificar

Introduction

Este documento descreve como recuperar instâncias da Cisco Virtual Policy and Charging Rules Function (vPCRF) implantadas na implantação do Ultra-M/Openstack.

Contribuído por Nitesh Bansal, Cisco Advance Services.

Prerequisites

Requirements

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

- Openstack

- CPS

- O cálculo em que as instâncias afetadas foram implantadas está agora disponível.

- Os recursos de computação estão disponíveis na mesma zona de disponibilidade da instância afetada.

Componentes Utilizados

As informações neste documento são baseadas no CPS e aplicáveis a todas as versões.

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.

Troubleshoot

Ligar o árbitro do estado SHUTOFF

Se alguma instância estiver no estado SHUTOFF devido a um desligamento planejado ou algum outro motivo, use o procedimento a seguir para iniciar a instância e habilitar sua monitoração no Controlador de serviço elástico (ESC).

Etapa 1. Verifique o estado da instância através do 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|

Etapa 2. Verifique se o computador está disponível e se o estado está ativo.

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’

| state                     | up                                       |

| status                    | enabled                                  |

Etapa 3. Faça login no ESC Master como usuário admin e verifique o estado da instância no 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

Etapa 4. Ligue a instância do openstack.

source /home/stack/destackovsrc-Pcrf

nova start r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Etapa 5. Aguarde cinco minutos para que a instância seja inicializada e chegue ao estado ativo.

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 |

Etapa 6. Ative o VM Monitor no ESC depois que a instância estiver no estado ativo.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Para obter mais recuperação das configurações de instância, consulte os procedimentos específicos de tipo de instância fornecidos abaixo.

Recuperar qualquer instância do estado ERROR

Se o estado da instância do CPS no openstack estiver no estado ERROR, use o seguinte procedimento para iniciar a instância:

Etapa 1. Redefina o estado da instância para forçar a instância de volta a um estado ativo em vez de um estado de erro, uma vez concluído, reinicialize a instância.

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

Etapa 2. Faça login no ESC Master como usuário admin e verifique o estado da instância no 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

Etapa 3. Verifique se o computador está disponível e funciona bem.

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’

| state                     | up                                       |

| status                    | enabled                                  |

Etapa 4. Verifique o estado da instância no 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|

Etapa 5. Aguarde cinco minutos para que a instância seja inicializada e chegue ao estado ativo.

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 |

Etapa 6. Se O Gerenciador de Cluster muda o estado para ATIVO após a reinicialização, ative o Monitor VM no ESC depois que a instância do Gerenciador de Cluster estiver no estado ativo.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Passo 7. Após a recuperação para o estado em execução/ativo, consulte o procedimento específico do tipo de instância para recuperar a configuração/os dados do backup.

Recuperar Arbiter/arbitervip

Se uma instância de árbitro/pcrfclient for recuperada recentemente e o árbiter não estiver na saída diagnostics.sh get_réplica_status, siga este procedimento.

Se a implantação tiver uma VM de árbitro dedicada, use as etapas de 1 a 3 , para executar arbitervip adicionalmente na etapa 4, execute estas etapas:

1. No gerenciador de cluster, execute este comando para criar os scripts mongosb start/stop com base na configuração do sistema:

cd /var/qps/bin/support/mongo

build_set.sh --all --create-scripts

2.  Em PCRFCLIENTXX ou (e) árbiter, execute este comando para listar todos os processos que você precisa iniciar.

cd etc/init.d/

ll | grep sessionmgr

3.  Em PCRFCLIENTXX ou (e) árbiter para cada arquivo listado na última saída, execute este comando, substitua xxxx por números de porta, por exemplo, para 27717 aqui:

/etc/init.d/sessionmgr-xxxxx start

Example:

/etc/init.d/sessionmgr-27717 start

4. Se o arbiter vip for usado, verifique se algum dos recursos do pcs no pcrfclient01 exige limpeza com a ajuda destes comandos:

pcs resource show | grep –v started

Se alguma saída for retornada pelo comando na etapa 4 limpe o recurso pcs usando o seguinte comando, para vários recursos pcs que não foram iniciados, repita o comando para cada recurso:

pcs resource cleanup

Verificar

Verifique a integridade do status da réplica:

Run diagnostics.sh on pcrfclient01

Se o árbitro for executado como um árbiter e não como um arbiter/pcrfclient, então para verificar se a VM está totalmente recuperada ou não, você pode executar estas etapas:

1. No árbitro principal, todos os processos mongo devem ser executados e podem ser verificados com este comando no árbiter:

ps –aef | grep mongo

2. Verifique se todos os processos em monitoração de mês estão em um estado bom (em execução/monitorado) para árbitro.

monit summary