Copia de seguridad y recuperación - Recuperación de clúster completa - CPS
Contenido
Introducción
Este documento describe los pasos necesarios para recuperar un clúster de CPS completo en una configuración Ultra-M que aloja funciones de red virtual (VNF) de CPS.
Antecedentes
Ultra-M es una solución de núcleo de paquetes móviles virtualizada validada y empaquetada previamente diseñada para simplificar la implementación de VNF. La solución Ultra-M consta de los siguientes tipos de máquinas virtuales (VM):
- Controlador de servicios elásticos (ESC)
- Cisco Policy Suite (CPS)
La arquitectura de alto nivel de Ultra-M y los componentes involucrados se ilustran en esta imagen:
Este documento está dirigido al personal de Cisco familiarizado con la plataforma Cisco Ultra-M.
Abreviaturas
| VNF | Función de red virtual |
| ESC | Controlador de servicio elástico |
| MOP | Método de procedimiento |
| OSD | Discos de almacenamiento de objetos |
| HDD | Unidad de disco duro |
| SSD | Unidad de estado sólido |
| VIM | Administrador de infraestructura virtual |
| VM | Máquina virtual |
| UUID | Identificador único universal |
Suposición
Para este procedimiento, se supone que solo se recuperará el clúster CPS y que todos los componentes a nivel de OpenStack estarán operativos, incluido el ESC
Procedimiento de restauración
Cuando ESC no puede iniciar VM:
- En algunos casos, ESC no puede iniciar la VM debido a un estado inesperado. Una solución alternativa es realizar un switchover ESC reiniciando el ESC maestro. El switchover ESC tarda aproximadamente un minuto. Ejecute health.sh en el nuevo Master ESC para verificar que está activo. Cuando ESC se convierte en Master, ESC puede corregir el estado de la VM e iniciar la VM. Puesto que esta operación está programada, debe esperar de 5 a 7 minutos para que se complete.
- Puede supervisar /var/log/esc/yangesc.log y /var/log/esc/escmanager.log. Si NO ve que se recupera la máquina virtual después de 5-7 minutos, el usuario tendría que ir y realizar la recuperación manual de las máquinas virtuales afectadas.
- Una vez que la máquina virtual se haya restaurado y ejecutado correctamente; asegúrese de que toda la configuración específica de syslog se restaura desde la copia de seguridad conocida anterior exitosa. Asegúrese de que se restaura en todas las VM 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
Recuperación de CPS
1. Creación de una Copia de Seguridad de CPS Cluster-Manager
Paso 1. Utilice el siguiente comando para ver las instancias nova y observe el nombre de la instancia de VM del administrador de clúster:
nova list
Pare el ESC de Cluman.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP
Paso 2. Verifique el Cluster Manager en el estado SHUTOFF.
admin@esc1 ~]$ /opt/cisco/esc/confd/bin/confd_cli admin@esc1> show esc_datamodel opdata tenants tenant Core deployments * state_machine
Paso 3. Cree una imagen de instantánea nova como se muestra en este comando:
nova image-create --poll
Importante: en caso de que la VM se vuelva inalcanzable después de la creación de la instantánea, verifique el estado de la VM mediante el comando nova list. Si se encuentra en estado "SHUTOFF", debe iniciar la VM manualmente.
Paso 4. Vea la lista de imágenes con el siguiente comando: nova image-list Figura 1: Ejemplo de salida
Paso 5. Cuando se crea una instantánea, la imagen de instantánea se almacena en OpenStack Glance. Para almacenar la instantánea en un almacén de datos remoto, descargue la instantánea y transfiera el archivo en OSPD a ( /home/stack/CPS_BACKUP )
Para descargar la imagen, utilice el siguiente comando en OpenStack:
glance image-download –-file For example: glance image-download –-file snapshot.raw 2bbfb51c-cd05-4b7c-ad77-8362d76578db
Paso 6. Enumera las imágenes descargadas como se muestra en el siguiente comando:
ls —ltr *snapshot*
Example output: -rw-r--r--. 1 root root 10429595648 Aug 16 02:39 snapshot.raw
Paso 7. Almacene la instantánea de la VM Cluster Manager para restaurarla en el futuro.
2. Realice una copia de seguridad de la configuración y la base de datos.
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 desde crontab -l si se necesita otra copia de seguridad
Transferir todas las copias de seguridad a OSPD /home/stack/CPS_BACKUP
3. Copia de seguridad del archivo de calendario desde 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 el archivo en OSPD /home/stack/CPS_BACKUP
4. Copia de seguridad de las entradas crontab -l
Cree un archivo txt con crontab -l y ftp en la ubicación remota ( en OSPD /home/stack/CPS_BACKUP )
5. Realice una copia de seguridad de los archivos de ruta desde el cliente LB y PCRF.
Collect and scp the below conifgurations from both LBs and Pcrfclients route -n /etc/sysconfig/network-script/route-*
Restaurar la VM del Cluster Manager en OpenStack
Paso 1. Copie la instantánea de VM del administrador de clúster en el servidor blade del controlador como se muestra en este comando:
ls —ltr *snapshot*
Ejemplo de salida: -rw-r—r—. 1 root 10429595648 16 ago 02:39 snapshot.raw
Paso 2. Cargue la imagen de instantánea en OpenStack desde el almacén de datos:
glance image-create --name --file --disk-format qcow2 --container-format bare
Paso 3. Verifique si la instantánea se carga con un comando Nova como se muestra en este ejemplo:
nova image-list
Figura 2: Ejemplo de salida
Paso 4. Dependiendo de si la VM del administrador de clúster existe o no, puede elegir crear el cluman o reconstruir el cluman:
Si la instancia de la VM Cluster Manager no existe, cree la VM Cluman con un comando Heat o Nova como se muestra en el siguiente ejemplo:
Creación de la VM Cluman con ESC
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/
El clúster de PCRF se producirá con la ayuda del comando anterior y, a continuación, restaurará las configuraciones del administrador de clúster a partir de las copias de seguridad tomadas con la restauración config_br.py, mongorestore from dump tomado en 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"
Si existe la instancia de la VM Cluster Manager, utilice un comando nova build para reconstruir la instancia de la VM de Cluman con la instantánea cargada como se muestra:
nova rebuild
Por ejemplo: nova build cps-cluman-5f3tujqvbi67 cluman_snapshot
Paso 5 Enumera todas las instancias como se muestra y verifique que se haya creado y ejecutado la nueva instancia del administrador del clúster:
lista de nova
Figura 3: Ejemplo de salida
Restaurar los últimos parches del 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
Restauración de Cronworks
- Mueva el archivo de copia de seguridad de OSPD a Cluman/Pcrfclient01
- Ejecute el comando para activar el cronjob desde la copia de seguridad
#crontab Cron-backup - Verifique si los cronworks han sido activados por el siguiente comando
#crontab -l
Restauración de VM individuales en el clúster
Para volver a implementar la VM pcrfclient01
Paso 1. Inicie sesión en la VM de Cluster Manager como usuario raíz.
Paso 2. Observe el UUID del repositorio SVN utilizando el siguiente comando:
svn info http://pcrfclient02/repos | grep UUID
El comando emitirá el UUID del repositorio.
Por ejemplo: UUID del repositorio: ea50bbd2-5726-46b8-b807-10f4a7424f0e
Paso 3. Importe los datos de configuración del creador de políticas de copia de seguridad en el Administrador de clústeres, como se muestra en el ejemplo siguiente:
config_br.py -a import --etc-oam --svn --stats --grafanadb --auth-htpasswd --users /mnt/backup/oam_backup_27102016.tar.gz
Paso 4. Para generar los archivos de VM archive en el Cluster Manager utilizando las últimas configuraciones, ejecute el siguiente comando:
/var/qps/install/current/scripts/build/build_svn.sh
Paso 5. Para implementar la VM pcrfclient01, realice una de las siguientes acciones:
En OpenStack, utilice la plantilla HEAT o el comando Nova para volver a crear la máquina virtual. Para obtener más información, consulte Guía de instalación de CPS para OpenStack.
Paso 6. Vuelva a establecer la sincronización maestra/esclava SVN entre pcrfclient01 y pcrfclient02 con pcrfclient01 como maestro mientras ejecuta estos comandos.
Si SVN ya está sincronizado, no ejecute estos comandos.
Para verificar si SVN está sincronizado, ejecute este comando desde pcrfclient02.
Si se devuelve un valor, el SVN ya está sincronizado:
/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos
Ejecute estos comandos desde 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
Paso 7. Si pcrfclient01 es también la VM árbitro, ejecute estos pasos:
1. Cree los scripts mongodb start/stop basándose en la configuración del sistema. No todas las implementaciones tienen todas estas bases de datos configuradas.
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. Iniciar el proceso mongo:
/usr/bin/systemctl start sessionmgr-XXXXX
3. Espere a que se inicie el árbitro y, a continuación, ejecute diagnostics.sh —get_réplica_status para comprobar el estado del conjunto de réplicas.
Para volver a implementar la VM pcrfclient02
Paso 1. Inicie sesión en la VM de Cluster Manager como usuario raíz.
Paso 2. Para generar los archivos de VM archive en el Cluster Manager utilizando las últimas configuraciones, ejecute este comando:
/var/qps/install/current/scripts/build/build_svn.sh
Paso 3 Para implementar la VM pcrfclient02, realice una de las siguientes acciones:
En OpenStack, utilice la plantilla HEAT o el comando Nova para volver a crear la máquina virtual. Para obtener más información, consulte Guía de instalación de CPS para OpenStack.
Paso 4 Secure Shell al pcrfclient01:
ssh pcrfclient01
Paso 5 Ejecute este script para recuperar los repos SVN de pcrfclient01:
/var/qps/bin/support/recover_svn_sync.sh
Para volver a implementar una VM de sessionmgr
Paso 1. Inicie sesión en la máquina virtual Cluster Manager como usuario raíz
Paso 2. Para implementar la máquina virtual sessionmgr y reemplazar la máquina virtual fallida o corrupta, realice una de estas acciones:
En OpenStack, utilice la plantilla HEAT o el comando Nova para volver a crear la máquina virtual. Para obtener más información, consulte Guía de instalación de CPS para OpenStack
Paso 3. Cree los scripts mongodb start/stop basándose en la configuración del sistema.
No todas las implementaciones tienen todas estas bases de datos configuradas. Consulte /etc/broadhop/mongoConfig.cfg para determinar qué bases de datos deben configurarse
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
Paso 4. Proteja el shell a la máquina virtual sessionmgr e inicie el proceso mongo:
ssh sessionmgrXX /usr/bin/systemctl start sessionmgr-XXXXX
Paso 5. Espere a que se inicien los miembros y a que se sincronicen los miembros secundarios y, a continuación, ejecute diagnostics.sh —get_réplica_status para comprobar el estado de la base de datos.
Paso 6. Para restaurar la base de datos de Session Manager, utilice uno de los siguientes comandos de ejemplo dependiendo de si la copia de seguridad se realizó con —mongo-all o con la opción —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 volver a implementar la máquina virtual Policy Director (Load Balancer)
Paso 1. Inicie sesión en la VM de Cluster Manager como usuario raíz.
Paso 2. Para importar los datos de configuración del creador de políticas de respaldo en el Administrador de clústeres, ejecute este comando:
config_br.py -a import --network --haproxy --users /mnt/backup/lb_backup_27102016.tar.gz
Paso 3 Para generar los archivos de VM en el Cluster Manager usando las últimas configuraciones, ejecute este comando:
/var/qps/install/current/scripts/build/build_svn.sh
Paso 4. Para implementar la máquina virtual lb01, realice una de estas acciones:
En OpenStack, utilice la plantilla HEAT o el comando Nova para volver a crear la máquina virtual. Para obtener más información, consulte Guía de instalación de CPS para OpenStack.
Para volver a implementar la VM de Policy Server (QNS)
Paso 1. Inicie sesión en la VM de Cluster Manager como usuario raíz.
Paso 2. Importe los datos de configuración del creador de políticas de copia de seguridad en el Administrador de clústeres, como se muestra en este ejemplo:
config_br.py -a import --users /mnt/backup/qns_backup_27102016.tar.gz
Paso 3. Para generar los archivos de VM archive en el Cluster Manager utilizando las últimas configuraciones, ejecute este comando:
/var/qps/install/current/scripts/build/build_svn.sh
Paso 4 Para implementar la VM qns, realice una de estas acciones:
En OpenStack, utilice la plantilla HEAT o el comando Nova para volver a crear la máquina virtual. Para obtener más información, consulte Guía de instalación de CPS para OpenStack
Procedimiento general para restaurar la base de datos
Paso 1. Ejecute este comando para restaurar la base de datos:
config_br.py –a import --mongo-all /mnt/backup/backup_$date.tar.gz where $date is the timestamp when the export was made.
Por ejemplo,
config_br.py –a import --mongo-all /mnt/backup/backup_27092016.tgz
Paso 2. Inicie sesión en la base de datos y verifique si se está ejecutando y si se puede acceder a ella:
1. Inicie sesión en el administrador de sesiones:
mongo --host sessionmgr01 --port $port
donde $port es el número de puerto de la base de datos para verificar. Por ejemplo, 27718 es el puerto de balance predeterminado.
2. Para mostrar la base de datos, ejecute el siguiente comando:
show dbs
3. Cambie el shell mongo a la base de datos ejecutando el siguiente comando:
use $db
donde $db es un nombre de base de datos que se muestra en el comando anterior.
El comando use conmuta el shell mongo a esa base de datos.
Por ejemplo,
use balance_mgmt
4. Para mostrar las colecciones, ejecute este comando:
show collections
5. Para mostrar el número de registros en la colección, ejecute este comando:
db.$collection.count() For example, db.account.count()
El ejemplo anterior mostrará el número de registros en la "cuenta" de la colección en la base de datos Balance (balance_mgmt).
Restauración del repositorio de subversion
Para restaurar los datos de configuración de Policy Builder desde una copia de seguridad, ejecute el siguiente 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 panel de Grafana
Puede restaurar el panel Grafana mediante el siguiente comando:
config_br.py -a import --grafanadb /mnt/backup/
Validar la restauración
Después de restaurar los datos, verifique el sistema en funcionamiento a través de este comando:
/var/qps/bin/diag/diagnostics.sh
Cuando ESC no puede iniciar VM
- En algunos casos, ESC no puede iniciar la VM debido a un estado inesperado. Una solución alternativa es realizar un switchover ESC reiniciando el ESC maestro. El switchover ESC tarda aproximadamente un minuto. Ejecute health.sh en el nuevo Master ESC para verificar que está activo. Cuando ESC se convierte en Master, ESC puede corregir el estado de la VM e iniciar la VM. Puesto que esta operación está programada, debe esperar de 5 a 7 minutos para que se complete.
- Puede supervisar /var/log/esc/yangesc.log y /var/log/esc/escmanager.log. Si NO ve que se recupera la máquina virtual después de 5-7 minutos, el usuario tendría que ir y realizar la recuperación manual de las máquinas virtuales afectadas.
- Si el clúster no está completamente disponible y sólo se puede alcanzar ESC, la restauración se debe realizar desde las últimas copias de seguridad que se toman de las copias de seguridad programadas realizadas a través de Cronjob. El procedimiento de recuperación sigue siendo el mismo que se menciona en la CP.
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)