Element Manager na ultra 6.3 release - architectuurwijzigingen en hoe u de problemen met betrekking tot de oplossing kunt oplossen

Downloadopties

  • PDF     (273.0 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (138.2 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (140.4 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:17 januari 2019
Document-id:214015

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

    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
    TAC Authored

    Bijgedragen door Cisco-engineers

    • Snezana Mitrovic
      Cisco TAC-engineer
    • Sourav Jyoti Das
      Cisco TAC-engineer

    Was dit document nuttig?

    FeedbackFeedback

    Contact Cisco

    Dit document is van toepassing op deze producten