Backup e recuperação - recuperação completa do cluster - CPS
Contents
Introduction
Este documento descreve as etapas necessárias para recuperar um cluster CPS inteiro em uma configuração Ultra-M que hospeda as funções de rede virtual (VNFs) do CPS.
Informações de Apoio
O Ultra-M é uma solução de núcleo de pacotes móveis virtualizados, pré-embalada e validada, projetada para simplificar a implantação de VNFs. A solução Ultra-M consiste nos seguintes tipos de máquina virtual (VM):
- Controlador de serviços elásticos (ESC)
- Cisco Policy Suite (CPS)
A arquitetura de alto nível da Ultra-M e os componentes envolvidos estão descritos nesta imagem:
Este documento destina-se ao pessoal da Cisco familiarizado com a plataforma Ultra-M da Cisco.
Abreviaturas
| VNF | Função de rede virtual |
| ESC | Controlador de serviço elástico |
| MOP | Método de Procedimento |
| OSD | Discos de Armazenamento de Objeto |
| HDD | Unidade de disco rígido |
| SSD | Unidade de estado sólido |
| VIM | Virtual Infrastructure Manager |
| VM | Máquina virtual |
| UUID | Identificador de ID universal exclusivo |
Hipótese
Para este procedimento, presume-se que apenas o cluster CPS deve ser recuperado e que todos os componentes ao nível de Openstack estão operacionais, incluindo o ESC
Procedimento de restauração
Quando o ESC não inicia a VM:
- Em alguns casos, o ESC falha ao iniciar a VM devido a um estado inesperado. Uma solução alternativa é executar um switchover ESC reinicializando o ESC mestre. O switchover do ESC leva aproximadamente um minuto. Execute health.sh no novo ESC mestre para verificar se ele está ativado. Quando o ESC se tornar Master, o ESC poderá corrigir o estado da VM e iniciar a VM. Como essa operação está agendada, você deve aguardar de 5 a 7 minutos para que seja concluída.
- Você pode monitorar /var/log/esc/yangesc.log e /var/log/esc/escmanager.log. Se você NÃO vir a VM sendo recuperada após 5 a 7 minutos, o usuário precisaria ir e fazer a recuperação manual das VMs afetadas.
- Depois que a VM for restaurada e executada com êxito; certifique-se de que toda a configuração específica do syslog seja restaurada a partir do backup conhecido anterior. Verifique se ele foi restaurado em todas as VMs do ESC
root@abautotestvnfm1em-0:/etc/rsyslog.d# pwd
/etc/rsyslog.d
root@abautotestvnfm1em-0:/etc/rsyslog.d# ll
total 28
drwxr-xr-x 2 root root 4096 Jun 7 18:38 ./
drwxr-xr-x 86 root root 4096 Jun 6 20:33 ../]
-rw-r--r-- 1 root root 319 Jun 7 18:36 00-vnmf-proxy.conf
-rw-r--r-- 1 root root 317 Jun 7 18:38 01-ncs-java.conf
-rw-r--r-- 1 root root 311 Mar 17 2012 20-ufw.conf
-rw-r--r-- 1 root root 252 Nov 23 2015 21-cloudinit.conf
-rw-r--r-- 1 root root 1655 Apr 18 2013 50-default.conf
root@abautotestvnfm1em-0:/etc/rsyslog.d# ls /etc/rsyslog.conf
rsyslog.conf
Recuperação de CPS
1. Criar um backup do Gerenciador de cluster CPS
Etapa 1. Use o seguinte comando para exibir as instâncias de nova e anote o nome da instância de VM do gerenciador de cluster:
nova list
Impeça o Cluman de ESC.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP
Etapa 2. Verifique o gerenciador de cluster no estado SHUTOFF.
admin@esc1 ~]$ /opt/cisco/esc/confd/bin/confd_cli admin@esc1> show esc_datamodel opdata tenants tenant Core deployments * state_machine
Etapa 3. Crie uma imagem de snapshot nova conforme mostrado neste comando:
nova image-create --poll
Importante - Caso a VM se torne inalcançável após a criação do snapshot, verifique o status da VM usando o comando nova list. Se estiver no estado "SHUTOFF", você precisará iniciar a VM manualmente.
Etapa 4. Exiba a lista de imagens com o seguinte comando: nova image-list Figura 1: Saída de exemplo
Etapa 5. Quando um snapshot é criado, a imagem do snapshot é armazenada no OpenStack Glance. Para armazenar o snapshot em um armazenamento de dados remoto, baixe o snapshot e transfira o arquivo no OSPD para ( /home/stack/CPS_BACKUP )
Para baixar a imagem, use o seguinte comando no OpenStack:
glance image-download –-file For example: glance image-download –-file snapshot.raw 2bbfb51c-cd05-4b7c-ad77-8362d76578db
Etapa 6. Liste as imagens baixadas conforme mostrado no seguinte comando:
ls —ltr *snapshot*
Example output: -rw-r--r--. 1 root root 10429595648 Aug 16 02:39 snapshot.raw
Passo 7. Armazene o instantâneo da VM do Cluster Manager a ser restaurado no futuro.
2. Faça backup da configuração e do banco de dados.
1. config_br.py -a export --all /var/tmp/backup/ATP1_backup_all_$(date +\%Y-\%m-\%d).tar.gz OR 2. config_br.py -a export --mongo-all /var/tmp/backup/ATP1_backup_mongoall$(date +\%Y-\%m-\%d).tar.gz 3. config_br.py -a export --svn --etc --grafanadb --auth-htpasswd --haproxy /var/tmp/backup/ATP1_backup_svn_etc_grafanadb_haproxy_$(date +\%Y-\%m-\%d).tar.gz 4. mongodump - /var/qps/bin/support/env/env_export.sh --mongo /var/tmp/env_export_$date.tgz 5. patches - cat /etc/broadhop/repositories, check which patches are installed and copy those patches to the backup directory /home/stack/CPS_BACKUP on OSPD 6. backup the cronjobs by taking backup of the cron directory: /var/spool/cron/ from the Pcrfclient01/Cluman. Then move the file to CPS_BACKUP on the OSPD.
Verifique na crontab -l se é necessário qualquer outro backup
Transferir todos os backups para o OSPD /home/stack/CPS_BACKUP
3. Faça backup do arquivo de teste do ESC Master.
/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u
-p
--get-config > /home/admin/ESC_config.xml
Transferir o arquivo em OSPD /home/stack/CPS_BACKUP
4. Fazer backup de entradas crontab -l
Crie um arquivo txt com crontab -l e ftp para um local remoto ( em OSPD /home/stack/CPS_BACKUP )
5. Faça um backup dos arquivos de rota do cliente LB e PCRF.
Collect and scp the below conifgurations from both LBs and Pcrfclients route -n /etc/sysconfig/network-script/route-*
Restaurar VM do Cluster Manager no OpenStack
Etapa 1. Copie o snapshot de VM do gerenciador de cluster para o blade do controlador, conforme mostrado neste comando:
ls —ltr *snapshot*
Saída de exemplo: -rw-r—r—. 1 raiz raiz 10429595648 Ago 16 02:39 snapshot.raw
Etapa 2. Carregue a imagem do snapshot no OpenStack do Datastore:
glance image-create --name --file --disk-format qcow2 --container-format bare
Etapa 3. Verifique se o snapshot é carregado com um comando Nova, como mostrado neste exemplo:
nova image-list
Figura 2: Saída de exemplo
Etapa 4. Dependendo se a VM do gerenciador de cluster existe ou não, você pode optar por criar o cluman ou reconstruir o cluman:
Se a instância da VM do Cluster Manager não existir, crie a VM Cluman com um comando Heat ou Nova como mostrado no exemplo a seguir:
Crie a VM Cluman com ESC
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/
O cluster PCRF será gerado com a ajuda do comando acima e, em seguida, restaurará as configurações do gerenciador de cluster a partir dos backups realizados com a restauração config_br.py, mongorestore a partir do dump tomado em backup
delete - nova boot --config-drive true --image "" --flavor "" --nic net-id=",v4-fixed-ip=" --nic net-id="network_id,v4-fixed-ip=ip_address" --block-device-mapping "/dev/vdb=2edbac5e-55de-4d4c-a427-ab24ebe66181:::0" --availability-zone "az-2:megh-os2-compute2.cisco.com" --security-groups cps_secgrp "cluman"
Se a instância da VM do Cluster Manager existir, use um comando rebuild nova para reconstruir a instância da VM Cluman com o snapshot carregado, como mostrado:
nova rebuild
Por exemplo: nova rebuild cps-cluman-5f3tujqvbi67 cluman_snapshot
Etapa 5 Listar todas as instâncias conforme mostrado e verificar se a nova instância do gerenciador de cluster foi criada e está em execução:
lista nova
Figura 3: Saída de exemplo
Restaure os patches mais recentes no sistema
1. Copy the patch files to cluster manager which were backed up in OSPD /home/stack/CPS_BACKUP 2. Login to the Cluster Manager as a root user. 3. Untar the patch by executing the following command: tar -xvzf [patch name].tar.gz 4. Edit /etc/broadhop/repositories and add the following entry: file:///$path_to_the plugin/[component name] 5. Run build_all.sh script to create updated QPS packages: /var/qps/install/current/scripts/build_all.sh 6. Shutdown all software components on the target VMs: runonall.sh sudo monit stop all 7. Make sure all software components are shutdown on target VMs: statusall.sh
Restaure os trabalhos em frente
- Mover o arquivo de backup do OSPD para o Cluman/Pcrfclient01
- Execute o comando para ativar o cronjob a partir do backup
#crontab Cron-backup - Verifique se cronjobs foram ativados pelo comando abaixo
#crontab -l
Restaurar VMs individuais no cluster
Para reimplantar a VM pcrfclient01
Etapa 1. Faça login na VM do Cluster Manager como o usuário raiz.
Etapa 2. Observe o UUID do repositório SVN usando o seguinte comando:
svn info http://pcrfclient02/repos | grep UUID
O comando exibirá o UUID do repositório.
Por exemplo: UUID do repositório: ea50bbd2-5726-46b8-b807-10f4a7424f0e
Etapa 3. Importe os dados de configuração do Policy Builder de backup no Cluster Manager, como mostrado no seguinte exemplo:
config_br.py -a import --etc-oam --svn --stats --grafanadb --auth-htpasswd --users /mnt/backup/oam_backup_27102016.tar.gz
Etapa 4. Para gerar os arquivos de arquivo da VM no Cluster Manager usando as configurações mais recentes, execute o seguinte comando:
/var/qps/install/current/scripts/build/build_svn.sh
Etapa 5. Para implantar a VM pcrfclient01, execute um dos seguintes procedimentos:
No OpenStack, use o modelo HEAT ou o comando Nova para recriar a VM. Para obter mais informações, consulte o Guia de Instalação do CPS para OpenStack.
Etapa 6. Restabeleça a sincronização mestre/escravo do SVN entre pcrfclient01 e pcrfclient02 com pcrfclient01 como mestre à medida que executa esses comandos.
Se o SVN já estiver sincronizado, não emita esses comandos.
Para verificar se o SVN está sincronizado, execute este comando a partir de pcrfclient02.
Se um valor for retornado, o SVN já está sincronizado:
/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos
Execute estes comandos a partir de pcrfclient01:
/bin/rm -fr /var/www/svn/repos /usr/bin/svnadmin create /var/www/svn/repos /usr/bin/svn propset --revprop -r0 svn:sync-last-merged-rev 0 http://pcrfclient02/repos-proxy-sync /usr/bin/svnadmin setuuid /var/www/svn/repos/ "Enter the UUID captured in step 2" /etc/init.d/vm-init-client /var/qps/bin/support/recover_svn_sync.sh
Passo 7. Se pcrfclient01 também for a VM do árbiter, execute estas etapas:
1. Crie os scripts mongosb start/stop com base na configuração do sistema. Nem todas as implantações têm todos esses bancos de dados configurados.
cd /var/qps/bin/support/mongo build_set.sh --session --create-scripts build_set.sh --admin --create-scripts build_set.sh --spr --create-scripts build_set.sh --balance --create-scripts build_set.sh --audit --create-scripts build_set.sh --report --create-scripts
2. Inicie o processo mongo:
/usr/bin/systemctl start sessionmgr-XXXXX
3. Aguarde o árbitro iniciar e execute diagnostics.sh — get_réplica_status para verificar a integridade do conjunto de réplicas.
Para reimplantar a VM pcrfclient02
Etapa 1. Faça login na VM do Cluster Manager como o usuário raiz.
Etapa 2. Para gerar os arquivos de arquivo da VM no Cluster Manager usando as configurações mais recentes, execute este comando:
/var/qps/install/current/scripts/build/build_svn.sh
Etapa 3 Para implantar a VM pcrfclient02, execute um dos seguintes procedimentos:
No OpenStack, use o modelo HEAT ou o comando Nova para recriar a VM. Para obter mais informações, consulte o Guia de Instalação do CPS para OpenStack.
Etapa 4 Secure shell para o pcrfclient01:
ssh pcrfclient01
Etapa 5 Executar este script para recuperar os acordos de SVN do pcrfclient01:
/var/qps/bin/support/recover_svn_sync.sh
Para reimplantar uma VM do gerente de sessões
Etapa 1. Faça login na VM do Cluster Manager como o usuário raiz
Etapa 2. Para implantar a VM do sessionmgr e substituir a VM com falha ou corrompida, execute um destes procedimentos:
No OpenStack, use o modelo HEAT ou o comando Nova para recriar a VM. Para obter mais informações, consulte o Guia de instalação do CPS para OpenStack
Etapa 3. Crie os scripts mongosb start/stop com base na configuração do sistema.
Nem todas as implantações têm todos esses bancos de dados configurados. Consulte /etc/broadhop/mongoConfig.cfg para determinar quais bancos de dados precisam ser configurados
cd /var/qps/bin/support/mongo build_set.sh --session --create-scripts build_set.sh --admin --create-scripts build_set.sh --spr --create-scripts build_set.sh --balance --create-scripts build_set.sh --audit --create-scripts build_set.sh --report --create-scripts
Etapa 4. Proteja o shell para a VM do sessionmgr e inicie o processo mongo:
ssh sessionmgrXX /usr/bin/systemctl start sessionmgr-XXXXX
Etapa 5. Aguarde até que os membros iniciem e os membros secundários sincronizem e execute diagnostics.sh — get_réplica_status para verificar a integridade do banco de dados.
Etapa 6. Para restaurar o banco de dados do Session Manager, use um dos seguintes comandos de exemplo, dependendo se o backup foi executado com a opção —mongo-all ou —mongo:
• config_br.py -a import --mongo-all --users /mnt/backup/Name of backup or • config_br.py -a import --mongo --users /mnt/backup/Name of backup
Para reimplantar a VM do Policy Diretor (Balanceador de carga)
Etapa 1. Faça login na VM do Cluster Manager como o usuário raiz.
Etapa 2. Para importar os dados de configuração do Policy Builder de backup no Cluster Manager, execute este comando:
config_br.py -a import --network --haproxy --users /mnt/backup/lb_backup_27102016.tar.gz
Etapa 3 Para gerar os arquivos de arquivo da VM no Cluster Manager usando as configurações mais recentes, execute este comando:
/var/qps/install/current/scripts/build/build_svn.sh
Etapa 4. Para implantar a VM lb01, execute um destes procedimentos:
No OpenStack, use o modelo HEAT ou o comando Nova para recriar a VM. Para obter mais informações, consulte o Guia de Instalação do CPS para OpenStack.
Para reimplantar a VM do Servidor de Políticas (QNS)
Etapa 1. Faça login na VM do Cluster Manager como o usuário raiz.
Etapa 2. Importe os dados de configuração do Policy Builder de backup no Cluster Manager, como mostrado neste exemplo:
config_br.py -a import --users /mnt/backup/qns_backup_27102016.tar.gz
Etapa 3. Para gerar os arquivos de arquivo da VM no Cluster Manager usando as configurações mais recentes, execute este comando:
/var/qps/install/current/scripts/build/build_svn.sh
Etapa 4 Para implantar a VM qns, execute um destes procedimentos:
No OpenStack, use o modelo HEAT ou o comando Nova para recriar a VM. Para obter mais informações, consulte o Guia de instalação do CPS para OpenStack
Procedimento geral para restauração de banco de dados
Etapa 1. Execute este comando para restaurar o banco de dados:
config_br.py –a import --mongo-all /mnt/backup/backup_$date.tar.gz where $date is the timestamp when the export was made.
Por exemplo,
config_br.py –a import --mongo-all /mnt/backup/backup_27092016.tgz
Etapa 2. Faça login no banco de dados e verifique se ele está em execução e está acessível:
1. Faça login no gerenciador de sessões:
mongo --host sessionmgr01 --port $port
onde $port é o número da porta do banco de dados a ser verificado. Por exemplo, 27718 é a porta de saldo padrão.
2. Exiba o banco de dados executando o seguinte comando:
show dbs
3. Mude o shell mongo para o banco de dados executando o seguinte comando:
use $db
onde $db é um nome de banco de dados exibido no comando anterior.
O comando use comuta o shell mongo para esse banco de dados.
Por exemplo,
use balance_mgmt
4. Para exibir as coleções, execute este comando:
show collections
5. Para exibir o número de registros na coleção, execute este comando:
db.$collection.count() For example, db.account.count()
O exemplo acima mostrará o número de registros na coleção "conta" no banco de dados Saldo (balance_mgmt).
Restauração do repositório de subversão
Para restaurar os Dados de Configuração do Policy Builder a partir de um backup, execute o seguinte comando:
config_br.py –a import --svn /mnt/backup/backup_$date.tgz where, $date is the date when the cron created the backup file.
Restaurar painel do Grafana
Você pode restaurar o painel do Grafana usando o seguinte comando:
config_br.py -a import --grafanadb /mnt/backup/
Validar a restauração
Depois de restaurar os dados, verifique o sistema em funcionamento por meio deste comando:
/var/qps/bin/diag/diagnostics.sh
Quando o ESC não inicia a VM
- Em alguns casos, o ESC falha ao iniciar a VM devido a um estado inesperado. Uma solução alternativa é executar um switchover ESC reinicializando o ESC mestre. O switchover do ESC leva aproximadamente um minuto. Execute health.sh no novo ESC mestre para verificar se ele está ativado. Quando o ESC se tornar Master, o ESC poderá corrigir o estado da VM e iniciar a VM. Como essa operação está agendada, você deve aguardar de 5 a 7 minutos para que seja concluída.
- Você pode monitorar /var/log/esc/yangesc.log e /var/log/esc/escmanager.log. Se você NÃO vir a VM sendo recuperada após 5 a 7 minutos, o usuário precisaria ir e fazer a recuperação manual das VMs afetadas.
- Se o cluster estiver completamente indisponível e somente o ESC estiver acessível, a restauração deverá ser executada a partir dos backups mais recentes que são obtidos dos backups agendados feitos por meio do Cronjobs. O procedimento de recuperação continua a ser o mencionado no MOP.
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)