Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

Abreviaturas

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

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

Distribución de ZooKeeper

Introducción de Keepalived para HA

Desacoplar SCM del proceso de NCS

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

Pasos para Resolver Problemas Relacionados con el Administrador de Elementos

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

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

Resumen de procesos UEM

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