Contents

Introduction

Troubleshoot

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

Ligar o Session Manager do estado SHUTOFF

Recuperar qualquer instância do estado ERROR

Recuperação do Session Manager/MongoDB

Membro do Conjunto de Réplicas no Estado Offline

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

Reconstruir Conjuntos de Réplicas

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

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

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

3. Execute o comando no Gerenciador de clusters.

cd /var/qps/bin/support/mongo

build_set.sh --all --create-scripts

4. 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

2. Liste todos os membros em todos os conjuntos de réplicas.

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

4. Pare o processo mongo e limpe o conteúdo no dbpath:

/etc/init.d/sessionmgr-xxxxx stop

rm -rf /var/data/sessions.1/b/*

5. 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.

2. 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.

3. Se desejar recriar um conjunto de réplicas específico para um banco de dados, use este comando:

build_set.sh --

--create --setname

4. 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/

2. 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

--