Inhalt

Einführung

Hintergrundinformationen

Abkürzungen

Workflow des MoP

Cluster-Status überprüfen

HA-Wiederherstellungsverfahren

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