Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Abkürzungen

Ultra Element Manager nach der Ultra 6.3-Version - Änderungen bei der Architektur

Anzahl der UEM VM-Instanzen ist ab Version 6.3 konfigurierbar

ZooKeeper-Verteilung

Einführung von Keepalived für HA

Trennung von SCM vom NCS-Prozess

EM-Service läuft nur auf Master-Knoten

Schritte zur Behebung von Element Manager-bezogenen Problemen

UEM-Setup mit 2 VMs - Prozess-Startup-Sequenz und Protokollspeicherort

UEM-Setup mit 3 VMs - Prozess-Startup Sequence und Protokollspeicherort

Zusammenfassung der UEM-Prozesse

Einführung

Dieses Dokument beschreibt die Änderungen in der Element Manager (EM)-Architektur, die als Teil der 6.3 UltraM-Version eingeführt wurden.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

- STAROs

- Ultra-M-Basisarchitektur

Verwendete Komponenten

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

Vor der Ultra 6.3-Version mussten 3 UEM VMs für Ultra Element Manager erstellt werden.  Die dritte war nicht in Gebrauch und war da, um ZooKeeper Cluster zu bilden. Ab Version 6.3 hat sich dieses Design geändert.

Abkürzungen

In diesem Artikel verwendete Abkürzungen:

VNF

Virtuelle Netzwerkfunktion

CF

Kontrollfunktion

SF

Servicefunktion

WSA

Elastic Service Controller

VIM

Virtueller Infrastrukturmanager

VM

Virtuelles System

EM

Element Manager

USA

Ultra-Automatisierungsservices

UUID

Universell eindeutige IDentifier

ZK

Zooschlüssel

Ultra Element Manager nach der Ultra 6.3-Version - Änderungen bei der Architektur

In diesem Dokument werden die fünf Änderungen beschrieben, die als Teil der 6.3 UltraM-Version eingeführt wurden:

Anzahl der UEM VM-Instanzen ist ab Version 6.3 konfigurierbar

Vor der Version 6.3 waren 3 UEM VM-Systeme obligatorisch. Sie können sehen, dass mit nova-Liste nach der Quelle der Core-Tenant-Datei:

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

Dieser Snapshot der Konfiguration (aus der Datei vnf.conf) wurde verwendet:

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

...

Unabhängig von der Anzahl der in diesem Befehl angegebenen Instanzen betrug die Anzahl der spun VMs immer 3. Anders ausgedrückt wurde der Wert für die Anzahl der Instanzen ignoriert.

Ab 6.3 wird dies geändert - der konfigurierte Wert kann 2 oder 3 sein.

Wenn Sie 2 konfigurieren, werden die 2 UEM VMs erstellt.

Wenn Sie 3 konfigurieren, werden die 3 UEM VMs erstellt.

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

....

Diese Konfiguration würde zu zwei VM's führen, wie aus der nova-Liste hervorgeht.

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

Beachten Sie jedoch, dass die Anforderungen an drei IP-Adressen unverändert geblieben sind. Das heißt, im EM-Teil der Konfiguration (vnf.conf-Datei) sind die drei IP-Adressen noch obligatorisch:

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

!

Dies ist erforderlich, damit ZK 3 Instanzen von ZK bearbeiten kann. Jede Instanz benötigt eine IP-Adresse. Auch wenn die dritte Instanz nicht effektiv verwendet wird, wird die dritte IP der dritten so genannten Arbiter ZK-Instanz zugewiesen (weitere Erläuterungen siehe Diff.2).

Welche Auswirkungen hat dies auf das Orchestrierungsnetzwerk?

Im Orchestrierungsnetzwerk werden immer 3 Ports erstellt (um die drei genannten IP-Adressen zu binden).

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

ZooKeeper-Verteilung

Vor 6,3 ZK wurde zur Erstellung des Clusters verwendet. Daher ist diese Anforderung für eine dritte VM bestimmt.

Diese Anforderung hat sich nicht geändert. Für die Einrichtungen, in denen 2 UEM-VMs verwendet werden, wird jedoch eine dritte ZK-Instanz auf demselben Satz von VMs gehostet:

Vor 6.3 und nach 6.3 in einer Konfiguration mit 3 UEM-VMs:

UEM VM1: ZK-Instanz 1 hosten

UEM VM2: Zk Instanz 2 hosten

UEM VM3: ZK Instanz 3 hosten

In 6.3 und höher, wobei nur 2 VMs:

UEM VM1: Hosten von Zk Instanz 1 und Zk Instanz 3

UEM VM2: Zk Instanz 2 hosten

UEM VM3: nicht vorhanden

Siehe Abbildung 1. am Ende dieses Artikels für eine detaillierte grafische Darstellung.

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

Einführung von Keepalived für HA

Mit den vorherigen Veröffentlichungen wurde das Master-EM mithilfe des Wahlrahmens der ZK-Führungskräfte bestimmt. Das ist nicht mehr der Fall, da Cisco auf das Keepalived Framework umgestiegen ist.

Was ist Keepalived und wie funktioniert es?

Keepalive ist eine Linux-basierte Software, die für Lastenausgleich und hohe Verfügbarkeit für Linux- und Linux-basierte Infrastrukturen verwendet wird.

Es wird bereits in ESC für HA verwendet.

In EM wird Keepalived verwendet, um das NCS vom Zk-Cluster-Status zu trennen.

Der Keepalived-Prozess wird nur auf den ersten beiden Instanzen des EM ausgeführt und bestimmt den Master-Status für den NCS-Prozess.

To check if the keepalived process is running:

ps -aef | grep keepalived

(must return the process ID)

Warum ändern?

In einer früheren Implementierung wurde die (NCS/SCM) Master Node-Auswahl eng mit dem Zk Cluster-Status integriert (die erste Instanz, die die /em in der Zk-Datenbank sperrte, wurde zum Master gewählt). Dies verursacht Probleme, wenn Zk die Verbindung mit dem Cluster verliert.

Keepalived wird verwendet, um Aktiv/Standby-UEM-Cluster auf VM-Basis zu verwalten.

Das NCS verwaltet die Konfigurationsdaten.

Zookeeper speichert die Betriebsdaten.

Trennung von SCM vom NCS-Prozess

In Versionen vor 6.3 wurde die SCM-Komponente mit NCS gebündelt. Das bedeutet, dass der SCM auch mit dem Start des NCS begann (als Konsequenz). In dieser Version ist dies nun entkoppelt und SCM ist ein separater Prozess für sich.

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

EM-Service läuft nur auf Master-Knoten

Vor der Version 6.3 werden UEM-Dienste auf Master/Slave ausgeführt. Ab 6.3 werden Dienste nur auf dem Master-Knoten ausgeführt. Dies würde sich auf die in show ems angezeigte Ausgabe auswirken. Ab 6.3 wird voraussichtlich nur noch ein (Master-)Knoten mit diesem Befehl angezeigt, sobald er bei der UEM-CLI angemeldet ist:

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.

Tatsächlich würden alle Services auf dem Master-Knoten ausgeführt, mit Ausnahme des NCS. Dies ist auf die NCS-Anforderungen zurückzuführen.

Dieses Bild zeigt die Zusammenfassung der möglichen Services und VM-Verteilung für Ultra Element Manager.

Schritte zur Behebung von Element Manager-bezogenen Problemen

Beim Start folgt die Startsequenz:

UEM-Setup mit 2 VMs - Prozess-Startup-Sequenz und Protokollspeicherort

Master-UEM:

- eifersüchtig

- Zookeeper

- NCS

- Arbiter (3. Instanz von Zookeeper

- VNFM-Proxy

- SCM

- SLA

Slave-UEM:

- eifersüchtig

- Zookeeper

- NCS

UEM-Setup mit 3 VMs - Prozess-Startup Sequence und Protokollspeicherort

Master-UEM:

- eifersüchtig

- Zookeeper

- NCS

- VNFM-Proxy

- SCM

- SLA

Slave-UEM:

- eifersüchtig

- Zookeeper

- NCS

3. UEM:

- Zookeeper

Zusammenfassung der UEM-Prozesse

Dies ist die Zusammenfassung der UEM-Prozesse, die Sie ausführen müssen.

Sie überprüfen den Status mit ps-aef. | grep xx

eifersüchtig

Schiedsrichter

schrumpfen

sla

Zoo.cfg

NCS

Sie können den Status mit dem Service-xx-Status überprüfen, wobei xx:

Zookeeper-Arbiter

Proxy

schrumpfen

sla

ZK

NCS