Herstel van de hoge beschikbaarheid in Ultra-M Element Manager Cluster - vEPC

Downloadopties

  • PDF     (331.4 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (278.0 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (251.1 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:9 juli 2018
Document-id:213477

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

    Dit document beschrijft de stappen die vereist zijn om hoge beschikbaarheid (HA) te herstellen in element Manager (EM) cluster van een Ultra-M instelling die StarOS Virtual Network Functions (VPN’s) gastheer is.

    Achtergrondinformatie

    Ultra-M is een vooraf verpakte en gevalideerde gevirtualiseerde mobiele pakketoplossing die is ontworpen om de implementatie van VNFs te vereenvoudigen. Ultra-M oplossing bestaat uit de genoemde typen virtuele machines (VM):

    • Automatische IT 
    • Automatisch implementeren
    • Ultra Automation Services (UAS)
    • Element Manager (EM)
    • Elastic Services Controller (ESC)
    • Bedieningsfunctie (CF)
    • Sessiefunctie (SF)

    De hoge architectuur van Ultra-M en de betrokken onderdelen zijn in deze afbeelding weergegeven:

    213477-high-availability-restoration-in-ultra-m-00.pngUltraM-architectuur

     Dit document is bedoeld voor het Cisco-personeel dat bekend is met het Cisco Ultra-M platform.

    Opmerking: De Ultra M 5.1.x release wordt overwogen om de procedures in dit document te definiëren.

      

    Afkortingen

    HA Hoge beschikbaarheid
    VNF   Virtuele netwerkfunctie
    CF    Bedieningsfunctie
    SF    Service-functie
    ESC   Elastic Service Controller
    MOP   Procedure
    OSD   Objectopslaglocaties
    HDD   Station vaste schijf
    SSD   Solid State Drive
    VIM   Virtual-infrastructuurbeheer
    VM    Virtuele machine
    EM    Element Manager
    UAS   Ultra Automation Services
    UUID   Universele unieke ID-versterker



    Werkstroom van de MoP

    213477-high-availability-restoration-in-ultra-m-01.pngHoge werkstromen van de EM HA-restauratieprocedure

    Cluster status controleren

    Meld u aan bij de actieve EM en controleer de HA-status. Er zijn twee scenario's:

    1. HA-modus is geen:

    ubuntu@vnfd1deploymentem-0:~$ ncs_cli -u admin -C
    admin@scm# show ncs-state ha
     ncs-state ha mode none

    admin@scm# show ems 
    %no entries found%

    2. EM-cluster heeft slechts één knooppunt (EM-cluster bestaat uit 3 VM's):

    ubuntu@vnfd1deploymentem-0:~$ ncs_cli -u admin -C
    admin@scm# show ncs-state ha
    ncs-state ha mode master
    ncs-state ha node-id 2-1528893823

    admin@scm# show ems
    EM VNFM 
    ID SLA SCM PROXY 
    ----------------------
    2 up down down

    In beide gevallen kan de HA-staat worden hersteld met de stappen die in de volgende sectie worden genoemd.

    HA-herstartprocedure

    Identificeer de VM-namen van EM's die deel uitmaken van de cluster in de nova-lijst. Er zullen drie VM's zijn die deel uitmaken van een EM-cluster.

    [stack@director ~]$ nova list | grep vnfd1
    | e75ae5ee-2236-4ffd-a0d4-054ec246d506 | vnfd1-deployment_c1_0_13d5f181-0bd3-43e4-be2d-ada02636d870 | ACTIVE | - | Running | tmo-autovnf2-uas-orchestration=172.18.180.22; DI-INTERNAL2=192.168.2.17; DI-INTERNAL1=192.168.1.14; tmo-autovnf2-uas-management=172.18.181.23 |
    | 33c779d2-e271-47af-8ad5-6a982c79ba62 | vnfd1-deployment_c4_0_9dd6e15b-8f72-43e7-94c0-924191d99555 | ACTIVE | - | Running | tmo-autovnf2-uas-orchestration=172.18.180.13; DI-INTERNAL2=192.168.2.14; DI-INTERNAL1=192.168.1.4; tmo-autovnf2-uas-management=172.18.181.21 |
    | 65344d53-de09-4b0b-89a6-85d5cfdb3a55 | vnfd1-deployment_s2_0_b2cbf15a-3107-45c7-8edf-1afc5b787132 | ACTIVE | - | Running | SERVICE-NETWORK1=192.168.10.4, 192.168.10.9; SERVICE-NETWORK2=192.168.20.17, 192.168.20.6; tmo-autovnf2-uas-orchestration=172.18.180.12; DI-INTERNAL2=192.168.2.6; DI-INTERNAL1=192.168.1.12 |
    | e1a6762d-4e84-4a86-a1b1-84772b3368dc | vnfd1-deployment_s3_0_882cf1ed-fe7a-47a7-b833-dd3e284b3038 | ACTIVE | - | Running | SERVICE-NETWORK1=192.168.10.22, 192.168.10.14; SERVICE-NETWORK2=192.168.20.5, 192.168.20.14; tmo-autovnf2-uas-orchestration=172.18.180.14; DI-INTERNAL2=192.168.2.7; DI-INTERNAL1=192.168.1.5 |
    | b283d43c-6e0c-42e8-87d4-a3af15a61a83 | vnfd1-deployment_s5_0_672bbb00-34f2-46e7-a756-52907e1d3b3d | ACTIVE | - | Running | SERVICE-NETWORK1=192.168.10.21, 192.168.10.24; SERVICE-NETWORK2=192.168.20.21, 192.168.20.24; tmo-autovnf2-uas-orchestration=172.18.180.20; DI-INTERNAL2=192.168.2.13; DI-INTERNAL1=192.168.1.16 |
    | 637547ad-094e-4132-8613-b4d8502ec385 | vnfd1-deployment_s6_0_23cc139b-a7ca-45fb-b005-733c98ccc299 | ACTIVE | - | Running | SERVICE-NETWORK1=192.168.10.13, 192.168.10.19; SERVICE-NETWORK2=192.168.20.9, 192.168.20.22; tmo-autovnf2-uas-orchestration=172.18.180.16; DI-INTERNAL2=192.168.2.19; DI-INTERNAL1=192.168.1.21 |
    | 4169438f-6a24-4357-ad39-2a35671d29e1 | vnfd1-deployment_vnfd1-_0_02d1510d-53dd-4a14-9e21-b3b367fef5b8 | ACTIVE | - | Running | tmo-autovnf2-uas-orchestration=172.18.180.6; tmo-autovnf2-uas-management=172.18.181.8 |
    | 30431294-c3bb-43e6-9bb3-6b377aefbc3d | vnfd1-deployment_vnfd1-_0_f17989e3-302a-4681-be46-f2ebf62b252a | ACTIVE | - | Running | tmo-autovnf2-uas-orchestration=172.18.180.7; tmo-autovnf2-uas-management=172.18.181.9 |
    | 28ab33d5-7e08-45fe-8a27-dfb68cf50321 | vnfd1-deployment_vnfd1-_0_f63241f3-2516-4fc4-92f3-06e45054dba0 | ACTIVE | - | Running | tmo-autovnf2-uas-orchestration=172.18.180.3; tmo-autovnf2-uas-management=172.18.181.7 |

    Stop een van hen uit het ESC en controleer of zij in de SHUTOFF-STAAT is opgenomen.

    [admin@vnfm1-esc-0 esc-cli]$ /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP vnfd1-deployment_vnfd1-_0_02d1510d-53dd-4a14-9e21-b3b367fef5b8

    [admin@vnfm1-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
              <snip>

                    <state>SERVICE_INERT_STATE</state>
                        
       
       
         vnfd1-deployment_vnfd1-_0_02d1510d-53dd-4a14-9e21-b3b367fef5b8 
       
                        
       
       
         VM_SHUTOFF_STATE 
       
                        <vm_name>vnfd1-deployment_vnfd1-_0_f17989e3-302a-4681-be46-f2ebf62b252a</vm_name>
                        <state>VM_ALIVE_STATE</state>
                        <vm_name>vnfd1-deployment_vnfd1-_0_f63241f3-2516-4fc4-92f3-06e45054dba0</vm_name>
                        <state>VM_ALIVE_STATE</state>

    Nu, zodra EM het SHUTOFF STATE is binnengegaan, start u het andere EM opnieuw op van OpenStack Platform Director (OSPD).

    [stack@director ~]$ nova reboot --hard vnfd1-deployment_vnfd1-_0_f17989e3-302a-4681-be46-f2ebf62b252a
    Request to reboot server <Server: vnfd2-deployment_vnfd1-_0_f17989e3-302a-4681-be46-f2ebf62b252a> has been accepted.

    Meld u nogmaals aan bij de EM VIP en controleer de HA-status.

    ubuntu@vnfd1deploymentem-0:~$ ncs_cli -u admin -C
    admin@scm# show ncs-state ha
    ncs-state ha mode master
    ncs-state ha node-id 2-1528893823


    Als de HA in de "master" staat, start dan de EM die eerder Shutoff van ESC was. Else, herstart de volgende EM van de OspD en controleer de HA-status opnieuw.

    [admin@vnfm1-esc-0 esc-cli]$ /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action START vnfd1-deployment_vnfd1-_0_02d1510d-53dd-4a14-9e21-b3b367fef5b8

    [admin@vnfm1-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
              <snip>

                    <state>SERVICE_ACTIVE_STATE</state>
                        
       
       
         vnfd1-deployment_vnfd1-_0_02d1510d-53dd-4a14-9e21-b3b367fef5b8 
       
                        
       
       
         VM_ALIVE_STATE 
       
                        <vm_name>vnfd1-deployment_vnfd1-_0_f17989e3-302a-4681-be46-f2ebf62b252a</vm_name>
                        <state>VM_ALIVE_STATE</state>
                        <vm_name>vnfd1-deployment_vnfd1-_0_f63241f3-2516-4fc4-92f3-06e45054dba0</vm_name>
                        <state>VM_ALIVE_STATE</state>

    Controleer de HA-status van EM na het starten van de EM vanaf ESC. Het had hersteld moeten worden.

    admin@scm# em-ha-status 
     ha-status MASTER
    admin@scm# show ncs-state ha
     ncs-state ha mode master
     ncs-state ha node-id 4-1516609103
     ncs-state ha connected-slave [ 2-1516609363 ]
    admin@scm# show ems
     EM            VNFM   
     ID  SLA  SCM  PROXY  
     ---------------------
     2   up   up   up     
     4   up   up   up
    TAC Authored

    Bijgedragen door Cisco-engineers

    • Padmaraj Ramanoudjam
      Cisco geavanceerde services
    • Partheeban Rajagopal
      Cisco geavanceerde services

    Was dit document nuttig?

    FeedbackFeedback

    Contact Cisco

    Dit document is van toepassing op deze producten