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

NCS