Introducción
Este documento describe los pasos necesarios para detener el inicio de un servidor informático defectuoso en una configuración Ultra-M que aloja Cisco Policy Suite (CPS) Virtual Network Functions (VNF).
Nota: Se considera la versión Ultra M 5.1.x para definir los procedimientos en este documento. Este documento está dirigido al personal de Cisco que está familiarizado con la plataforma Cisco Ultra-M y detalla los pasos necesarios para llevarse a cabo en el nivel de VNF de OpenStack y CPS en el momento del inicio de detención del servidor de cómputo.
Prerequisites
Copia de seguridad
Antes de detener el inicio de un nodo Compute, es importante comprobar el estado actual de su entorno de Red Hat OpenStack Platform. Se recomienda que verifique el estado actual para evitar complicaciones.
En caso de recuperación, Cisco recomienda realizar una copia de seguridad de la base de datos OSPD con el uso de estos pasos.
<[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
Este proceso asegura que un nodo se pueda reemplazar sin afectar la disponibilidad de ninguna instancia. Además, se recomienda realizar una copia de seguridad de la configuración de CPS.
Utilice esta configuración para realizar una copia de seguridad de las VM CPS desde la máquina virtual Cluster Manager (VM).
[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_28092016.tar.gz
Identificación de las VM alojadas en el nodo de informática
Identifique las VM alojadas en el servidor informático.
[stack@director ~]$ nova list --field name,host,networks | grep compute-10
| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d | pod1-compute-10.localdomain | Replication=10.160.137.161; Internal=192.168.1.131; Management=10.225.247.229; tb1-orch=172.16.180.129
Nota: En el resultado que se muestra aquí, la primera columna corresponde al identificador único universal (UUID), la segunda columna es el nombre de la máquina virtual y la tercera es el nombre de host donde está presente la máquina virtual. Los parámetros de este resultado se utilizarán en secciones posteriores.
Inhabilitar los servicios PCRF que residen en la máquina virtual para ser apagados
1. Inicie sesión en la IP de administración de la VM.
[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit stop all
2. Si la VMes un SM, OAMorArbiter, además, detenga los servicios sessionmgr.
[root@XXXSM03 ~]# cd /etc/init.d
[root@XXXSM03 init.d]# ls -l sessionmgr*
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27717
-rwxr-xr-x 1 root root 4399 Nov 28 22:45 sessionmgr-27721
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27727
3. Para cada archivo titulado sessionmgr-xxxxx ejecute service sessionmgr-xxxxx stop.
[root@XXXSM03 init.d]# service sessionmgr-27717 stop
Apagado Graceful
Apagar VM desde ESC
1. Inicie sesión en el nodo ESC que corresponde al VNF y verifique el estado de la VM.
[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
<vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
<state>VM_ALIVE_STATE</state>
<vm_name> VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
<state>VM_ALIVE_STATE</state>
<snip>
2. Detenga la máquina virtual con el uso de su nombre de máquina virtual. (Nombre de VM indicado en la sección "Identificar las VM alojadas en el nodo de cálculo").
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
3. Una vez detenido, la VM debe ingresar el estado SHUTOFF.
[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
<vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
<state>VM_ALIVE_STATE</state>
<vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
<state>VM_ALIVE_STATE</state>
<vm_name>VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
<state>VM_SHUTOFF_STATE</state>
<snip>
Compute Node Stop-Start
Los pasos mencionados en esta sección son comunes independientemente de las VM alojadas en el nodo informático.
Detener el nodo de cómputo de inicio desde OSPD
1. Verifique el estado y luego detenga el nodo.
[stack@director ~]$ nova list | grep compute-10
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod1-stack-compute-10 | ACTIVE | - | Running | ctlplane=192.200.0.106 |
[stack@director ~]$ nova stop pod1-stack-compute-10
2. Espere a que el estado del cálculo sea Shutoff y vuelva a iniciarlo.
[stack@director ~]$ nova start pod1-stack-compute-10
3. Verifique que el nuevo nodo de cálculo se encuentre en el estado Activo.
[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep compute-10
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod1-stack-compute-10 | ACTIVE | - | Running | ctlplane=192.200.0.106 |
[stack@director ~]$ source pod1-stackrc-Core
[stack@director ~]$ openstack hypervisor list |grep compute-10
| 6 | pod1-compute-10.localdomain |
Restauración de las VM
Recuperación de VM desde ESC
1. Idealmente, desde OSPD si marca la lista nova, las VM deben estar en estado de cierre. En este caso, debe iniciar las VM desde ESC.
[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action START VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin:
2. O bien, si la VM se encuentra en estado de error en la lista nova, realice esta configuración.
[stack@director ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d | ERROR | - | NOSTATE |
3. Ahora, recupere la máquina virtual del ESC.
[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin:
Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<ok/>
</rpc-reply>
4. Monitoree el archivo yangesc.log.
admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN Status Code: 200
14:59:50,112 07-Nov-2017 WARN Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].
Verifique los servicios PCRF que residen en la máquina virtual
Nota: Si la VM se encuentra en el estado SHUTOFF, enciéndala con el uso de esc_nc_cli de ESC. Verifique el diagnostics.sh de la VM del cluster manager y si encuentra algún error encontrado para las VM que se recuperan entonces.
1. Inicie sesión en la máquina virtual correspondiente.
[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit start all
2. Si la VMes un SM, OAMorArbiter, además, inicie los servicios de sessionmgr que se detuvieron antes. Para cada archivo titulado sessionmgr-xxxxx, ejecute service sessionmgr-xxxxx start.
[root@XXXSM03 init.d]# service sessionmgr-27717 start
3. Si todavía no está claro el diagnóstico, realice build_all.sh desde la VM Cluster Manager y realice VM-init en la VM respectiva.
/var/qps/install/current/scripts/build_all.sh
ssh VM e.g. ssh pcrfclient01
/etc/init.d/vm-init