Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Achtergrondinformatie

Afkortingen

Ultra Element Manager na Ultra 6.3 release - Architectuurveranderingen

Aantal UEM VM-stoffen kan vanaf 6.3 worden configureren

ZooKeeper Distribution

Inleiding van Keepalived voor HA

SCM van NCS proces decoderen

EM-service wordt alleen op hoofdknooppunt uitgevoerd

Stappen voor problemen met probleemoplossing bij element Manager

UEM Instellen met 2 VM's - Opstartsequentie en locatie voor loggen verwerken

UEM Instellen met 3 VM's - Opstartsequentie en locatie voor loggen verwerken

Samenvatting van UEM-processen

Inleiding

In dit document worden de wijzigingen in de Element Manager (EM)-architectuur beschreven die als onderdeel van de 6.3 UltraM-release worden geïntroduceerd.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

- STARO’S

- Ultra-M basisarchitectuur

Gebruikte componenten

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Achtergrondinformatie

Vóór de introductie van Ultra 6.3 moest Ultra Element Manager drie UEM VM's creëren om te kunnen werken.  Het derde toestel werd niet gebruikt en was er om te helpen bij het vormen van ZooKeeper cluster. Vanaf de release 6.3 is dit ontwerp veranderd.

Afkortingen

In dit artikel gebruikte afkortingen:

VNF

Virtuele netwerkfunctie

CF

Bedieningsfunctie

SF

Service-functie

ESC

Elastic Service Controller

VIM

Virtual-infrastructuurbeheer

VM

Virtuele machine

EM

Element Manager

UAS

Ultra Automation Services

UUID

Universele unieke ID-versterker

ZK

Zoo Keeper

Ultra Element Manager na Ultra 6.3 release - Architectuurveranderingen

In dit document worden deze 5 veranderingen beschreven die worden geïntroduceerd als onderdeel van de 6.3 UltraM release:

Aantal UEM VM-stoffen kan vanaf 6.3 worden configureren

Voor de introductie van 6.3, waren 3 UEM VM verplicht. Je kon dat zien met nova lijst na de bron van het basishuurbestand:

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

Deze configuratiesnapshot (van vnf.conf-bestand) is gebruikt:

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

...

Ongeacht het aantal gevallen dat in deze opdracht is gespecificeerd, was het aantal VM's met spun altijd 3. Met andere woorden, de waarde aantal gevallen werd genegeerd.

Vanaf 6.3 wordt dit gewijzigd - de ingestelde waarde kan 2 of 3 zijn.

Bij configuratie 2 worden de 2 UEM-VM's gecreëerd.

Bij configuratie 3 worden de 3 UEM-VM's gecreëerd.

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

....

Deze configuratie zou resulteren in twee VM's zoals die met nova list worden gezien.

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

Houd er echter rekening mee dat 3 IP-adresvoorschriften hetzelfde blijven. Dat wil zeggen dat in het EM deel van de configuratie (vnf.conf-bestand) het 3 IP-adres nog steeds verplicht is:

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

!

Dit is nodig voor ZK om 3 gevallen van ZK te kunnen gebruiken. Elk exemplaar vereist een IP-adres. Hoewel de derde instantie niet effectief wordt gebruikt, wordt het derde IP toegewezen aan de derde, zogenoemde Arbiter ZK-instantie (zie Diff.2 voor meer uitleg).

Welke gevolgen heeft dit voor het orkestratienetwerk?

Er zullen altijd 3 poorten worden gemaakt in het orkestratienetwerk (om de 3 vermelde IP-adressen te verbinden).

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

Vóór 6,3 ZK werd gebruikt om de cluster te vormen, zodat deze eis geldt voor de derde VM.

Dit voorschrift is niet gewijzigd. Voor de instellingen waarin 2 UEM VM's worden gebruikt, wordt echter een 3rd ZK-exemplaar georganiseerd op dezelfde set VM's:

Vóór 6.3 en na 6.3 in een instelling met 3 UEM-VM’s:

UEM VM1: ZK-instantie 1

UEM VM2: ZK-instantie 2

UEM VM3: ZK-instantie 3

In punt 6.3 en later, wanneer alleen 2 VM's:

UEM VM1: ZK-instantie 1 & Zk-instantie 3

UEM VM2: ZK-instantie 2

UEM VM3: niet bestaan

Zie Afbeelding 1. onderaan dit artikel voor uitgebreide grafische voorstelling.

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

Inleiding van Keepalived voor HA

Met de vorige releases werd het verkiezingsraamwerk van ZK-leiders gebruikt om de macht van EM te bepalen. Dat is niet meer het geval aangezien Cisco naar het behouden kader is overgestapt.

Wat blijft bewaard en hoe het werkt?

Hiervoor is Linux-gebaseerde software gebruikt voor taakverdeling en hoge beschikbaarheid voor Linux-systeem en Linux-gebaseerde infrastructuur.

Het wordt al gebruikt bij ESC voor HA.

In EM wordt Keepalived gebruikt om het NCS te ontkoppelen van de Zk-clusterstaat.

Het doorgevoerde proces draait alleen op de eerste twee instanties van het EM en bepaalt de status van het NCS-proces.

To check if the keepalived process is running:

ps -aef | grep keepalived

(must return the process ID)

Waarom veranderen?

In een eerdere implementatie werd de (NCS/SCM) hoofdnoopselectie nauw geïntegreerd met de Zk-clusterstatus (de eerste instantie die op de /em in de Zk-database werd vergrendeld, werd master geselecteerd). Dit creëert problemen wanneer Zk connectiviteit met het cluster verliest.

Keepalived wordt gebruikt om actief/standby UEM Cluster op VM-basis te onderhouden.

NCS onderhoudt de configuratiegegevens.

Houder houdt de operationele gegevens bij.

SCM van NCS proces decoderen

In releases voorafgaand aan 6.3 werd de SCM-component gebundeld met NCS. Dat betekent dat toen het NCS begon, het SCM ook begon (als gevolg). In deze release is dit nu losgekoppeld en SCM is een afzonderlijk proces voor zichzelf.

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 wordt alleen op hoofdknooppunt uitgevoerd

Vóór release 6.3 draaien UEM-services op zowel Master/Slave. Vanaf 6.3 draaien de diensten alleen op het hoofdknooppunt. Dit zou invloed hebben op de uitvoer die in Show ems wordt weergegeven. Vanaf 6.3 wordt verwacht dat u slechts één (master) knooppunt met deze opdracht ziet, nadat u hebt aangemeld bij de 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.

In feite zouden alle diensten op het hoofdknooppunt draaien, met uitzondering van het NCS, en dat is te wijten aan NCS-vereisten.

Dit beeld geeft de samenvatting van de mogelijke diensten en VM-distributie voor Ultra Element Manager

Stappen voor problemen met probleemoplossing bij element Manager

Tijdens het opstarten is dit de opstartvolgorde:

UEM Instellen met 2 VM's - Opstartsequentie en locatie voor loggen verwerken

Master UEM:

- behouden

- jachthandelaar

- NCS

- Arbiter (3rd) geval van Zookeeper

- VPN-proxy

- SCM

- SLA

Slaat UEM:

- behouden

- jachthandelaar

- NCS

UEM Instellen met 3 VM's - Opstartsequentie en locatie voor loggen verwerken

Master UEM:

- behouden

- jachthandelaar

- NCS

- VPN-proxy

- SCM

- SLA

Slaat UEM:

- behouden

- jachthandelaar

- NCS

3e UEM:

- jachthandelaar

Samenvatting van UEM-processen

Dit is de samenvatting van UEM processen die u moet uitvoeren.

U controleert de status met IPS-aef | grep xx

behouden

scheidsrechter

scm

slo

zoo.cfg

NCS

U kunt de status met service xx-status controleren, waarin xx:

scheidsrechter

volmacht

scm

slo

pit

NCS