Récupération des machines virtuelles CNAT, CUPS et 5G-UPF via UAME

Options de téléchargement

  • PDF     (130.6 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (87.4 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (78.6 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:9 décembre 2020
ID du document:216509

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

    Introduction


    Ce document décrit les informations de haut niveau sur la récupération des machines virtuelles CNAT, CUPS et 5G-UPF.

    Conditions préalables

    Conditions requises

    Cisco vous recommande de prendre connaissance des rubriques suivantes :

    • Composants des solutions Cisco Ultra Virtual Packet Core
    • Moteur UAME (Ultra Automation and Monitoring Engine)
    • Contrôleurs de service élastiques (ESC)
    • OpenStack

    Composants utilisés

    Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

    • USP 6.9.0
    • UAME 
    • ESC : 4.5.0(112)
    • StarOS : 21.15.28 (74825)
    • Cloud - Openstack 13 (Queens)

    The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

    Informations générales

    UAME (Ultra Automation and Monitoring Engine)

    L'UAME est un nouveau module de logiciel Ultra Automation Services (UAS) présenté à :

    • Prendre en charge le déploiement intégré des fonctions de réseau virtualisé 4G ou 5G et des fonctions de réseau natif en nuage 5G.

    • Réduisez le nombre de machines virtuelles (VM) généralement requises par USP et UAS, en remplaçant les composants UEM, AutoIT, AutoDeploy et AutoVNF.

    L'UAME assure l'orchestration du déploiement pour les éléments suivants :

    • 4 GVNF :

      • VNF CUPS : L'UAME travaille avec Virtual Network Function Manager (VNFM) pour déployer les VNF du plan de contrôle basé sur SI VPC et du plan utilisateur (UP) pour prendre en charge l'architecture CUPS (Control and User Plane Separation).

      • VNF non CUPS : L'UAME est rétrocompatible, travaillant avec le VNFM pour fournir une prise en charge du déploiement des passerelles 4G non CUPS (basées sur VPC-DI) et de la fonction PCRF (Policy and Charging Rules Function) 4G.

    • NF 5G :

      • NF basés sur VNF :l'UAME travaille avec le VNFM pour déployer des NF basés sur VPC-SI.

      • NF basés sur le cloud natif :l'UAME interagit avec le VNFM pour déployer l'infrastructure de microservices d'abonné Ultra Cloud Core (SMI). Le SMI travaille ensuite avec le VNFM pour déployer des NF dans un cluster Kubernetes basé sur des machines virtuelles (également appelé K8s).

    Contrôleur de services élastiques (ESC)

    ESC est le VNFM mentionné dans cet article qui est actuellement la seule plate-forme prise en charge.

    Problème 

    Les machines virtuelles hébergeant des machines virtuelles SMI 5G natives du cloud sont en état d'ERREUR dans ESC.

    crucs502-cnat-cn_oam1_0_d7f90c1e-4401-4be9-87f6-f39ecf04ea3a   VM_ERROR_STATE 
    crucs502-cnat-cn_master_0_05487525-c86f-47e1-a07e-fd33720d114f VM_ERROR_STATE 
    crucs502-4g-CRPC_CRPCF5_0_ee07bf60-a8f8-405f-9a0d-cfa7363e32e7 VM_ERROR_STATE

    Procédure de récupération des machines virtuelles

    Vérifiez l'état de la machine virtuelle dans UAME et ESC. démarrer le processus de récupération à partir de l'ESC. Si l'ESC ne peut pas récupérer la machine virtuelle, redéployez-la à partir de l'UAME.

    Étape 1. Vérifiez l'état de la machine virtuelle à partir de UAME.

    Connectez-vous à UAME, accédez à l'interface de ligne de commande confd, puis vérifiez l'état comme indiqué ici.


    ubuntu@crucs502-uame-1:~$ /opt/cisco/usp/uas/confd-6.3.8/bin/confd_cli -u admin -C
    Enter Password for 'admin': 
    elcome to the ConfD CLI
    admin connected from 10.249.80.137 using ssh on crucs502-uame-1
    crucs502-uame-1#
    crucs502-uame-1#show vnfr state
    VNFR ID STATE 
    ---------------------------------
    crucs502-4g-CRPCF504 alive 
    crucs502-4g-CRPCF505 alive 
    crucs502-4g-CRPCF506 alive 
    crucs502-4g-CRPCF507 error 
    crucs502-4g-CRPCF604 alive 
    crucs502-cnat-cnat error

    Étape 2. Récupérez les machines virtuelles à partir de l'ESC.

    Essayez de récupérer de l'ESC manuellement.

    Chauffeur

    Note: La récupération peut prendre jusqu'à 900 (15 min).

    bootup_time 300
    recovery_wait_time 600

    Connectez-vous à l'ESC maître, vérifiez l'état, puis exécutez les commandes de récupération comme indiqué ici.

    Last login: Wed May 13 02:07:42 2020 from 10.x.x.x

####################################################################
# ESC on crucs502-esc-vnf-esc-core-esc-1 is in MASTER state.
####################################################################


[admin@crucs502-esc-vnf-esc-core-esc-1 ~]$ health.sh
============== ESC HA (MASTER) with DRBD =================
vimmanager (pgid 14643) is running
monitor (pgid 14712) is running
mona (pgid 14768) is running
drbd (pgid 0) is master
snmp is disabled at startup
etsi is disabled at startup
pgsql (pgid 15119) is running
keepalived (pgid 14070) is running
portal is disabled at startup
confd (pgid 15016) is running
filesystem (pgid 0) is running
escmanager (pgid 15254) is running
=======================================
ESC HEALTH PASSED


/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO crucs502-cnat-cn_oam1_0_d7f90c1e-4401-4be9-87f6-f39ecf04ea3a
    tail -50f /var/log/esc/yangesc.log

    2020-05-05 02:29:01.534 WARN ===== SEND NOTIFICATION STARTS =====
    2020-05-05 02:29:01.534 WARN Type: VM_RECOVERY_COMPLETE
    2020-05-05 02:29:01.534 WARN Status: SUCCESS
    2020-05-05 02:29:01.534 WARN Status Code: 200
    2020-05-05 02:29:01.534 WARN Status Msg: Recovery: Successfully recovered VM [crucs502-cnat-cn_oam1_0_d7f90c1e-4401-4be9-87f6-f39ecf04ea3a].
    2020-05-05 02:29:01.534 WARN Tenant: core
    2020-05-05 02:29:01.534 WARN Deployment name: crucs502-cnat-cnat-core
    2020-05-05 02:29:01.534 WARN VM group name: oam1
    <output trimmed>

    /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO crucs502-cnat-cn_master_0_05487525-c86f-47e1-a07e-fd33720d114f
    tail -50f /var/log/esc/yangesc.log

    2020-05-05 02:12:51.512 WARN ===== SEND NOTIFICATION STARTS =====
    2020-05-05 02:12:51.512 WARN Type: VM_RECOVERY_COMPLETE
    2020-05-05 02:12:51.512 WARN Status: SUCCESS
    2020-05-05 02:12:51.512 WARN Status Code: 200
    2020-05-05 02:12:51.512 WARN Status Msg: Recovery: Successfully recovered VM [crucs502-cnat-cn_master_0_05487525-c86f-47e1-a07e-fd33720d114f].
    2020-05-05 02:12:51.512 WARN Tenant: core
    2020-05-05 02:12:51.512 WARN Deployment name: crucs502-cnat-cnat-core
    <output trimmed>

    Étape 3. Vérifiez si la récupération a réussi.

    Vérifiez les journaux de yangesc (tail -50f /var/log/esc/yangesc.log) et recherchez Status and Recovery comme indiqué ci-dessus. S'il réussit, accédez à l'interface de ligne de commande confd et vérifiez.

    [admin@crucs502-esc-vnf-esc-core-esc-1 ~]$ /opt/cisco/esc/confd/bin/confd_cli -u admin -C

    admin connected from 10.249.80.137 using ssh on crucs502-esc-vnf-esc-core-esc-1


    crucs502-esc-vnf-esc-core-esc-1# show esc_datamodel opdata tenants tenant | select deployments state_machine
    NAME DEPLOYMENT NAME STATE VM NAME STATE 
    -------------------------------------------------------------------------------------------------------------------------------------------
    <trucated output>
    crucs502-cnat-cn_etcd2_0_7263c87c-ee62-4b81-8e1e-a0f5c463a5b5 VM_ALIVE_STATE 
    crucs502-cnat-cn_etcd3_0_512ef3c0-96a2-4a10-83b0-4c7d13805856 VM_ALIVE_STATE 
    crucs502-cnat-cn_master_0_05487525-c86f-47e1-a07e-fd33720d114f VM_ALIVE_STATE 
    crucs502-cnat-cn_master_0_8cf66daa-9dfe-4c7e-817e-36624f9c98c2 VM_ALIVE_STATE 
    crucs502-cnat-cn_master_0_dff4ad36-7982-4131-a737-ccb6c8eae348 VM_ALIVE_STATE 
    crucs502-cnat-cn_oam1_0_d7f90c1e-4401-4be9-87f6-f39ecf04ea3a VM_ALIVE_STATE

    Récupération réussie

    When ESC shows VM_ALIVE_STATE, verify the status in UAME

    crucs502-uame-1#show vnfr state
    VNFR ID STATE 
    ---------------------------------
    crucs502-4g-CRPCF504 alive 
    crucs502-4g-CRPCF505 alive 
    crucs502-4g-CRPCF506 alive 
    crucs502-4g-CRPCF507 alive 
    crucs502-4g-CRPCF604 alive 
    crucs502-4g-CRPCF605 alive 
    crucs502-4g-CRPCF606 alive 
    crucs502-4g-CRPCF607 alive 
    crucs502-4g-CRPGW502 alive 
    crucs502-4g-CRPGW503 alive 
    crucs502-4g-CRPGW608 alive 
    crucs502-4g-CRPGW609 alive 
    crucs502-4g-CRPGW610 alive 
    crucs502-4g-CRPGW611 alive 
    crucs502-4g-CRPGW612 alive 
    crucs502-4g-CRPGW613 alive 
    crucs502-4g-CRPGW614 alive 
    crucs502-4g-CRPGW615 alive 
    crucs502-4g-CRSGW606 alive 
    crucs502-4g-CRSGW607 alive 
    crucs502-4g-CRSGW608 alive 
    crucs502-4g-CRSGW609 alive 
    crucs502-4g-CRSGW610 alive 
    crucs502-4g-CRSGW611 alive 
    crucs502-5g-upf-CRUPF014 alive 
    crucs502-5g-upf-CRUPF015 alive 
    crucs502-5g-upf-CRUPF016 alive 
    crucs502-5g-upf-CRUPF017 alive 
    crucs502-5g-upf-CRUPF018 alive 
    crucs502-5g-upf-CRUPF019 alive 
    crucs502-5g-upf-CRUPF020 alive 
    crucs502-5g-upf-CRUPF021 alive 
    crucs502-5g-upf-CRUPF022 alive 
    crucs502-5g-upf-CRUPF023 alive 
    crucs502-5g-upf-CRUPF024 alive 
    crucs502-5g-upf-CRUPF025 alive 
    crucs502-5g-upf-CRUPF026 alive 
    crucs502-5g-upf-CRUPF027 alive 
    crucs502-cnat-cnat alive 
    crucs502-cnat-smi-cm alive 
    crucs502-esc-vnf-esc alive 


    verify the same in openstack (source the correct overcloud rc file)

    (crucs502) [stack@crucs502-ospd ~]$ nova list --fields name,status,host |egrep "CRPCF507|cnat"

    <truncated output>
    | 3eb43fe7-9f41-42d8-afe4-80f6fd62c385 | crucs502-4g-CRPCF507-core-CRPCF5071 | ACTIVE | crucs502-compute-11.localdomain |
    | cc678283-2967-4404-a714-e4dd78000e82 | crucs502-cnat-cnat-core-etcd1 | ACTIVE | crucs502-osd-compute-0.localdomain |
    | 711d6fcd-b816-49d4-a702-e993765757b0 | crucs502-cnat-cnat-core-master3 | ACTIVE | crucs502-osd-compute-3.localdomain |
    | 46f64bde-a8db-48f2-bf3d-fe3b01295f2f | crucs502-cnat-cnat-core-oam1 | ACTIVE | crucs502-osd-compute-3.localdomain |
    | f470ba3d-813e-434b-aac8-78bc646fda22 | crucs502-cnat-cnat-core-oam2 | ACTIVE | crucs502-osd-compute-2.localdomain |

    Échec de la récupération

    Cet exemple montre un cas d'échec de récupération de l'ESC. Dans ce cas, la VM est redéployée à partir de UAME.

    /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO crucs502-4g-CRPC_CRPCF5_0_ee07bf60-a8f8-405f-9a0d-cfa7363e32e7

    Cette sortie affiche le message d'échec dans yangesc.log

    tail -50f /var/log/esc/yangesc.log

    2020-05-05 02:57:21.143 WARN ===== SEND NOTIFICATION STARTS =====
    2020-05-05 02:57:21.143 WARN Type: VM_RECOVERY_INIT
    2020-05-05 02:57:21.143 WARN Status: SUCCESS
    2020-05-05 02:57:21.143 WARN Status Code: 200
    2020-05-05 02:57:21.143 WARN Status Msg: Recovery event for VM Generated ID [crucs502-4g-CRPC_CRPCF5_0_ee07bf60-a8f8-405f-9a0d-cfa7363e32e7] triggered.
    2020-05-05 02:57:21.143 WARN Tenant: core
    2020-05-05 02:57:21.143 WARN Deployment name: crucs502-4g-CRPCF507-core
    2020-05-05 02:57:21.143 WARN VM group name: CRPCF5071
    <output trimmed>


    2020-05-05 02:57:21.144 WARN ===== SEND NOTIFICATION ENDS =====
    2020-05-05 03:09:21.655 WARN 
    2020-05-05 03:09:21.655 WARN ===== SEND NOTIFICATION STARTS =====
    2020-05-05 03:09:21.655 WARN Type: VM_RECOVERY_REBOOT
    2020-05-05 03:09:21.655 WARN Status: SUCCESS
    2020-05-05 03:09:21.655 WARN Status Code: 200
    2020-05-05 03:09:21.655 WARN Status Msg: VM Generated ID [crucs502-4g-CRPC_CRPCF5_0_ee07bf60-a8f8-405f-9a0d-cfa7363e32e7] is rebooted.
    2020-05-05 03:09:21.655 WARN Tenant: core
    2020-05-05 03:09:21.655 WARN Deployment name: crucs502-4g-CRPCF507-core
    2020-05-05 03:09:21.655 WARN VM group name: CRPCF5071
    <output trimmed>


    2020-05-05 03:09:21.656 WARN ===== SEND NOTIFICATION ENDS =====
    2020-05-05 03:14:22.079 WARN 
    2020-05-05 03:14:22.079 WARN ===== SEND NOTIFICATION STARTS =====
    2020-05-05 03:14:22.079 WARN Type: VM_RECOVERY_COMPLETE
    2020-05-05 03:14:22.079 WARN Status: FAILURE
    2020-05-05 03:14:22.079 WARN Status Code: 500
    2020-05-05 03:14:22.079 WARN Status Msg: Recovery: Recovery completed with errors for VM: [crucs502-4g-CRPC_CRPCF5_0_ee07bf60-a8f8-405f-9a0d-cfa7363e32e7]
    2020-05-05 03:14:22.079 WARN Tenant: core
    2020-05-05 03:14:22.079 WARN Deployment name: crucs502-4g-CRPCF507-core
    2020-05-05 03:14:22.079 WARN VM group name: CRPCF5071
    <output trimmed>

    Vérifier la politique de récupération de l'ESC

    Dans ESC, la méthode de récupération est redémarrée uniquement. Ceci montre que la machine virtuelle n'a pas pu être ramenée avec un redémarrage, besoin de redéployer.

    crucs502-esc-vnf-esc-core-esc-1# show running-config | include recovery_policy 
    recovery_policy recovery_type AUTO
    recovery_policy action_on_recovery REBOOT_ONLY
    recovery_policy max_retries 1

    Confirmer à nouveau l'état de la machine virtuelle dans UAME

    Chauffeur
    Remarque importante : le redéploiement est fourni avec la configuration day0. La configuration Day1 doit être chargée séparément. 
    ubuntu@crucs502-uame-1:~$ /opt/cisco/usp/uas/confd-6.3.8/bin/confd_cli -u admin -C
    Enter Password for 'admin': 
    elcome to the ConfD CLI
    admin connected from 10.249.80.137 using ssh on crucs502-uame-1
    crucs502-uame-1#

    crucs502-uame-1#
    crucs502-uame-1#show vnfr state
    VNFR ID STATE 
    ---------------------------------
    crucs502-4g-CRPCF504 alive 
    crucs502-4g-CRPCF505 alive 
    crucs502-4g-CRPCF506 alive 
    crucs502-4g-CRPCF507 error
    crucs502-4g-CRPCF604 alive

    Étape 4. Redéployer les machines virtuelles.

    Redéployer les machines virtuelles à partir de UAME

    crucs502-uame-1# recover nsd-id crucs502-4g vnfd CRPCF507 recovery-action redeploy

    Inspecter les journaux de redéploiement

    Afficher les journaux UAME et ESC. Ce processus peut prendre jusqu'à 15 minutes.

    Journaux UAME :

    tail -50f /var/log/upstart /uame/log
    <truncated output>
    2020-05-06 08:57:22,252 - | VM_RECOVERY_DEPLOYED | CRPCF5071 | SUCCESS | Waiting for: VM_RECOVERY_COMPLETE|
    2020-05-06 08:57:22,255 - Timing out in 143 seconds
    2020-05-06 08:57:48,227 - | VM_RECOVERY_COMPLETE | crucs502-4g-CRPC_CRPCF5_0_ee07bf60-a8f8-405f-9a0d-cfa7363e32e7 | SUCCESS | (1/1)
    2020-05-06 08:57:48,229 - NETCONF transaction completed successfully!
    2020-05-06 08:57:48,231 - Released lock: esc_vnf_req
    2020-05-06 08:57:48,347 - Deployment recover-vnf-deployment: crucs502-4g succeeded
    2020-05-06 08:57:48,354 - Send Deployment notification for: crucs502-4g-CRPCF507

    Journaux ESC :

    tail -50f /var/log/esc/yangesc.log
    2020-05-06 08:58:01.454 WARN Type: VM_RECOVERY_COMPLETE
    2020-05-06 08:58:01.454 WARN Status: SUCCESS
    2020-05-06 08:58:01.454 WARN Status Code: 200
    2020-05-06 08:58:01.454 WARN Status Msg: Recovery: Successfully recovered VM [crucs502-4g-CRPC_CRPCF5_0_ee07bf60-a8f8-405f-9a0d-cfa7363e32e7].
    2020-05-06 08:58:01.454 WARN Tenant: core
    2020-05-06 08:58:01.454 WARN Deployment ID: 4f958c43-dfa4-45d4-a69d-76289620c337
    2020-05-06 08:58:01.454 WARN Deployment name: crucs502-4g-CRPCF507-core
    2020-05-06 08:58:01.454 WARN VM group name: CRPCF5071
    <output trimmed>

    Vérifiez l'état de la machine virtuelle. Suivez la procédure décrite à l'étape 3.

    TAC Authored

    Contribution d’experts de Cisco

    • Adityan Arathi
      Cisco TAC Engineer

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits