Procedimiento de recuperación para fallo de clúster de Ultra-M AutoVNF - vEPC

Introducción

Este documento describe los pasos necesarios para recuperar la falla de Ultra Automation Services (UAS) o AutoVNF Cluster en una configuración Ultra-M que aloja funciones de red virtual (VNF) de StarOS.

Antecedentes

Ultra-M es una solución de núcleo de paquetes móviles virtualizados previamente empaquetada y validada que se ha diseñado para simplificar la implementación de VNF.

La solución Ultra-M consta de los tipos de máquina virtual (VM) mencionados:

• TI automática 
• Implementación automática
• UAS o AutoVNF
• Administrador de elementos (EM)
• Controlador de servicios elástico (ESC)
• Función de control (CF)
• Función de sesión (SF)

La arquitectura de alto nivel de Ultra-M y los componentes implicados se muestran en esta imagen:

Arquitectura UltraM

Este documento está dirigido al personal de Cisco que está familiarizado con la plataforma Cisco Ultra-M.

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

Abreviaturas

VNF	Función de red virtual
CF	Función de control
SF	Función de servicio
ESC	Controlador de servicio elástico
FREGAR	Método de procedimiento
OSD	Discos de almacenamiento de objetos
HDD	Disco duro
SSD	Unidad de estado sólido
VIM	Administrador de infraestructura virtual
VM	Máquina virtual
EM	Administrador de elementos
UAS	Servicios de ultra automatización
UUID	Identificador único universal

Flujo de trabajo del MOP

Caso 1. Recuperación de un solo fallo del clúster de UAS

Comprobación de estado

1. Ultra-M Manager realiza la comprobación de estado del nodo Ultra-M. Acceda al directorio reports/var/log/cisco/ultram-health/ y a grep para el informe UAS.

• [stack@pod1-ospd ultram-health]$ more ultram_health_uas.report
  
  ---------------------------------------------------------------------------------------------------------
   VNF ID           | UAS Node | Status   | Error Info, if any        
  ---------------------------------------------------------------------------------------------------------
   172.21.201.122   | autovnf  | XXX      | AutoVNF Cluster FAILED : Node: 172.16.180.12, Status: error, Role: NA
   172.21.201.122   | vnf-em   | :-)      |
   172.21.201.122   | esc      | :-)      |
  --------------------------------------------------------------------------------------------------------- 

2. El estado previsto del grupo de UAS será el que se muestra, en el que los tres UAS están activos. 

[stack@pod1-ospd ~]# ssh ubuntu@10.1.1.1
password:

ubuntu@autovnf1-uas:~$ ncs_cli -u admin -C

autovnf1-uas-0#show uas 
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP STATE ROLE 
------------------------------------
172.16.180.3 alive CONFD-MASTER 
172.16.180.7 alive CONFD-SLAVE 
172.16.180.12 alive NA

Fallo al conectarse al servidor configurado cuando intenta conectarse a UAS

1. En algunos casos, no podrá conectarse al servidor confd.

ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ confd_cli -u admin -C
Failed to connect to server

 2. Compruebe el estado del proceso uas-confd.

ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ sudo initctl status uas-confd
uas-confd stop/waiting

3. Si el servidor confd no se ejecuta, reinicie el servicio.

ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ sudo initctl start uas-confd
uas-confd start/running, process 7970
ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 172.16.180.9 using ssh on autovnf1-uas-0

Recuperar UAS del estado de error

 1. En caso de falla de una AutoVNF entre el clúster, el clúster de UAS muestra uno de los UAS en estado de error .

[stack@pod1-ospd ~]# ssh ubuntu@10.1.1.1
password:

ubuntu@autovnf1-uas:~$ ncs_cli -u admin -C

autovnf1-uas-0#show uas 
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP STATE ROLE 
------------------------------------
172.16.180.3 alive CONFD-MASTER 
172.16.180.7 alive CONFD-SLAVE 
172.16.180.12 alive error

2. Copie el archivo correcto (archivo rc de su VNF) de /home/stack en el servidor OSPD a AutoDeploy y obtenga su origen. 

3. Verifique el estado de su UAS/AutoVNF con el uso de la secuencia de comandos uas-check.py . autovnf1 es el nombre de AutoVNF. 

ubuntu@auto-deploy-iso-590-uas-0:~$ /opt/cisco/usp/apps/auto-it/scripts/uas-check.py auto-vnf autovnf1
2017-11-17 14:52:20,186 - INFO: Check of AutoVNF cluster started
2017-11-17 14:52:22,172 - INFO: Found 2 AutoVNF instance(s), 3 expected
2017-11-17 14:52:22,172 - INFO: Instance 'autovnf1-uas-2' is missing
2017-11-17 14:52:22,172 - INFO: Check completed, AutoVNF cluster has recoverable errors

4. Recupere el UAS con el uso del script uas-check.py y la palabra clave add —fix.

ubuntu@auto-deploy-iso-590-uas-0:~$ /opt/cisco/usp/apps/auto-it/scripts/uas-check.py auto-vnf autovnf1 --fix
2017-11-17 14:52:27,493 - INFO: Check of AutoVNF cluster started
2017-11-17 14:52:29,215 - INFO: Found 2 AutoVNF instance(s), 3 expected
2017-11-17 14:52:29,215 - INFO: Instance 'autovnf1-uas-2' is missing
2017-11-17 14:52:29,215 - INFO: Check completed, AutoVNF cluster has recoverable errors
2017-11-17 14:52:29,386 - INFO: Creating instance 'autovnf1-uas-2' and attaching volume 'autovnf1-uas-vol-2'
2017-11-17 14:52:47,600 - INFO: Created instance 'autovnf1-uas-2'

5. Verá que el UAS recién creado está activo y forma parte del clúster.

autovnf1-uas-0#show uas 
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP STATE ROLE 
------------------------------------
172.16.180.3 alive CONFD-MASTER 
172.16.180.7 alive CONFD-SLAVE 
172.16.180.13 alive NA

Caso 2. Los tres UAS (AutoVNF) están en estado de error

1. Ultra-M Manager realiza la comprobación de estado del nodo Ultra-M.

[stack@pod1-ospd ultram-health]$ more ultram_health_uas.report

---------------------------------------------------------------------------------------------------------

 VNF ID           | UAS Node | Status   | Error Info, if any        

---------------------------------------------------------------------------------------------------------

 172.21.201.122   | autovnf  | XXX      | AutoVNF Cluster FAILED : Node: 172.16.180.12, Status: error, Role: NA,Node: 172.16.180.9, Status: error, Role: NA,Node: 172.16.180.10, Status: error, Role: NA

 172.21.201.122   | vnf-em   | :-)      |

 172.21.201.122   | esc      | :-)      |

---------------------------------------------------------------------------------------------------------

2. Como se observa en la salida, el administrador Ultra-M informa de que se ha producido un fallo en AutoVNF y muestra que los tres UAS del cluster están en estado de error. 

Compruebe el estado de UAS con el script uas-check.py

1. Inicie sesión en la implementación automática y compruebe si puede acceder a AutoVNF UAS y obtener el estado.

ubuntu@auto-deploy-iso-590-uas-0:~$ /opt/cisco/usp/apps/auto-it/scripts$ ./uas-check.py auto-vnf autovnf1 --os-tenant-name core

2017-12-05 11:41:09,834 - INFO: Check of AutoVNF cluster started
2017-12-05 11:41:11,342 - INFO: Found 3 ACTIVE AutoVNF instances
2017-12-05 11:41:11,343 - INFO: Check completed, AutoVNF cluster is fine

2. Desde Auto-Deploy, Secure Shell (SSH) hasta AutoVNF node e ingrese en modo confd. Verifique el estado con show uas.

ubuntu@auto-deploy-iso-590-uas-0:~$ ssh ubuntu@172.16.180.9
password:
autovnf1-uas-1#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP    STATE  ROLE 

----------------------------

172.16.180.9   error  NA   
172.16.180.10  error  NA   
172.16.180.12  error  NA   

3. Se recomienda comprobar el estado en los tres nodos UAS.

Comprobar el estado de las VM en el nivel de OpenStack

Compruebe el estado de las máquinas virtuales AutoVNF en la lista de novas. Si es necesario, ejecute nova start para iniciar la VM de apagado.

[stack@pod1-ospd ultram-health]$ nova list | grep autovnf

| 83870eed-b4e9-47b3-976d-cc3eddecf866 | autovnf1-uas-0                                                 | ACTIVE | -          | Running     | orchestr=172.16.180.12; mgmt=172.16.181.6                                                                                                                  
| 201d9ce5-538c-42f7-a46c-fc8cdef1eabf | autovnf1-uas-1                                                 | ACTIVE | -          | Running     | orchestr=172.16.180.10; mgmt=172.16.181.5                                                                                                                    
| 6c6d25cd-21b6-42b9-87ff-286220faa2ff | autovnf1-uas-2                                                 | ACTIVE | -          | Running     | orchestr=172.16.180.9; mgmt=172.16.181.13                                                     

Comprobar la vista del zookeeper

1. Compruebe el estado del zookeeper para verificar el modo como líder.

ubuntu@autovnf1-uas-0:/var/log/upstart$ /opt/cisco/usp/packages/zookeeper/current/bin/zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /opt/cisco/usp/packages/zookeeper/current/bin/../conf/zoo.cfg
Mode: leader

2. Zookeeper normalmente debe estar arriba.

Resolución de problemas de AutoVNF - Procesos y tareas

1. Identifique el motivo del estado de error de los nodos. Para que AutoVNF se ejecute, hay un conjunto de procesos que deben estar activos y en ejecución, como se muestra a continuación:

AutoVNF

uws-ae

uas-confd

cluster_manager

uas_manager

ubuntu@autovnf1-uas-0:~$ sudo initctl list  | grep uas 

uas-confd stop/waiting ====> this is not good, the uas-confd process is not running

uas_manager start/running, process 2143

root@autovnf1-uas-1:/home/ubuntu# sudo initctl list 
....
uas-confd start/running, process 1780
....
autovnf start/running, process 1908
....
....
uws-ae start/running, process 1909
....
....
cluster_manager start/running, process 1827
....
.....
uas_manager start/running, process 1697
......
......

2. Verifique que estos procesos de Python se estén ejecutando:

uas_manager.py

cluster_manager.py

usp_autovnf.py

  

root@autovnf1-uas-1:/home/ubuntu# ps -aef | grep pyth
root      1819  1697  0 Jun13 ?        00:00:50 python /opt/cisco/usp/uas/manager/uas_manager.py
root      1858  1827  0 Jun13 ?        00:09:21 python /opt/cisco/usp/uas/manager/cluster_manager.py
root      1908     1  0 Jun13 ?        00:01:00 python /opt/cisco/usp/uas/autovnf/usp_autovnf.py
root     25662 24750  0 13:16 pts/7    00:00:00 grep --color=auto pyth

3. Si alguno de los procesos esperados no se encuentra en el estado inicio/ejecución, reinicie el proceso y compruebe el estado. Si todavía se muestra en estado de error, siga el procedimiento mencionado en la siguiente sección para solucionar este problema.

Corregir varios UAS en estado de error

1. nova —hard reboot <nombre de la VM> desde OSPD, dedique algún tiempo a la recuperación de esta VM antes de continuar con el siguiente UAS. Hágalo en todas las VM de UAS. 

or

2.Inicie sesión en cada UAS y utilice sudo reboot. Espere a la recuperación y continúe con otras VM de UAS.

Para los registros de transacciones, marque:

/var/log/upstart/autovnf.log

show logs xxx | display xml

Esto solucionará el problema y recuperará el UAS del estado de error. 

1. Verifique lo mismo con el uso del informe ultram_health_check.

[stack@pod1-ospd ultram-health]$ more ultram_health_uas.report

---------------------------------------------------------------------------------------------------------

 VNF ID           | UAS Node | Status   | Error Info, if any        

---------------------------------------------------------------------------------------------------------

 172.21.201.122   | autovnf  | :-)      | 

 172.21.201.122   | vnf-em   | :-)      |

 172.21.201.122   | esc      | :-)      |

---------------------------------------------------------------------------------------------------------