Procédure de récupération en cas de défaillance du cluster Ultra-M AutoVNF - vEPC
Table des matières
Introduction
Ce document décrit les étapes requises pour récupérer la défaillance du cluster Ultra Automation Services (UAS) ou AutoVNF dans une configuration Ultra-M qui héberge des fonctions de réseau virtuel (VNF) StarOS.
Informations générales
Ultra-M est une solution de coeur de réseau de paquets mobile virtualisée préemballée et validée, conçue pour simplifier le déploiement des VNF.
La solution Ultra-M se compose des types de machine virtuelle (VM) mentionnés :
- Auto-IT
- Déploiement automatique
- UAS ou AutoVNF
- 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 bien la plate-forme Cisco Ultra-M.
Abréviations
| VNF | Fonction de réseau virtuel |
| CF | Fonction De Commande |
| SF | Fonction de service |
| ESC | Contrôleur de service élastique |
| SERPILLIÈRE | 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 |
| SAMU | Services d’automatisation ultra |
| UUID | Identificateur Universally Unique |
Flux de travail de la musique d'attente
Cas 1. Récupération d'une défaillance unique du cluster UAS
Vérification du statut
1. Ultra-M Manager effectue le contrôle d'intégrité du noeud Ultra-M. Accédez au répertoire /var/log/cisco/ultram-health/ et au grep du rapport UAS.
-
[stack@pod1-ospd ultram-health]$ more ultram_health_uas.report
---------------------------------------------------------------------------------------------------------
VNF ID | UAS Node | Status | Error Info, if any
---------------------------------------------------------------------------------------------------------
172.21.201.122 | autovnf | XXX | AutoVNF Cluster FAILED : Node: 172.16.180.12, Status: error, Role: NA
172.21.201.122 | vnf-em | :-) |
172.21.201.122 | esc | :-) |
---------------------------------------------------------------------------------------------------------
2. L'état prévu du groupe UAS sera celui représenté, où les trois UAS sont vivants.
[stack@pod1-ospd ~]# ssh ubuntu@10.1.1.1
password:
ubuntu@autovnf1-uas:~$ ncs_cli -u admin -C
autovnf1-uas-0#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP STATE ROLE
------------------------------------
172.16.180.3 alive CONFD-MASTER
172.16.180.7 alive CONFD-SLAVE
172.16.180.12 alive NA
Échec de la connexion au serveur Confd lorsque vous essayez de vous connecter à UAS
1. Dans certains cas, vous ne pourrez pas vous connecter au serveur confd.
ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ confd_cli -u admin -C
Failed to connect to server
2. Vérifiez le statut du processus uas-confd.
ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ sudo initctl status uas-confd
uas-confd stop/waiting
3. Si le serveur confd ne fonctionne pas, redémarrez le service.
ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ sudo initctl start uas-confd
uas-confd start/running, process 7970
ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 172.16.180.9 using ssh on autovnf1-uas-0
Récupérer UAS de l'état d'erreur
1. En cas de défaillance d'un AutoVNF dans le cluster, le cluster UAS affiche l'un des UAS dans l'état Erreur .
[stack@pod1-ospd ~]# ssh ubuntu@10.1.1.1
password:
ubuntu@autovnf1-uas:~$ ncs_cli -u admin -C
autovnf1-uas-0#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP STATE ROLE
------------------------------------
172.16.180.3 alive CONFD-MASTER
172.16.180.7 alive CONFD-SLAVE
172.16.180.12 alive error
2. Copiez le bon fichier (rc file of your VNF) de /home/stack dans le serveur OSPD vers AutoDeploy et envoyez-le.
3. Vérifiez l'état de votre UAS/AutoVNF à l'aide du script uas-check.py . autovnf1 est le nom AutoVNF.
ubuntu@auto-deploy-iso-590-uas-0:~$ /opt/cisco/usp/apps/auto-it/scripts/uas-check.py auto-vnf autovnf1
2017-11-17 14:52:20,186 - INFO: Check of AutoVNF cluster started
2017-11-17 14:52:22,172 - INFO: Found 2 AutoVNF instance(s), 3 expected
2017-11-17 14:52:22,172 - INFO: Instance 'autovnf1-uas-2' is missing
2017-11-17 14:52:22,172 - INFO: Check completed, AutoVNF cluster has recoverable errors
4. Récupérez l'UAS à l'aide du script uas-check.py et ajoutez le mot clé —fix.
ubuntu@auto-deploy-iso-590-uas-0:~$ /opt/cisco/usp/apps/auto-it/scripts/uas-check.py auto-vnf autovnf1 --fix
2017-11-17 14:52:27,493 - INFO: Check of AutoVNF cluster started
2017-11-17 14:52:29,215 - INFO: Found 2 AutoVNF instance(s), 3 expected
2017-11-17 14:52:29,215 - INFO: Instance 'autovnf1-uas-2' is missing
2017-11-17 14:52:29,215 - INFO: Check completed, AutoVNF cluster has recoverable errors
2017-11-17 14:52:29,386 - INFO: Creating instance 'autovnf1-uas-2' and attaching volume 'autovnf1-uas-vol-2'
2017-11-17 14:52:47,600 - INFO: Created instance 'autovnf1-uas-2'
5. Vous verrez que le système d'accès aux services utilisateur nouvellement créé est actif et fait partie du cluster.
autovnf1-uas-0#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP STATE ROLE
------------------------------------
172.16.180.3 alive CONFD-MASTER
172.16.180.7 alive CONFD-SLAVE
172.16.180.13 alive NA
Cas 2. Les trois UAS (AutoVNF) sont en état d’erreur
1. Ultra-M Manager effectue le contrôle d'intégrité du noeud Ultra-M.
[stack@pod1-ospd ultram-health]$ more ultram_health_uas.report
---------------------------------------------------------------------------------------------------------
VNF ID | UAS Node | Status | Error Info, if any
---------------------------------------------------------------------------------------------------------
172.21.201.122 | autovnf | XXX | AutoVNF Cluster FAILED : Node: 172.16.180.12, Status: error, Role: NA,Node: 172.16.180.9, Status: error, Role: NA,Node: 172.16.180.10, Status: error, Role: NA
172.21.201.122 | vnf-em | :-) |
172.21.201.122 | esc | :-) |
---------------------------------------------------------------------------------------------------------
2. Comme indiqué dans le résultat, le gestionnaire Ultra-M signale une défaillance d'AutoVNF et indique que les trois UAS du cluster sont à l'état Erreur.
Vérifiez l'état de santé de l'UAS avec le script uas-check.py
1. Connectez-vous au déploiement automatique et vérifiez si vous pouvez accéder au système UAS AutoVNF et obtenir l'état.
ubuntu@auto-deploy-iso-590-uas-0:~$ /opt/cisco/usp/apps/auto-it/scripts$ ./uas-check.py auto-vnf autovnf1 --os-tenant-name core
2017-12-05 11:41:09,834 - INFO: Check of AutoVNF cluster started
2017-12-05 11:41:11,342 - INFO: Found 3 ACTIVE AutoVNF instances
2017-12-05 11:41:11,343 - INFO: Check completed, AutoVNF cluster is fine
2. À partir du noeud Auto-Deploy, Secure Shell (SSH) vers AutoVNF et passez en mode confd. Vérifiez l'état avec show uas.
ubuntu@auto-deploy-iso-590-uas-0:~$ ssh ubuntu@172.16.180.9
password:
autovnf1-uas-1#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP STATE ROLE
----------------------------
172.16.180.9 error NA
172.16.180.10 error NA
172.16.180.12 error NA
3. Il est recommandé de vérifier l’état des trois noeuds UAS.
Vérifier l'état des machines virtuelles au niveau d'OpenStack
Vérifiez l'état des machines virtuelles AutoVNF dans la liste nova. Si nécessaire, exécutez nova start afin de démarrer la VM d'arrêt.
[stack@pod1-ospd ultram-health]$ nova list | grep autovnf
| 83870eed-b4e9-47b3-976d-cc3eddecf866 | autovnf1-uas-0 | ACTIVE | - | Running | orchestr=172.16.180.12; mgmt=172.16.181.6
| 201d9ce5-538c-42f7-a46c-fc8cdef1eabf | autovnf1-uas-1 | ACTIVE | - | Running | orchestr=172.16.180.10; mgmt=172.16.181.5
| 6c6d25cd-21b6-42b9-87ff-286220faa2ff | autovnf1-uas-2 | ACTIVE | - | Running | orchestr=172.16.180.9; mgmt=172.16.181.13
Vérifier la vue du gardien de zoo
1. Vérifiez l'état du gardien de zoo afin de vérifier le mode en tant que chef.
ubuntu@autovnf1-uas-0:/var/log/upstart$ /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
2. Le gardien de zoo devrait normalement être activé.
Dépannage d'AutoVNF - Processus et tâches
1. Identifiez la raison de l'état Erreur des noeuds. Pour qu'AutoVNF s'exécute, un ensemble de processus doit être actif et en cours d'exécution, comme illustré :
AutoVNF
uws-ae
uas-confd
cluster_manager
uas_manager
ubuntu@autovnf1-uas-0:~$ sudo initctl list | grep uas
uas-confd stop/waiting ====> this is not good, the uas-confd process is not running
uas_manager start/running, process 2143
root@autovnf1-uas-1:/home/ubuntu# sudo initctl list
....
uas-confd start/running, process 1780
....
autovnf start/running, process 1908
....
....
uws-ae start/running, process 1909
....
....
cluster_manager start/running, process 1827
....
.....
uas_manager start/running, process 1697
......
......
2. Vérifiez que ces processus python sont en cours d'exécution :
uas_manager.py
cluster_manager.py
usp_autovnf.py
root@autovnf1-uas-1:/home/ubuntu# ps -aef | grep pyth
root 1819 1697 0 Jun13 ? 00:00:50 python /opt/cisco/usp/uas/manager/uas_manager.py
root 1858 1827 0 Jun13 ? 00:09:21 python /opt/cisco/usp/uas/manager/cluster_manager.py
root 1908 1 0 Jun13 ? 00:01:00 python /opt/cisco/usp/uas/autovnf/usp_autovnf.py
root 25662 24750 0 13:16 pts/7 00:00:00 grep --color=auto pyth
3. Si l'un des processus attendus n'est pas à l'état start/running, redémarrez le processus et vérifiez son état. Si l'état d'erreur est toujours affiché, suivez la procédure mentionnée dans la section suivante afin de résoudre ce problème.
Correction pour plusieurs UAS en état d'erreur
1. nova —hard reboot <nom de la VM> à partir d'OSPD, donnez un peu de temps pour la récupération de cette VM avant de passer au prochain UAS. Effectuez cette opération sur toutes les machines virtuelles UAS.
ou
2. Connectez-vous à chaque UAS et utilisez sudo reboot. Attendez la récupération, puis passez aux autres VM UAS.
Pour les journaux de transactions, vérifiez :
/var/log/upstart/autovnf.log
show logs xxx | display xml
Cela permet de résoudre le problème et de récupérer le système UAS à partir de l'état Erreur.
1. Vérifiez la même chose à l'aide du rapport ultram_health_check.
[stack@pod1-ospd ultram-health]$ more ultram_health_uas.report
---------------------------------------------------------------------------------------------------------
VNF ID | UAS Node | Status | Error Info, if any
---------------------------------------------------------------------------------------------------------
172.21.201.122 | autovnf | :-) |
172.21.201.122 | vnf-em | :-) |
172.21.201.122 | esc | :-) |
---------------------------------------------------------------------------------------------------------
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)