Hochverfügbarkeitswiederherstellung im Ultra-M-Element-Manager-Cluster - vEPC

Einführung

In diesem Dokument werden die Schritte beschrieben, die erforderlich sind, um im Element Manager (EM)-Cluster einer Ultra-M-Konfiguration, die StarOS Virtual Network Functions (VNFs) hostet, die Hochverfügbarkeit (HA) wiederherzustellen.

Hintergrundinformationen

Ultra-M ist eine vorkonfigurierte und validierte Kernlösung für virtualisierte mobile Pakete, die die Bereitstellung von VNFs vereinfacht. Die Ultra-M-Lösung besteht aus den genannten VM-Typen:

• Auto-IT 
• Automatische Bereitstellung
• Ultra Automation Services (UAS)
• Element Manager (EM)
• Elastic Services Controller (ESC)
• Kontrollfunktion (CF)
• Sitzungsfunktion (SF)

Die High-Level-Architektur von Ultra-M und die beteiligten Komponenten sind in diesem Bild dargestellt:

UltraM-Architektur

 Dieses Dokument richtet sich an Mitarbeiter von Cisco, die mit der Cisco Ultra-M-Plattform vertraut sind.

Hinweis: Ultra M 5.1.x wird zur Definition der Verfahren in diesem Dokument berücksichtigt.

  

Abkürzungen

HA	Hohe Verfügbarkeit
VNF	Virtuelle Netzwerkfunktion
CF	Kontrollfunktion
SF	Servicefunktion
WSA	Elastic Service Controller
MOP	Verfahrensweise
OSD	Objektspeicherdatenträger
HDD	Festplattenlaufwerk
SSD	Solid-State-Laufwerk
VIM	Virtueller Infrastrukturmanager
VM	Virtuelles System
EM	Element Manager
USA	Ultra-Automatisierungsservices
UUID	Universell eindeutige IDentifier

Workflow des MoP

Allgemeiner Workflow des EM HA-Wiederherstellungsverfahrens

Cluster-Status überprüfen

Melden Sie sich beim aktiven EM an, und überprüfen Sie den HA-Status. Es gibt zwei Szenarien:

1. Der HA-Modus ist nicht:

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 hat nur einen Knoten (EM-Cluster besteht aus 3 VMs):

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 beiden Fällen kann der HA-Status mithilfe der im nächsten Abschnitt beschriebenen Schritte wiederhergestellt werden.

HA-Wiederherstellungsverfahren

Identifizieren Sie die VM-Namen von EMs, die Teil des Clusters sind, aus der Nova-Liste. Es gibt drei VMs, die Teil eines EM-Clusters sind.

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

Beenden Sie eines der EM aus dem ESC, und prüfen Sie, ob es in den SHUTOFF-STATE eingegeben wurde.

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

Nachdem das EM in den SHUTOFF-ZUSTAND gelangt ist, starten Sie das andere EM über den OpenStack Platform Director (OSPD) neu.

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

Melden Sie sich erneut beim EM VIP an, und überprüfen Sie den 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

Wenn sich die HA im Master-Status befindet, starten Sie das EM, das zuvor vom ESC abgeschaltet wurde. Fahren Sie andernfalls mit dem Neustart des nächsten EM von OSPD fort, und überprüfen Sie dann erneut den HA-Status.

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

Nachdem Sie das EM vom ESC aus gestartet haben, überprüfen Sie den HA-Status von EM. Es hätte wiederhergestellt werden sollen.

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