Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Abbreviazioni

Ultra Element Manager dopo Ultra 6.3 Release - Modifiche all'architettura

Il numero di istanze di VM UEM è configurabile alla versione 6.3

Distribuzione ZooKeeper

Introduzione di Mantenuti attivi per HA

Separazione di SCM dal processo NCS

Il servizio EM viene eseguito solo sul nodo principale

Passi per la risoluzione dei problemi correlati a Element Manager

Configurazione UEM con 2 VM - Sequenza di avvio del processo e posizione del log

Configurazione UEM con 3 VM - Sequenza di avvio del processo e posizione del log

Riepilogo dei processi UEM

Introduzione

Questo documento descrive le modifiche all'architettura di Element Manager (EM) introdotte come parte della release 6.3 UltraM.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

- STARO

- Architettura di base Ultra-M

Componenti usati

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Prima della versione Ultra 6.3, per il funzionamento di Ultra Element Manager era necessario creare 3 VM UEM.  Il terzo non era in uso ed era lì per aiutare a formare il cluster ZooKeeper. A partire dalla versione 6.3, questo design è stato modificato.

Abbreviazioni

Abbreviazioni utilizzate in questo articolo:

VNF

Funzione di rete virtuale

CF

Funzione di controllo

SF

Funzione di servizio

ESC

Elastic Service Controller

VIM

Virtual Infrastructure Manager

VM

Macchina virtuale

EM

Gestione elementi

UAS

Ultra Automation Services

UUID

Identificatore univoco universale

ZK

Custode zoo

Ultra Element Manager dopo Ultra 6.3 Release - Modifiche all'architettura

Questo documento descrive le 5 modifiche introdotte come parte della release 6.3 UltraM:

Il numero di istanze di VM UEM è configurabile alla versione 6.3

Prima della release 6.3, 3 VM UEM erano obbligatorie. Si potrebbe vedere che con nova elenco dopo l'origine del file tenant core:

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

Questo snapshot di configurazione (dal file vnf.conf) è stato utilizzato:

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

...

Indipendentemente dal numero di istanze specificato in questo comando, il numero di macchine virtuali ruotate è sempre 3. In altre parole, il valore del numero di istanze è stato ignorato.

A partire dalla versione 6.3, questa viene modificata - il valore configurato può essere 2 o 3.

Quando si configura 2, vengono create le 2 VM UEM.

Quando si configura 3, vengono create le 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

....

Questa configurazione darebbe come risultato 2 VM come mostrato nell'elenco 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 |

Si noti, tuttavia, che il requisito di 3 indirizzi IP rimane lo stesso. Ciò significa che nella parte EM della configurazione (file vnf.conf) l'indirizzo IP 3 è ancora obbligatorio:

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

!

Questa operazione è necessaria affinché ZK funzioni. Sono necessarie 3 istanze di ZK. Ogni istanza richiede un indirizzo IP. Anche se la terza istanza non viene effettivamente utilizzata, la terza IP viene assegnata alla terza istanza, la cosiddetta Arbiter ZK (vedere Diff.2 per ulteriori informazioni).

Che effetto ha questo sulla rete di orchestrazione?

Nella rete di orchestrazione verranno sempre create 3 porte (per collegare i 3 indirizzi IP menzionati).

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

Distribuzione ZooKeeper

Prima della 6.3 ZK era stato utilizzato per formare il cluster, quindi questo requisito è per la terza VM.

Questo requisito non è cambiato. Tuttavia, per le impostazioni in cui vengono utilizzate 2 VM UEM, una terza istanza ZK è ospitata sullo stesso set di VM:

Prima della 6.3 e dopo la 6.3 in una configurazione con 3 VM UEM:

UEM VM1: hosting istanza Zk 1

UEM VM2: hosting istanza Zk 2

UEM VM3: hosting istanza Zk 3

Nella versione 6.3 e successive, dove solo 2 VM:

UEM VM1: hosting istanza Zk 1 e istanza Zk 3

UEM VM2: hosting istanza Zk 2

UEM VM3: non esiste

Vedere la figura 1. in fondo a questo articolo per una rappresentazione grafica dettagliata.

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

Introduzione di Mantenuti attivi per HA

Con le release precedenti, il framework per l'elezione dei leader ZK veniva utilizzato per determinare i master EM. Questo non è più il caso, in quanto Cisco è passata al framework keepalive.

Cosa viene mantenuto e come funziona?

Keepalive è un software basato su Linux utilizzato per il bilanciamento del carico e l'elevata disponibilità del sistema Linux e delle infrastrutture basate su Linux.

È già utilizzato in ESC per HA.

In EM, l'opzione Mantenuto viene utilizzata per separare NCS dallo stato del cluster Zk.

Il processo Mantenuto attivo viene eseguito solo sulle prime due istanze di Enterprise Manager e determina lo stato principale del processo NCS.

To check if the keepalived process is running:

ps -aef | grep keepalived

(must return the process ID)

Perché cambiare?

In un'implementazione precedente, la selezione del nodo master (NCS/SCM) era strettamente integrata con lo stato del cluster Zk (la prima istanza a bloccare /em nel database Zk è stata scelta come master). Questo crea problemi quando Zk perde la connettività con il cluster.

Mantenuto attivo viene utilizzato per mantenere il cluster UEM attivo/standby sulla base di VM.

NCS gestisce i dati di configurazione.

Zookeeper conserva i dati operativi.

Separazione di SCM dal processo NCS

Nelle versioni precedenti alla 6.3, il componente SCM era fornito con NCS. Ciò significa che all'avvio dell'NCS anche l'SCM ha avuto inizio (di conseguenza). In questa release, l'operazione è ora disaccoppiata e SCM è un processo separato per se stesso.

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

Il servizio EM viene eseguito solo sul nodo principale

Nelle versioni precedenti alla 6.3, i servizi UEM vengono eseguiti sia su Master che su Slave. A partire dalla versione 6.3, i servizi vengono eseguiti solo sul nodo master. Questo influirebbe sull'output visualizzato in show ems. A partire dalla versione 6.3, si prevede di vedere solo un nodo (master) con questo comando, una volta eseguito il login alla CLI 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.

Tutti i servizi verrebbero effettivamente eseguiti sul nodo principale, ad eccezione di NCS, e ciò è dovuto ai requisiti NCS.

Questa immagine mostra il riepilogo dei possibili servizi e distribuzione VM per Ultra Element Manager

Passi per la risoluzione dei problemi correlati a Element Manager

Durante l'avvio, questa è la sequenza di avvio:

Configurazione UEM con 2 VM - Sequenza di avvio del processo e posizione del log

UEM master:

- conservato

- Zookeeper

- NCS

- Arbitro (3a) istanza di Zookeeper

- VNFM-Proxy

- SCM

- SLA

UEM slave:

- conservato

- Zookeeper

- NCS

Configurazione UEM con 3 VM - Sequenza di avvio del processo e posizione del log

UEM master:

- conservato

- Zookeeper

- NCS

- VNFM-Proxy

- SCM

- SLA

UEM slave:

- conservato

- Zookeeper

- NCS

Terza UEM:

- Zookeeper

Riepilogo dei processi UEM

Riepilogo dei processi UEM da eseguire.

Lo stato viene verificato con ps -aef | grep xx

conservato

arbitro

scm

sla

zoo.cfg

ncs

È possibile controllare lo stato con lo stato del servizio xx, dove xx:

zookeeper-arbitro

proxy

scm

sla

zk

ncs