Introducción

Este documento describe los pasos requeridos a de reserva y el Restore una máquina virtual (VM) en que los host llaman una red virtual puesta Ultra-M CP funciona (VNFs).

Antecedentes

Ultra-M es una solución móvil virtualizada preembalada y validada de la base del paquete diseñada para simplificar el despliegue de VNFs. La solución de Ultra-M consiste en estos tipos de la máquina virtual (VM):

• El elástico mantiene el regulador (el ESC)
• Habitación de la directiva de Cisco (CP)

La arquitectura de alto nivel de Ultra-M y los componentes implicados están tal y como se muestra en de esta imagen.

Note: Ultra la versión M 5.1.x se considera para definir los procedimientos en este documento. Este documento se piensa para el personal de Cisco que es familiar con la plataforma de Cisco Ultra-M.

Abreviaturas

VNF	Función de la red virtual
ESC	Regulador elástico del servicio
FREGONA	Método de procedimiento
OSD	Discos del almacenamiento del objeto
HDD	Unidad de disco duro
SSD	Unidad de estado sólido
VIM	Administrador virtual de la infraestructura
VM	Máquina virtual
UUID	Universal Identificador único

Procedimiento para backup

Respaldo OSPD

1. Marque el estatus del stack de OpenStack y de la lista del nodo.

[stack@director ~]$ source stackrc 
[stack@director ~]$ openstack stack list --nested
[stack@director ~]$ ironic node-list
[stack@director ~]$ nova list

2. Marque si todos los servicios del undercloud están en cargado, estatus activo y corriente del nodo OSP-D. 

[stack@director ~]$ systemctl list-units "openstack*" "neutron*" "openvswitch*"

UNIT                                       LOAD   ACTIVE SUB     DESCRIPTION

neutron-dhcp-agent.service                 loaded active running OpenStack Neutron DHCP Agent
neutron-openvswitch-agent.service          loaded active running OpenStack Neutron Open vSwitch Agent
neutron-ovs-cleanup.service                loaded active exited  OpenStack Neutron Open vSwitch Cleanup Utility
neutron-server.service                     loaded active running OpenStack Neutron Server
openstack-aodh-evaluator.service           loaded active running OpenStack Alarm evaluator service
openstack-aodh-listener.service            loaded active running OpenStack Alarm listener service
openstack-aodh-notifier.service            loaded active running OpenStack Alarm notifier service
openstack-ceilometer-central.service       loaded active running OpenStack ceilometer central agent
openstack-ceilometer-collector.service     loaded active running OpenStack ceilometer collection service
openstack-ceilometer-notification.service  loaded active running OpenStack ceilometer notification agent
openstack-glance-api.service               loaded active running OpenStack Image Service (code-named Glance) API server
openstack-glance-registry.service          loaded active running OpenStack Image Service (code-named Glance) Registry server
openstack-heat-api-cfn.service             loaded active running Openstack Heat CFN-compatible API Service
openstack-heat-api.service                 loaded active running OpenStack Heat API Service
openstack-heat-engine.service              loaded active running Openstack Heat Engine Service
openstack-ironic-api.service               loaded active running OpenStack Ironic API service
openstack-ironic-conductor.service         loaded active running OpenStack Ironic Conductor service
openstack-ironic-inspector-dnsmasq.service loaded active running PXE boot dnsmasq service for Ironic Inspector
openstack-ironic-inspector.service         loaded active running Hardware introspection service for OpenStack Ironic
openstack-mistral-api.service              loaded active running Mistral API Server
openstack-mistral-engine.service           loaded active running Mistral Engine Server
openstack-mistral-executor.service         loaded active running Mistral Executor Server
openstack-nova-api.service                 loaded active running OpenStack Nova API Server
openstack-nova-cert.service                loaded active running OpenStack Nova Cert Server
openstack-nova-compute.service             loaded active running OpenStack Nova Compute Server
openstack-nova-conductor.service           loaded active running OpenStack Nova Conductor Server
openstack-nova-scheduler.service           loaded active running OpenStack Nova Scheduler Server
openstack-swift-account-reaper.service     loaded active running OpenStack Object Storage (swift) - Account Reaper
openstack-swift-account.service            loaded active running OpenStack Object Storage (swift) - Account Server
openstack-swift-container-updater.service  loaded active running OpenStack Object Storage (swift) - Container Updater
openstack-swift-container.service          loaded active running OpenStack Object Storage (swift) - Container Server
openstack-swift-object-updater.service     loaded active running OpenStack Object Storage (swift) - Object Updater
openstack-swift-object.service             loaded active running OpenStack Object Storage (swift) - Object Server
openstack-swift-proxy.service              loaded active running OpenStack Object Storage (swift) - Proxy Server
openstack-zaqar.service                    loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server
openstack-zaqar@1.service                  loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server Instance 1
openvswitch.service                        loaded active exited  Open vSwitch

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

37 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

3. Confirme que usted tiene suficiente espacio en disco disponible antes de que usted realice el proceso de backup. Se espera que este tarball sea por lo menos 3.5 GB.

[stack@director ~]$df -h

4. Ejecute estos comandos como el respaldo del usuario raíz los datos del nodo del undercloud a un archivo nombrado el [timestamp] .tar.gz del undercloud-respaldo y transferencia él al servidor de backup.

[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql
[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql 
/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack
tar: Removing leading `/' from member names

Respaldo ESC

1. El ESC, a su vez, saca a colación la función de la red virtual (VNF) obrando recíprocamente al VIM.

2. El ESC tiene Redundancia de 1:1 en la solución de Ultra-M. Hay 2 ESC VM desplegados y apoya el solo error en Ultra-M. es decir recupere el sistema si hay un solo error en el sistema.

Note: Si hay error más que solo, no se soporta y puede requerir el despliegue del sistema.

Detalles de reserva ESC:

• Configuración corriente
• ConfD BDC DB
• Registros ESC
• Configuración de syslog

3. La frecuencia del respaldo ESC DB es difícil y necesita ser dirigida cuidadosamente pues el ESC monitorea y mantiene las diversas máquinas de estado para diverso VNF VM desplegadas. Se aconseja que estos respaldos están realizados después de las actividades siguientes en VNF/POD/Site dado

4. Verifique la salud del ESC es bueno con el script de health.sh.

[root@auto-test-vnfm1-esc-0 admin]# escadm status
0 ESC status=0 ESC Master Healthy

[root@auto-test-vnfm1-esc-0 admin]# health.sh
esc ui is disabled -- skipping status check
esc_monitor start/running, process 836
esc_mona is up and running ...
vimmanager start/running, process 2741
vimmanager start/running, process 2741
esc_confd is started
tomcat6 (pid 2907) is running...                           [  OK  ]
postgresql-9.4 (pid  2660) is running...
ESC service is running...
Active VIM = OPENSTACK
ESC Operation Mode=OPERATION

/opt/cisco/esc/esc_database is a mountpoint

============== ESC HA (MASTER) with DRBD =================

DRBD_ROLE_CHECK=0
MNT_ESC_DATABSE_CHECK=0
VIMMANAGER_RET=0
ESC_CHECK=0
STORAGE_CHECK=0
ESC_SERVICE_RET=0
MONA_RET=0
ESC_MONITOR_RET=0

=======================================

ESC HEALTH PASSED

5. Tome el respaldo de la configuración y de la transferencia corrientes el archivo al servidor de backup.

[root@auto-test-vnfm1-esc-0 admin]# /opt/cisco/esc/confd/bin/confd_cli -u admin -C

admin connected from 127.0.0.1 using console on auto-test-vnfm1-esc-0.novalocal
auto-test-vnfm1-esc-0# show running-config | save /tmp/running-esc-12202017.cfg
auto-test-vnfm1-esc-0#exit

[root@auto-test-vnfm1-esc-0 admin]# ll /tmp/running-esc-12202017.cfg
-rw-------. 1 tomcat tomcat 25569 Dec 20 21:37 /tmp/running-esc-12202017.cfg

 Base de datos de reserva ESC

1. El registro en ESC VM y ejecuta el siguiente comando antes de que usted tome el respaldo.

[admin@esc ~]# sudo bash
[root@esc ~]# cp /opt/cisco/esc/esc-scripts/esc_dbtool.py /opt/cisco/esc/esc-scripts/esc_dbtool.py.bkup
[root@esc esc-scripts]# sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump," /opt/cisco/esc/esc-scripts/esc_dbtool.py

#Set ESC to mainenance mode
[root@esc esc-scripts]# escadm op_mode set --mode=maintenance

2. Marque el modo ESC y asegúrese que está en el modo de mantenimiento.

[root@esc esc-scripts]# escadm op_mode show

3. Base de datos de backup usando la herramienta del restore del backup de la base de datos disponible en el ESC.

[root@esc scripts]# sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup --file  scp://<username>:<password>@<backup_vm_ip>:<filename>

4. Fije el ESC de nuevo al modo de funcionamiento y confirme el modo.

[root@esc scripts]# escadm op_mode set --mode=operation

[root@esc scripts]# escadm op_mode show 

5. Navegue al directorio de los scripts y recoja los registros.

[root@esc scripts]# /opt/cisco/esc/esc-scripts

sudo ./collect_esc_log.sh

 6. Para crear una foto del ESC primero apague el ESC.

shutdown -r now

7. Del crearte OSPD una foto de la imagen

nova image-create --poll esc1 esc_snapshot_27aug2018

8. Verifique que la foto esté creada

openstack image list | grep esc_snapshot_27aug2018

9. Comience el ESC de OSPD

nova start esc1 

10. Relance el mismo procedimiento en ESC espera VM y transferencia los registros al servidor de backup

11. Recoja el respaldo de la configuración de syslog en ambo el ESC VMS y transferencia ellos al servidor de backup

[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf

  

CP de reserva

1. Cree un respaldo del administrador de clúster CP

Utilice este comando para ver los casos de la Nova y observar el nombre del caso del administrador de clúster VM:

nova list

Pare el Cluman del ESC

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP <vm-name>

Paso 2. Verifique al administrador de clúster en el estado del CIERRE.

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 la foto de la Nova tal y como se muestra en del siguiente comando:

nova image-create --poll <cluman-vm-name> <snapshot-name>

Note: Asegúrese de que usted tenga bastante espacio en disco para la foto.

Importante - En caso de que si el VM llega a ser inalcanzable después de la creación de la foto, marque el estatus del VM usando el comando list de la Nova. Si está en el estado del “CIERRE”, usted necesita comenzar el VM manualmente.

Paso 4. Vea la lista de imágenes con el siguiente comando: cuadro 1 de la lista de imágenes de la Nova: Salida de ejemplo

Paso 5. Cuando se crea una foto, la imagen de la foto se salva en el vistazo de OpenStack. Para salvar la foto en los datos remotos salve, descargue la foto y la transferencia 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. Enumere las imágenes descargadas tal y como se muestra en del siguiente comando:

ls —ltr *snapshot*

Example output: -rw-r--r--. 1 root root 10429595648 Aug 16 02:39 snapshot.raw

Paso 7. Salve la foto del administrador de clúster VM para restablecer en el futuro.

2. Respaldo 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 del crontab - l si algún otro respaldo es necesario

Transferencia todos los respaldos al OSPD /home/stack/CPS_BACKUP

3. Archivo de reserva del yaml del master ESC

/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u <admin-user> -p <admin-password> --get-config > /home/admin/ESC_config.xml

Transferencia el archivo en OSPD /home/stack/CPS_BACKUP

4. Crontab de reserva - l entradas

Cree un archivo txt con el crontab - l y ftp él al lugar remoto (en OSPD /home/stack/CPS_BACKUP)

5. Tome un respaldo de los archivos de la ruta del cliente LB y PCRF

Collect and scp the below conifgurations from both LBs and Pcrfclients
route -n /etc/sysconfig/network-script/route-*

Procedimiento de restaurar

Recuperación OSPD

Se realiza el Procedimiento de recuperación OSPD basó en las suposiciones siguientes

1. El respaldo OSPD es disponible desde servidor viejo OSPD.

2. La recuperación OSPD será hecha en el nuevo servidor que es el reemplazo del servidor viejo OSPD en el sistema.

Recuperación ESC

1. El ESC VM es recuperable si el VM está en el error o el estado de cierre normal hace la reinicialización dura para traer para arriba del VM afectado. Ejecute estos pasos para recuperar el ESC.

2. Identifique el VM que está en el ERROR o el estado de cierre normal, duro-reinicialización una vez identificada el ESC VM. En este ejemplo, usted está reiniciando auto-test-vnfm1-ESC-0.                                   

[root@tb1-baremetal scripts]# nova list | grep auto-test-vnfm1-ESC-

| f03e3cac-a78a-439f-952b-045aea5b0d2c | auto-test-vnfm1-ESC-0                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.11; auto-testautovnf1-uas-management=172.57.11.3                                                                                      |
| 79498e0d-0569-4854-a902-012276740bce | auto-test-vnfm1-ESC-1                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.15; auto-testautovnf1-uas-management=172.57.11.5                                                                                      |

[root@tb1-baremetal scripts]# [root@tb1-baremetal scripts]# nova reboot --hard f03e3cac-a78a-439f-952b-045aea5b0d2c\
Request to reboot server <Server: auto-test-vnfm1-ESC-0> has been accepted.

[root@tb1-baremetal scripts]#

3. Si el ESC VM se borra y necesita ser traído para arriba otra vez. Siga debajo de la secuencia de pasos

[stack@pod1-ospd scripts]$ nova list |grep ESC-1
| c566efbf-1274-4588-a2d8-0682e17b0d41 | vnf1-ESC-ESC-1                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.4                                                                                                 |

[stack@pod1-ospd scripts]$ nova delete vnf1-ESC-ESC-1
Request to delete server vnf1-ESC-ESC-1 has been accepted.                                                 

4. Si el ESC VM es irrecuperable y requiere el restore de la base de datos, restablezca por favor la base de datos del respaldo previamente tomado.

5. Para el restore de la base de datos ESC, tenemos que asegurarnos que el servicio salida esté parado antes de restablecer la base de datos; Para ESC HA, primero y después ejecute en el VM secundario el VM primario.

# service keepalived stop

6. Marque el estatus del servicio ESC y asegúrese que todo está parada en los VM primarios y secundarios para el HA.

# escadm status

7. Ejecute el script para restablecer la base de datos. Como parte de la restauración del DB al caso creado recientemente ESC, la herramienta también promoverá uno de los casos para ser un ESC primario, monta su carpeta DB al dispositivo del drbd y comenzará la base de datos de PostgreSQL.

# /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://<username>:<password>@<backup_vm_ip>:<filename>

8. Recomience el servicio ESC para completar el restore de la base de datos. Para el HA ejecute en ambos VM, recomienzan el servicio keepalived.

# service keepalived start

9. Una vez que el VM se restablece con éxito y el ejecutarse; asegúrese que toda la configuración específica del Syslog esté restablecida del respaldo sabido acertado anterior. asegúrese que esté restablecida en todo el ESC VM.

[admin@auto-test-vnfm2-esc-1 ~]$
[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf

10. Si el ESC necesita ser reconstruido del uso de la foto OSPD este comando con el uso de la foto tomado durante el respaldo.

nova rebuild --poll --name esc_snapshot_27aug2018 esc1

11. Marque el estatus del ESC después de que la reconstrucción sea completa 

nova list --fileds name,host,status,networks | grep esc

12. Marque la salud ESC con el comando abajo

health.sh

Copy Datamodel to a backup file
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata > /tmp/esc_opdata_`date +%Y%m%d%H%M%S`.txt

Cuando el ESC no puede comenzar el VM

• En algunos casos, el ESC no podrá comenzar el VM debido a un estado inesperado. Una solución alternativa es realizar un intercambio ESC reiniciando al master ESC. El intercambio ESC tardará alrededor de un minuto.  Ejecute health.sh en el nuevo master ESC para verificarlo está para arriba. Cuando el ESC llega a ser principal, el ESC puede reparar el estado VM y comenzar el VM. Puesto que se programa esta operación, usted debe esperar 5-7 minutos ella para completar. 

• Usted puede monitorear /var/log/esc/yangesc.log y /var/log/esc/escmanager.log. Si usted no ve el VM el conseguir recuperado después de 5-7 minutos, el usuario necesitaría ir hacer la recuperación manual del VM afectado.

• Una vez que el VM se restablece con éxito y el ejecutarse; asegúrese que toda la configuración específica del Syslog esté restablecida del respaldo sabido acertado anterior. Asegúrese que esté restablecida en todo el ESC VM

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 CP

Administrador de clúster VM del Restore en OpenStack

Paso 1 Copie la foto del administrador de clúster VM a la cuchilla del regulador tal y como se muestra en del siguiente comando:

ls —ltr *snapshot*

Example output: -rw-r--r--. 1 root root 10429595648 Aug 16 02:39 snapshot.raw

Paso 2 Cargue la imagen de la foto a OpenStack de Datastore:

  

glance image-create --name --file --disk-format qcow2 --container-format bare

Paso 3 Verifique si la foto esté cargada con un comando de Nova tal y como se muestra en del siguiente ejemplo:

nova image-list

Figura 2: Salida de ejemplo

Paso 4 Dependiendo de si existe el administrador de clúster VM o no, usted puede elegir crear el cluman o reconstruir el cluman:

• Si no existe el caso del administrador de clúster VM, cree el Cluman VM con un comando del calor o de Nova tal y como se muestra en del siguiente ejemplo:

Cree el Cluman VM con el ESC 

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/<original_xml_filename>

El cluster PCRF spawn/generará con la ayuda del comando antedicho, y después restablece las configuraciones del administrador de clúster de los respaldos tomados con el restore config_br.py, mongorestore del respaldo admitido volcado

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 el caso del administrador de clúster VM, utilice un comando de la reconstrucción de la Nova de reconstruir el caso de Cluman VM con la foto cargada como se muestra:

nova rebuild <instance_name> <snapshot_image_name>

Por ejemplo:

nova rebuild cps-cluman-5f3tujqvbi67 cluman_snapshot

Paso 5 Enumere todos los casos como se muestra y verifiquelos que el nuevo caso del administrador de clúster está creado y el ejecutarse:

nova list

Cuadro 3. salida de ejemplo

Restablezca las últimas correcciones en el 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

Note: Los componentes del software deben toda la visualización no monitoreada como el estado actual.

8.       Update the qns VMs with the new software using reinit.sh script:  /var/qps/install/current/scripts/upgrade/reinit.sh
9.       Restart all software components on the target VMs:  runonall.sh sudo monit start all
10.     Verify that the component is updated, run:  about.sh

Restablezca el Cronjobs

1. Mueva el archivo con copia de seguridad desde OSPD al Cluman/Pcrfclient01.

2. Funcione con el comando de activar el cronjob del respaldo.

       

#crontab Cron-backup

3. Marque si los cronjobs han sido activados por el comando abajo.

     

#crontab -l 

      

Restablezca los VM individuales en el cluster

Para cambiar de frente el pcrfclient01 VM: 

Paso 1 Login al administrador de clúster VM como el usuario raíz.

Paso 2 Observe el UUID del repositorio SVN usando el siguiente comando:

svn info http://pcrfclient02/repos | grep UUID

El comando hará salir el UUID del repositorio.

Por ejemplo: Repositorio UUID: ea50bbd2-5726-46b8-b807-10f4a7424f0e

Paso 3 Importe los datos de configuración de reserva del constructor de la directiva en el administrador de clúster, tal y como se muestra en del siguiente ejemplo:

config_br.py -a import --etc-oam --svn --stats --grafanadb --auth-htpasswd --users /mnt/backup/oam_backup_27102016.tar.gz

Note: Mucho deploymentsrun una tarea cron que sostiene el respaldo del repositorio de los datos de configuración regularly.SeeSubversion, para más detalles.

Paso 4 Para generar los archivos VM en el administrador de clúster que usa configuraciones más posteriores, ejecute el siguiente comando:

/var/qps/install/current/scripts/build/build_svn.sh

  

Paso 5 Para desplegar el pcrfclient01 VM, realice uno del siguiente:

En OpenStack, utilice la plantilla del CALOR o el comando de Nova de reconstruir el VM. Para más información, vea la guía de instalación CP para OpenStack.

Paso 6 Re-establishSVN sincronización maestro/satélite entre el pcrfclient01 y el pcrfclient02 con pcrfclient01 como el master ejecutando la serie siguiente de comandos.

Si el SVN se sincroniza ya, no publique estos comandos.

Para marcar si el SVN está adentro sincronice, funcione con el siguiente comando de pcrfclient02.

Si se vuelve un valor, después el SVN está ya adentro sincroniza:

/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos

Ejecute los siguientes comandos 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

Paso 7 Si pcrfclient01 es también el árbitro VM, después ejecute los pasos siguientes:

a) Cree los scripts partida/parada del mongodb basados en la configuración del sistema. No todas las implementaciones tienen todas estas bases de datos configuradas.

Note: Refiera a /etc/broadhop/mongoConfig.cfg para determinar que las bases de datos necesiten ser 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

b) Comience el proceso del mongo:

/usr/bin/systemctl start sessionmgr-XXXXX

c) Espere al árbitro para comenzar, después ejecute diagnostics.sh --get_replica_status para marcar la salud del conjunto de la reproducción.

Para cambiar de frente el pcrfclient02 VM:

 Paso 1 Login al administrador de clúster VM como el usuario raíz

Paso 2 Para generar los archivos VM en el administrador de clúster que usa configuraciones más posteriores, ejecute el siguiente comando:

/var/qps/install/current/scripts/build/build_svn.sh

Paso 3 Para desplegar el pcrfclient02 VM, realice uno del siguiente:
En OpenStack, utilice la plantilla del CALOR o el comando de Nova de reconstruir el VM. Para más información, vea la guía de instalación CP para OpenStack.

Paso 4 Secure Shell al pcrfclient01:

ssh pcrfclient01

Paso 5 Ejecute el script siguiente para recuperar el repos SVN de pcrfclient01:

/var/qps/bin/support/recover_svn_sync.sh

Para cambiar de frente un sessionmgr VM:

Paso 1 Login al administrador de clúster VM como el usuario raíz

Paso 2 Para desplegar el sessionmgr VM y substituir el VM fallado o corrupto, realice uno del siguiente:

En OpenStack, utilice la plantilla del CALOR o el comando de Nova de reconstruir el VM. Para más información, vea la guía de instalación CP para OpenStack

Paso 3 Cree los scripts partida/parada del mongodb basados en la configuración del sistema.

No todas las implementaciones tienen todas estas bases de datos configuradas. Refiera a /etc/broadhop/mongoConfig.cfg para determinar que las bases de datos necesiten ser 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

Paso 4 El Secure Shell al sessionmgr VM y comienza el proceso del mongo:

ssh sessionmgrXX

/usr/bin/systemctl start sessionmgr-XXXXX

Paso 5 La espera para que los miembros comiencen y para que los miembros secundarios sincronicen, entonces ejecuta diagnostics.sh --get_replica_status para marcar la salud de la base de datos.

Paso 6 Para restablecer la base de datos del administrador de sesión, utilice uno de los comandos del siguiente ejemplo dependiendo de con si el respaldo fue realizado --mongo-todo o --opción del 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 cambiar de frente al director de la directiva (balanceador) de la carga VM:

 Paso 1 Login al administrador de clúster VM como el usuario raíz.

Paso 2 Para importar los datos de configuración de reserva del constructor de la directiva en el administrador de clúster, ejecute el siguiente comando:

config_br.py -a import --network --haproxy --users /mnt/backup/lb_backup_27102016.tar.gz

Paso 3 Para generar los archivos VM en el administrador de clúster que usa configuraciones más posteriores, ejecute el siguiente comando:

/var/qps/install/current/scripts/build/build_svn.sh

Paso 4 Para desplegar el lb01 VM, realice uno del siguiente:

En OpenStack, utilice la plantilla del CALOR o el comando de Nova de reconstruir el VM. Para más información, vea la guía de instalación CP para OpenStack.

Para cambiar de frente al servidor de políticas (QNS) VM:

 Paso 1 Login al administrador de clúster VM como el usuario raíz.

Paso 2 Importe los datos de configuración de reserva del constructor de la directiva en el administrador de clúster, tal y como se muestra en del siguiente ejemplo:

config_br.py -a import --users /mnt/backup/qns_backup_27102016.tar.gz

Paso 3 Para generar los archivos VM en el administrador de clúster que usa configuraciones más posteriores, ejecute el siguiente comando:

/var/qps/install/current/scripts/build/build_svn.sh

Paso 4 Para desplegar los qns VM, realice uno del siguiente:
En OpenStack, utilice la plantilla del CALOR o el comando de Nova de reconstruir el VM. Para más información, vea la guía de instalación CP para OpenStack 

Procedimiento general para el Restore de la base de datos

Paso 1 Ejecute el siguiente comando de restablecer 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 a la base de datos y verifique si se está ejecutando y es accesible:

1. Registro en el administrador de sesión:

mongo --host sessionmgr01 --port $port

donde está el número del puerto $port de la base de datos a marcar. Por ejemplo, 27718 es el puerto predeterminado de la balanza.

2. Visualice la base de datos ejecutando el siguiente comando:

show dbs

3. Conmute el shell del mongo a la base de datos ejecutando el siguiente comando:

use $db

donde está un nombre de la base de datos $db visualizado en el anterior ordene.

Los switches del comando del “uso” el shell del mongo a esa base de datos.

Por ejemplo,

use balance_mgmt

4. Para visualizar las colecciones, ejecute el siguiente comando:

show collections

5. Para visualizar la cantidad de registros en la colección, ejecute el siguiente comando:

db.$collection.count()
 
For example, db.account.count()

El ejemplo antedicho mostrará la cantidad de registros en la colección “cuenta” en la base de datos de la balanza (balance_mgmt).

Restore del repositorio de la subversión

Para restablecer los datos de configuración del constructor de la directiva de un respaldo, 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. 

Restablezca el panel de Grafana

Usted puede restablecer el panel de Grafana usando el siguiente comando:

config_br.py -a import --grafanadb /mnt/backup/

Validar el Restore

Después de restablecer los datos, verifique el sistema en funcionamiento ejecutando el siguiente comando:

/var/qps/bin/diag/diagnostics.sh