Administrador de elementos después de la versión Ultra 6.3: cambios arquitectónicos y cómo solucionar problemas de EM

Introducción

Este documento describe los cambios en la arquitectura del gestor de elementos (EM) que se introducen como parte de la versión 6.3 UltraM.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• STARO
• Arquitectura básica Ultra M

Componentes Utilizados

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Antes de la versión Ultra 6.3, para que Ultra Element Manager funcionara, era necesario crear 3 VM UEM.  La tercera no estaba en uso y estaba ahí para ayudar a formar el clúster ZooKeeper. A partir de la versión 6.3, este diseño ha cambiado.

Abreviaturas

Abreviaturas utilizadas en este artículo:

VNF	Función de red virtual
CF	Función de control
SF	Función de servicio
ESC	Controlador de servicio elástico
VIM	Administrador de infraestructura virtual
VM	Máquina virtual
EM	Administrador de elementos
UAS	Servicios de ultra automatización
UUID	Identificador único universal
ZK	Zoo Keeper

Ultra Element Manager después de la versión Ultra 6.3: cambios arquitectónicos

Este documento describe estos 5 cambios que se introducen como parte de la versión 6.3 UltraM: 

Número de instancias de UEM VM configurables a partir de la versión 6.3

Antes de la versión 6.3,3 VM UEM eran obligatorias. Podría ver eso con nova list después de que se obtenga el archivo principal del arrendatario:

[root@POD]# openstack server list --all
+--------------------------------------+-----------------------+--------+--------------------------------------------------------------------+---------------+
| ID | Name | Status | Networks | Image Name |
+--------------------------------------+-----------------------+--------+---------------------------------....
| fae2d54a-96c7-4199-a412-155e6c029082 | vpc-LAASmme-em-3 | ACTIVE | orch=192.168.12.53; mgmt=192.168.11.53 | ultra-em |
| c89a3716-9028-4835-9237-759166b5b7fb | vpc-LAASmme-em-2 | ACTIVE | orch=192.168.12.52; mgmt=192.168.11.52 | ultra-em |
| 5f8cda2c-657a-4ba1-850c-805518e4bc18 | vpc-LAASmme-em-1 | ACTIVE | orch=192.168.12.51; mgmt=192.168.11.51 | ultra-em |

Se utilizó esta instantánea de configuración (del archivo vnf.conf):

 vnfc em
 health-check enabled
 health-check probe-frequency 10
 health-check probe-max-miss 6
 health-check retry-count 6
 health-check recovery-type restart-then-redeploy
 health-check boot-time 300
 vdu vdu-id em
 number-of-instances 1 --> HERE, this value was previously ignored in pre 6.3 releases
 connection-point eth0
...

Independientemente del número de instancias especificadas en este comando, el número de VM de envío siempre fue 3. En otras palabras, el valor number-of-instance fue ignorado.

A partir de 6.3, esto cambia - el valor configurado puede ser 2 ó 3. 

Al configurar 2, se crean las 2 VM UEM. 

Al configurar 3, se crean las 3 VM UEM.

vnfc em
 health-check enabled
 health-check probe-frequency 10
 health-check probe-max-miss 6
 health-check retry-count 3
 health-check recovery-type restart
 health-check boot-time 300
 vdu vdu-id vdu-em
 vdu image ultra-em
 vdu flavor em-flavor
 number-of-instances 2 --> HERE
 connection-point eth0
....

Esta configuración daría como resultado 2 VM tal y como se ven en la lista nova.

[root@POD]# openstack server list --all
+--------------------------------------+-----------------------+--------+--------------------------------------------------------------------+---------------+
| ID | Name | Status | Networks | Image Name |
+--------------------------------------+-----------------------+--------+---------------------------------....
| fae2d54a-96c7-4199-a412-155e6c029082 | vpc-LAASmme-em-3 | ACTIVE | orch=192.168.12.53; mgmt=192.168.11.53 | ultra-em |
| c89a3716-9028-4835-9237-759166b5b7fb | vpc-LAASmme-em-2 | ACTIVE | orch=192.168.12.52; mgmt=192.168.11.52 | ultra-em |

Sin embargo, tenga en cuenta que el requisito de 3 direcciones IP se mantuvo igual. Es decir, en la parte EM de la configuración (archivo vnf.conf), la dirección IP 3 sigue siendo obligatoria:

vnfc em
 health-check enabled
 health-check probe-frequency 10
 health-check probe-max-miss 6
 health-check retry-count 3
 health-check recovery-type restart
 health-check boot-time 300
 vdu vdu-id vdu-em
 vdu image ultra-em
 vdu flavor em-flavor
 number-of-instances 2 ---> NOTE NUMBER OF INSTANCES is 2
 connection-point eth0
 virtual-link service-vl orch
 virtual-link fixed-ip 172.x.y.51  --> IP #1
 !
 virtual-link fixed-ip 172.x.y.52 --> IP #2
 !
 virtual-link fixed-ip 172.x.y.53  --> IP #3 
 !

Esto es necesario para que ZK funcione con 3 instancias de ZK. Cada instancia requiere una dirección IP. Aunque la tercera instancia no se utiliza de manera efectiva, la tercera IP se asigna a la tercera, llamada instancia Arbiter ZK (consulte Diff.2 para obtener más información).

¿Qué efecto tiene esto en la red de orquestación?

Siempre habrá 3 puertos creados en la red de orquestación (para enlazar las 3 direcciones IP mencionadas). 

[root@POD# neutron port-list | grep -em_

| 02d6f499-b060-469a-b691-ef51ed047d8c | vpc-LAASmme-em_vpc-LA_0_70de6820-9a86-4569-b069-46f89b9e2856 | fa:16:3e:a4:9a:49 | {"subnet_id": "bf5dea3d-cd2f-4503-a32d-5345486d66dc", "ip_address": "192.168.12.52"} |
| 0edcb464-cd7a-44bb-b6d6-07688a6c130d | vpc-LAASmme-em_vpc-LA_0_2694b73a-412b-4103-aac2-4be2c284932c | fa:16:3e:80:eb:2f | {"subnet_id": "bf5dea3d-cd2f-4503-a32d-5345486d66dc", "ip_address": "192.168.12.51"} |
| 9123f1a8-b3ea-4198-9ea3-1f89f45dfe74 | vpc-LAASmme-em_vpc-LA_0_49ada683-a5ce-4166-aeb5-3316fe1427ea | fa:16:3e:5c:17:d6 | {"subnet_id": "bf5dea3d-cd2f-4503-a32d-5345486d66dc", "ip_address": "192.168.12.53"} |

Distribución de ZooKeeper

Antes de 6.3 ZK se utilizaba para formar el clúster, por lo que este requisito es para la tercera VM.
Ese requisito no ha cambiado. Sin embargo, para las configuraciones donde se utilizan 2 VM UEM, se aloja una tercera instancia ZK en el mismo conjunto de VM:

Antes de 6.3 y después de 6.3 en una configuración con 3 VM UEM:

VM1 de UEM: alojamiento de la instancia 1 de Zk

VM2 de UEM: alojamiento de Zk instancia 2

VM3 de UEM: alojamiento de Zk instancia 3

En la versión 6.3 y posteriores, donde sólo 2 VM:

VM1 de UEM: alojamiento de Zk instancia 1 y Zk instancia 3

VM2 de UEM: alojamiento de Zk instancia 2

VM3 de UEM: no existe

Véase la imagen 1. en la parte inferior de este artículo para obtener una representación gráfica detallada. 

Useful Zk commands:

To see Zk mode (leader/follower):

/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

To check if Zk is running:

echo stat | nc IP_ADDRESS 2181

How to find the Ip address of Zk instance:

Run 'ip addr' from EM
In the /opt/cisco/em/config/ip.txt there are all the 3IP's
From vnf.conf file
From 'nova list' look for orchestration IP
For 2 EM's the arbiter IP can be found also in /opt/cisco/em/config/proxy-params.txt

How to check status of the Zk instance:

echo stat | nc 192.168.12.51 2181 | grep Mode
Mode: follower

You can run this command from one Zk for all other Zk instances (even they are on different VM)!

To connect to the Zk cli - now must use the IP (rather then localhost earlier):

/opt/cisco/usp/packages/zookeeper/current/bin/zkCli.sh -server 
      
        :2181 
       
 
       
You can use same command to connect to other Zk instances (even they are on different VM)! 
       
 
       
 
      Some useful command you can run once you connect to ZkCli:
    
            ls /config/vdus/control-function
            ls /config/element-manager
            ls /
            ls /log
            ls /stat
            get /config/vdus/session-function/BOOTxx

Introducción de Keepalived para HA

Con las versiones anteriores, se utilizó el marco de elección del líder ZK para determinar el maestro EM. Este ya no es el caso, ya que Cisco ha pasado al marco de mantenimiento. 

¿Qué se mantiene activo y cómo funciona?

Keeplaseen es software basado en Linux utilizado para equilibrio de carga y alta disponibilidad para infraestructuras basadas en Linux y sistemas Linux.

Ya se utiliza en ESC para HA. 

En EM, Keepalived se utiliza para separar el NCS del estado de clúster Zk. 

El proceso "keepalived" se ejecuta sólo en las dos primeras instancias de EM y determinaría el estado maestro del proceso NCS. 

To check if the keepalived process is running:

ps -aef | grep keepalived
    (must return the process ID)

¿Por qué cambiar?

En una implementación anterior, la selección del nodo maestro (NCS/SCM) se integró estrechamente con el estado del clúster de Zk (la primera instancia para bloquear el /em en la base de datos de Zk se eligió principal). Esto crea problemas cuando Zk pierde la conectividad con el clúster. 

Keepalived se utiliza para mantener el clúster UEM activo/en espera en VM.

NCS mantiene los datos de configuración. 
Zookeeper mantiene los datos operativos. 

Desacoplar SCM del proceso de NCS 

En las versiones anteriores a la 6.3, el componente SCM se empaquetó con NCS. Esto significa que cuando se inició NCS, también se inició el SCM (como consecuencia). En esta versión, esto ahora está desacoplado y SCM es un proceso separado para sí mismo. 

Commands to check the NCS and SCM services & processes. 
To be executed from the ubuntu command line

ps -aef | grep ncs
ps -aef | grep scm

sudo service show ncs
sudo service scm status

El servicio EM se ejecuta sólo en el nodo principal

Antes de la versión 6.3, los servicios de UEM se ejecutaban tanto en Master como en Slave. A partir de la versión 6.3, los servicios se ejecutan sólo en el nodo maestro. Esto afectaría la salida mostrada en show ems. A partir de la versión 6.3, se espera que vea solamente un nodo (maestro) con este comando, una vez que haya iniciado sesión en la CLI de UEM:

root@vpc-em-2:/var/log# sudo -i
root@vpc-em-2:~# ncs_cli -u admin -C

admin connected from 127.0.0.1 using console on vpc-LAASmme-em-2
admin@scm# show ems
EM VNFM 
ID SLA SCM PROXY VERSION 
------------------------------
52 UP UP UP 6.3.0 ===> HERE Only one EM instance is seen. In previous releases you were able to see 2 instances. 

Efectivamente, todos los servicios se ejecutarían en el nodo principal, con excepción de NCS, y ello se debe a los requisitos de NCS. 

Esta imagen muestra el resumen de los posibles servicios y distribución de VM para Ultra Element Manager

Pasos para Resolver Problemas Relacionados con el Administrador de Elementos

Durante el inicio, esta es la secuencia de inicio:

Configuración de UEM con 2 VM: Procesar secuencia de inicio y ubicación de registro

UEM maestro:

• keepalived
• Zookeeper
• NCS
• Árbitro (3^ª) instancia de Zookeeper
• Proxy VNFM
• SCM
• SLA

Esclavo UEM:

• keepalived
• Zookeeper
• NCS

Configuración de UEM con 3 VM: Procesar secuencia de inicio y ubicación de registro

UEM maestro:

• keepalived
• Zookeeper
• NCS
• Proxy VNFM
• SCM
• SLA

Esclavo UEM:

• keepalived
• Zookeeper
• NCS

3.ª UEM:

• Zookeeper

Resumen de procesos UEM 

Este es el resumen de los procesos UEM que debe ejecutar.

Compruebe el estado con ps -aef | grep xx

keepalived

árbitro

scm

sla

zoo.cfg

ncs

Puede verificar el estado con el estado xx del servicio, donde xx:

zookeeper-arbiter

proxy

scm

sla

zk

ncs