Solução de problemas de PCRF VM Recovery-Arbiter- Openstack
Opções de download
Linguagem imparcial
O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
Sobre esta tradução
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Contents
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:
- 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
- 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:
- No árbitro principal, todos os processos mongo devem ser executados e podem ser verificados com este comando no árbiter:
ps –aef | grep mongo
- 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
Colaborado por engenheiros da Cisco
- Nitesh BansalCisco Advance Services
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)