Contenido

Introducción

Antecedentes

Abreviaturas

Suposición

Procedimiento de restauración

Recuperación de CPS

Restaurar la VM del Cluster Manager en OpenStack

Restauración de Cronworks

Restauración de VM individuales en el clúster

Para volver a implementar la VM pcrfclient01

Para volver a implementar la VM pcrfclient02

Para volver a implementar una VM de sessionmgr

Para volver a implementar la máquina virtual Policy Director (Load Balancer)

Para volver a implementar la VM de Policy Server (QNS)

Procedimiento general para restaurar la base de datos

Restauración del repositorio de subversion

Restaurar panel de Grafana

Validar la restauración

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.

Nota: La versión Ultra M 5.1.x se considera para definir los procedimientos en este documento.

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

Nota: asegúrese de que dispone de suficiente espacio en disco para la instantánea.

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

Nota: Todos los componentes del software deben mostrar No supervisado como estado actual) 8. Actualice las VM de qns con el nuevo software usando el script reinit.sh: /var/qps/install/current/scripts/upgrade/reinit.sh 9. Reinicie todos los componentes de software en las VM de destino: runonall.sh sudo monit start all 10. Verifique que el componente esté actualizado y ejecute: about.sh

Restauración de Cronworks

1. Mueva el archivo de copia de seguridad de OSPD a Cluman/Pcrfclient01

2. Ejecute el comando para activar el cronjob desde la copia de seguridad

#crontab Cron-backup

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

Nota: Muchas implementaciones ejecutan un trabajo cron que realiza copias de seguridad de los datos de configuración de forma regular.ConsulteCopia de seguridad del repositorio de subversión para obtener más detalles.

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.

Nota: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

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.