Restauration haute disponibilité dans le cluster Ultra-M Element Manager - vEPC

Introduction

Ce document décrit les étapes requises pour restaurer la haute disponibilité (HA) dans le cluster Element Manager (EM) d'une configuration Ultra-M qui héberge les fonctions de réseau virtuel (VNF) de StarOS.

Informations générales

Ultra-M est une solution de coeur de réseau de paquets mobiles virtualisés prépackagée et validée conçue pour simplifier le déploiement des VNF. La solution Ultra-M se compose des types de machines virtuelles mentionnés :

• IT automatique 
• Déploiement automatique
• Ultra Automation Services (UAS)
• Gestionnaire d'éléments (EM)
• Contrôleur de services élastiques (ESC)
• Fonction de contrôle (CF)
• Fonction de session (SF)

L'architecture de haut niveau d'Ultra-M et les composants impliqués sont représentés dans cette image :

Architecture UltraM

 Ce document est destiné au personnel Cisco qui connaît la plate-forme Cisco Ultra-M.

Note: La version Ultra M 5.1.x est prise en compte afin de définir les procédures de ce document.

  

Abréviations

HA	Haute disponibilité
VNF	Fonction de réseau virtuel
FC	Fonction de contrôle
SF	Fonction de service
Échap	Contrôleur de service flexible
MOP	Méthode de procédure
OSD	Disques de stockage d'objets
HDD	Disque dur
SSD	Disque dur SSD
VIM	Gestionnaire d'infrastructure virtuelle
VM	Machine virtuelle
EM	Gestionnaire d'éléments
UAS	Services d’automatisation ultra
UUID	Identificateur unique

Flux de travail du MoP

Workflow de haut niveau de la procédure de restauration EM HA

Vérifier l'état du cluster

Connectez-vous au module EM actif et vérifiez l'état de la haute disponibilité. Il peut y avoir deux scénarios :

1. Le mode HA n'est pas :

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. Le cluster EM n'a qu'un noeud (le cluster EM se compose de 3 machines virtuelles) :

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 

Dans les deux cas, l'état HA peut être restauré par les étapes mentionnées dans la section suivante.

Procédure de restauration HA

Identifiez les noms des machines virtuelles des EM qui font partie du cluster dans la liste nova. Trois machines virtuelles font partie d'un cluster EM.

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

Arrêtez l'un des EM de l'ESC et vérifiez s'il est entré dans l'ÉTAT SHUTOFF.

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

Maintenant, une fois que le module EM est entré dans l'ÉTAT SHUTOFF, redémarrez l'autre module EM à partir de l'OSPD (OpenStack Platform Director).

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

Connectez-vous à nouveau au processeur VIP EM et vérifiez l'état de la haute disponibilité.

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

Si la HA est en état « maître », démarrez le module EM qui était précédemment Shutoff de l'ESC. Sinon, redémarrez le prochain module EM à partir d'OSPD, puis vérifiez à nouveau l'état HA.

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

Après avoir démarré le module EM à partir de l'ESC, vérifiez l'état HA du module EM. Elle aurait dû être restaurée.

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