Solução de problemas de recuperação de VM do PCRF Session Manager - Openstack

Opções de download

  • PDF     (158.3 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (88.1 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (77.8 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:4 de setembro de 2018
ID do documento:213624

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.

    Introduction

    Este documento descreve o procedimento de Recuperação do Session Manager implantado em implantações Ultra-M/Openstack.

    Troubleshoot

    Procedimentos de Recuperação de Instância do Session Manager

    Ligar o Session Manager do estado SHUTOFF

    Se algum caso estiver no estado SHUTOFF devido a um desligamento planejado ou por algum outro motivo, use este procedimento para iniciar a instância e habilitar o monitoramento do€™ no ESC.

    1. Verifique o estado da instância através do 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. 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                                  |
    3. Faça login no controlador de serviços elásticos (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 sm-s1_0
SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE
    4. Ligue a instância do openstack

      source /home/stack/destackovsrc-Pcrf
nova start SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
      .
    5. Aguarde cinco minutos por exemplo para inicializar e chegar ao estado ativo.

      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. 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 SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

      

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

    Recuperar qualquer instância do estado ERROR

    Este procedimento pode ser usado se o estado da instância do CPS no openstack for ERROR:

    1. Verifique o estado da instância no 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. 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                                  |
    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 sm-s1_0

SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE
    4. 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 SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
nova reboot –-hard  SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
    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 sm
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |
    6. Se o Gerenciador de clusters mudar o estado para ATIVO após a reinicialização, Habilite o Monitor VM no ESC depois que a instância do Gerenciador de clusters estiver no estado ativo.
    /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

      

    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.

    Recuperação do Session Manager/MongoDB

    O Session Manager fornece a camada de banco de dados para o Cluster Policy Suite nesta seção, discute-se a recuperação de bancos de dados em uma instância recuperada recentemente do session manager:

    Membro do Conjunto de Réplicas no Estado Offline

    Se os membros de um conjunto de réplicas estiverem no estado off-line, use este procedimento:

    1. Verifique o status do conjunto de réplicas usando este comando no Gerenciador de Clusters.
    diagnostics.sh --get_replica_status

      

    1. Liste todos os membros OFF-LINE em todos os conjuntos de réplicas.

    2. Execute o comando no Gerenciador de clusters.
    cd /var/qps/bin/support/mongo
build_set.sh --all --create-scripts
    1. Proteja o shell para as VMs do gerente de sessões e inicie o processo mongo.
    ssh sessionmgrXX
/etc/init.d/sessionmgr-XXXXX start

    Membro(s) do Conjunto de Réplicas preso no Estado Inicialização2/Recuperação por um Estado de Longo Tempo

    Se os membros de um conjunto de réplicas estiverem presos no estado de inicialização2 ou de recuperação e o primário estiver disponível no conjunto de réplicas, use este procedimento:

    1. Verifique o status do conjunto de réplicas usando este comando no Gerenciador de Clusters.
    diagnostics.sh --get_replica_status

      

    1. Liste todos os membros em todos os conjuntos de réplicas.
    1. Proteja o shell para as VMs do sessionmgr e obtenha o local de armazenamento do processo mongo. Como mostrado no exemplo, dbpath é /var/data/sessions.1/b para o processo mongo em execução no sessionmgr01 na porta 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

       

    1. Pare o processo mongo e limpe o conteúdo no dbpath:
    /etc/init.d/sessionmgr-xxxxx stop
rm -rf /var/data/sessions.1/b/*
    1. Inicie o processo mongo, isso faz com que o membro do conjunto de réplicas sincronize todos os dados do banco de dados principal e não o log.
    /etc/init.d/sessionmgr-xxxxx start

    A etapa 5 pode levar um tempo considerável para sincronizar todos os dados do principal, dependendo do tamanho do banco de dados.

    Reconstruir Conjuntos de Réplicas

    Devido a algumas interrupções, pode ser necessário reconstruir alguns ou todos os conjuntos de réplicas. No entanto, antes de ser tomada a decisão de reconstruir alguns ou todos os conjuntos de réplicas, pode-se observar que todos os dados nesses conjuntos de réplicas podem ser perdidos. A disponibilidade de backups deve ser verificada para esses bancos de dados:

    • Administrador (geralmente em 27721)
    • Saldo (geralmente na porta 27718)
    • SPR (geralmente na porta 27720)

    Depois que os backups forem verificados cruzadamente e a decisão de recriar conjuntos de réplicas do banco de dados for tomada, use este procedimento:

    1. Verifique o conteúdo de /etc/broadhop/mongoConfig.cfg, o LLD deve ter informações sobre qual configuração deve estar presente neste arquivo ou você pode usar um arquivo de backup.
    1. O comando build_set.sh —<db-name> —create deve ser executado no Cluster Manager, que depende do banco de dados que você pretende reconstruir. Ele cria todos os conjuntos de réplicas relacionados a esse banco de dados.

    Note: O comando para criar todos os dbs em um conjunto de réplicas limpa o banco de dados. Todo o conteúdo do conjunto de réplicas seria perdido.

    1. Se desejar recriar um conjunto de réplicas específico para um banco de dados, use este comando:
    build_set.sh --
     
     
       --create --setname

      

    1. Se desejar reconstruir todos os conjuntos de réplicas de todos os bancos de dados, use este comando:
    build_set.sh --all --create

    Restaurar o banco de dados do conjunto de réplicas da postagem de backup

    Quando todos os membros do conjunto de réplicas estiverem on-line e um dos membros for primário, o mongoDB poderá ser restaurado a partir do backup através deste procedimento.

    1. Para restaurar todos os DBs do backup, use este comando:
    config_br.py --action import --mongo-all  /mnt/backup/
    1. Para restaurar um banco de dados específico do backup através de config_br.py, estas opções estão disponíveis:
    • SPR
    config_br.py --action import --mongo-all --spr /mnt/backup/

      

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

      

    • Equilíbrio 
    config_br.py --action import  --mongo-all --balance  /mnt/backup/

      

    • Relatórios
    config_br.py --action import  --mongo-all --report  /mnt/backup/

    Se o mongodump for usado para fazer backup de bancos de dados, isso explica seu uso por meio da restauração mongo:

    1. Extraia o arquivo backup tar.gz.

      tar -zxf /mnt/backup/
    2. Localize a pasta que contém o despejo mongo do banco de dados que deseja recuperar e altere o diretório para inseri-lo.

      ls -ltr  /mnt/backup/cd /mnt/backup/27721_backup_$(date +\%Y-\%m-\%d)/dump
    3. Restaure o conjunto de réplicas do backup.

      mongorestore --host 
          
          
            --port
    4. Opcionalmente para restaurar uma coleção específica ou um db, use este comando:
    mongorestore --host 
        
        
          --port 
         
           --db 
          
            --
    TAC Authored

    Colaborado por engenheiros da Cisco

    • Nitesh Bansal
      Cisco Advance Services

    Este documento lhe foi útil?

    FeedbackFeedback

    Contate a Cisco

    Este documento se refere a estes produtos