Element Manager após a liberação ultra 6.3 - As mudanças arquitetural e como pesquisar defeitos o EM emitem

Introdução

Este documento descreve as mudanças na arquitetura do Element Manager (EM) que são introduzidas como parte da liberação de 6.3 UltraM.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• STAROs
• Arquitetura da base de Ultra-M

Componentes Utilizados

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Antes de ultra 6.3 libere, porque o Element Manager a trabalhar ultra lá era uma exigência criar 3 UEM VM.  Ó não era dentro uso e estava lá ajudar o conjunto do ZooKeeper do formulário. Até à data da liberação 6.3, este projeto mudou.

Abreviaturas

Abreviaturas usadas neste artigo:

VNF	Função da rede virtual
CF	Função de controle
SF	Função de serviço
ESC	Controlador elástico do serviço
VIM	Gerente virtual da infraestrutura
VM	Máquina virtual
EM	Element Manager
UA	Ultra Automation Services
UUID	Universalmente identificador exclusivo
ZK	Zoo keeper

Ultra Element Manager após a liberação ultra 6.3 - Mudanças arquitetural

Este documento descreve estas mudanças 5 que são introduzidas como parte da liberação de 6.3 UltraM: 

O número de exemplos UEM VM é configurável até à data da liberação 6.3

Antes de 6.3 liberações, 3 UEM VM eram imperativos. Você poderia ver que com nova a lista após o arquivo do inquilino do núcleo é originado:

[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 |

Este instantâneo da configuração (do arquivo vnf.conf) foi usado:

 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
...

Apesar do número de exemplos especificados neste comando, o número de VM girados era sempre 3. ou seja os número--exemplos que o valor foi ignorado.

Até à data de 6.3, isto obtém mudado - o valor configurado pode ser 2 ou 3. 

Quando você configura 2, os 2 UEM VM estão criados. 

Quando você configura 3, os 3 UEM VM estão criados.

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 configuração conduziria a 2 VM como considerado com lista da 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 |

Note contudo que uma exigência de 3 endereços IP de Um ou Mais Servidores Cisco ICM NT permaneceu a mesma. Isto é, no EM parte da configuração (arquivo vnf.conf) o endereço IP de Um ou Mais Servidores Cisco ICM NT 3 é ainda imperativa:

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 
 !

Isto é precisado para que ZK trabalhe 3 exemplos de ZK é exigido. Cada exemplo exige um endereço IP de Um ou Mais Servidores Cisco ICM NT. Mesmo que o ó exemplo não seja usado eficazmente, o ó IP é atribuído ao ó, exemplo assim chamado do árbitro ZK (veja Diff.2 para mais explicação).

Que efeito que isto tem na rede da orquestração?

Está indo sempre estar 3 portas criadas na rede da orquestração (para ligar os 3 endereços IP de Um ou Mais Servidores Cisco ICM NT mencionados). 

[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"} |

Distribuição do ZooKeeper

Antes de 6.3 ZK foi usado para formar o conjunto, daqui esta exigência é para o ó VM.
Essa exigência não mudou. Contudo, para as instalações onde 2 UEM VM são usados, um ó exemplo ZK é hospedado no mesmo grupo de VM:

Antes de 6.3 e após 6.3 em uma instalação com 3 UEM VM:

UEM VM1: hospedando o exemplo 1 de Zk

UEM VM2: hospedando o exemplo 2 de Zk

UEM VM3: hospedando o exemplo 3 de Zk

Em 6.3 e mais atrasado onde 2 VM somente:

UEM VM1: hospedando Zk cite como exemplo 1 & exemplo 3 de Zk

UEM VM2: hospedando o exemplo 2 de Zk

UEM VM3: para não existir

Veja a imagem 1. na parte inferior deste artigo para representação gráfica detalhada. 

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 <ip>: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

Introdução de Keepalived para o HA

Com as liberações precedentes, estrutura da eleição do líder ZK usada para determinar o EM mestre. Aquele não é o caso anymore porque Cisco se moveu para a estrutura keepalived. 

Que keepalived e como ele trabalham?

Keeplaived é software baseado Linux usado para o Balanceamento de carga e o requisito de alta disponibilidade ao sistema Linux e às infra-estruturas baseadas Linux.

É usado já no ESC para o HA. 

No EM, Keepalived é usado para decuplar os NC do estado do conjunto de Zk. 

As corridas do processo de Keepalived somente nos primeiros dois exemplos do EM e determinariam o estado mestre para o processo NC. 

To check if the keepalived process is running:

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

Por que mude?

Em uma aplicação mais adiantada, a seleção do nó mestre (NCS/SCM) foi integrada proximamente com estado do conjunto de Zk (o primeiro exemplo a travar em /em no base de dados de Zk foi elegido mestre). Isto cria problemas quando Zk perde a Conectividade com o conjunto. 

Keepalived é usado para manter conjunto ativo/à espera UEM na base VM.

Os NC mantêm os dados de configuração. 
O Zookeeper mantém os dados operacionais. 

Decuple o SCM do processo NC 

Nas liberações antes de 6.3, o componente SCM foi empacotado com NC. Isso significa quando os NC começaram, o SCM começado também (como a consequência). Nesta liberação, isto é decuplado agora e o SCM é um processo separado para se. 

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

O EM presta serviços de manutenção a corridas no nó mestre somente

Antes de 6.3 liberações, os serviços UEM executam em ambos o mestre/escravo. Até à data de 6.3 serviços é executado no nó mestre somente. Isto impactaria a saída indicada na mostra ems. Até à data de 6.3, espera-se ver somente um nó (mestre) com este comando, entrado uma vez ao UEM CLI:

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. 

Eficazmente todos os serviços seriam executado no nó mestre, com exceção dos NC, e aquele é devido às exigências NC. 

Esta imagem mostra o sumário dos serviços possíveis e da distribuição VM para ultra o Element Manager

Etapas para pesquisar defeitos problemas relacionados do Element Manager

Durante a inicialização, esta é a sequência de inicialização:

UEM Setup com 2 VM - Sequência de inicialização do processo e lugar do log

Mestre UEM:

• keepalived
• Zookeeper
• NC
• Exemplo do árbitro (ó) do Zookeeper
• VNFM-proxy
• SCM
• SLA

Escravo UEM:

• keepalived
• Zookeeper
• NC

UEM Setup com 3 VM - Sequência de inicialização do processo e lugar do log

Mestre UEM:

• keepalived
• Zookeeper
• NC
• VNFM-proxy
• SCM
• SLA

Escravo UEM:

• keepalived
• Zookeeper
• NC

ó UEM:

• Zookeeper

Sumário de processos UEM 

Este é o sumário dos processos UEM que você tem que executar.

Você verifica o estado com o picosegundo - aef | grep xx

keepalived

árbitro

scm

precários

zoo.cfg

ncs

Você pode verificar o estado com o estado do serviço xx, onde xx:

zookeeper-árbitro

proxy

scm

precários

zk

ncs