CNAT VMs, CUPS VMs und 5G-UPF VMs Recovery durch UAME

Download-Optionen

  • PDF     (130.4 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (86.5 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (77.3 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:9. Dezember 2020
Dokument-ID:216509

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

    Einführung


    Dieses Dokument beschreibt die allgemeinen Informationen zur Wiederherstellung von CNAT VMs, CUPS VMs und 5G-UPF VMs.

    Voraussetzungen

    Anforderungen

    Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

    • Komponenten der Cisco Ultra Virtual Packet Core-Lösungen
    • Ultra Automation and Monitoring Engine (UAME)
    • Elastic Service Controller (ESC)
    • OpenStack

    Verwendete Komponenten

    Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

    • USP 6.9.0
    • UAME 
    • ESC: 112
    • StarOS: 21,15,28 (74825)
    • Cloud - OpenStack 13 (Queens)

    Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

    Hintergrundinformationen

    Ultra Automation and Monitoring Engine (UAME)

    UAME ist ein neues Softwaremodul für Ultra Automation Services (UAS), das eingeführt wurde, um:

    • Unterstützung der integrierten Bereitstellung von VNFs (Virtualized Network Functions) der Serien 4G oder 5G und 5G Cloud-Native Network Functions (CNFs)

    • Reduzieren Sie die Anzahl der virtuellen Systeme (VMs), die normalerweise für USP und UAS erforderlich sind, und ersetzen Sie die Komponenten UEM, AutoIT, AutoDeploy und AutoVNF.

    Das UAME ermöglicht die Orchestrierung der Bereitstellung für:

    • 4GVNFs:

      • CUPS-basierte VNFs: Das UAME verwendet den Virtual Network Function Manager (VNFM), um VPC SI-basierte Kontrollebenen (CP) und VNFs auf Benutzerebene (UP) bereitzustellen, um die CUPS-Architektur (Control and User Plane Separation) zu unterstützen.

      • Nicht-CUPS-basierte VNFs: Das UAME ist abwärtskompatibel und bietet in Zusammenarbeit mit dem VNFM Unterstützung für die Bereitstellung von Nicht-CUPS 4G-Gateways (basierend auf VPC-DI) und der 4G Policy and Charging Rules Function (PCRF).

    • 5G NFs:

      • VNF-basierte NFs: Das UAME verwendet das VNFM, um VPC-SI-basierte Netzwerkfunktionen (NFs) bereitzustellen.

      • Cloud-basierte NFs: Das UAME interagiert mit dem VNFM, um die SMI (Ultra Cloud Core Subscriber Microservices Infrastructure) bereitzustellen. Der SMI arbeitet dann mit dem VNFM zusammen, um NFs in einem VM-basierten Kuberneten-Cluster (auch bekannt als K8s) bereitzustellen.

    Elastic Services Controller (ESC)

    ESC ist das in diesem Artikel erwähnte VNFM, das derzeit die einzige unterstützte Plattform ist.

    Problem 

    VMs, die Cloud-native 5G SMI VMs hosten, befinden sich im ESC im FEHLER-Status.

    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

    Verfahren zur Wiederherstellung von VMs

    Überprüfen Sie, ob der VM-Status in UAME und ESC angezeigt wird. Starten Sie den Wiederherstellungsvorgang von ESC aus. Wenn ESC die VM nicht wiederherstellen kann, fahren Sie mit der erneuten Bereitstellung von UAME fort.

    Schritt 1: Überprüfen Sie den VM-Status von UAME.

    Melden Sie sich beim UAME an, navigieren Sie zur cond-CLI, und überprüfen Sie den Status wie hier gezeigt.


    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

    Schritt 2: Stellen Sie die VMs vom ESC wieder her.

    Versuchen Sie, ESC manuell wiederherzustellen.

    Spoiler

    Hinweis: Die Wiederherstellung kann bis zu 900 s (15 Min.) dauern.

    bootup_time 300
    Wiederherstellungs-Wartezeit 600

    Melden Sie sich bei Master ESC an, überprüfen Sie den Zustand, und führen Sie dann die Wiederherstellungsbefehle aus, wie hier gezeigt.

    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>

    Schritt 3: Überprüfen Sie, ob die Wiederherstellung erfolgreich war.

    Überprüfen Sie die yangesc-Protokolle (tail -50f /var/log/esc/yangesc.log) und suchen Sie nach Status und Recovery wie oben gezeigt. Wenn es erfolgreich ist, navigieren Sie zur cond-CLI und überprüfen Sie.

    [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

    Erfolgreiche Wiederherstellung

    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 |

    Fehlgeschlagene Wiederherstellung

    Dieses Beispiel zeigt einen Fall eines Wiederherstellungsfehlers von ESC. In diesem Fall wird die VM von UAME erneut bereitgestellt.

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

    Diese Ausgabe zeigt die Fehlermeldung in yangesc.log an.

    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>

    Überprüfung der Wiederherstellungspolitik des WSA

    In ESC wird die Wiederherstellungsmethode nur neu gestartet. Dies zeigt, dass die VM nicht mit einem Neustart zurückgeholt werden konnte. Eine erneute Bereitstellung ist erforderlich.

    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

    Bestätigen Sie den VM-Status in UAME erneut.

    Spoiler
    Wichtiger Hinweis: Redeploy wird durch day0-Konfiguration. Die Day1-Konfiguration muss separat geladen werden. 
    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

    Schritt 4: Bereitstellung der VMs

    VMs von UAME erneut bereitstellen

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

    Protokolle der Neubereitstellung inspizieren

    Anzeige von UAME-Protokollen und ESC-Protokollen. Dieser gesamte Vorgang kann bis zu 15 Minuten dauern.

    UAME-Protokolle:

    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

    ESC-Protokolle:

    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>

    Überprüfen Sie den Status des virtuellen Systems. Befolgen Sie das Verfahren in Schritt 3.

    TAC Authored

    Beiträge von Cisco Ingenieuren

    • Adityan Arathi
      Cisco TAC-Techniker

    War dieses Dokument hilfreich?

    FeedbackFeedback

    Cisco kontaktieren

    Dieses Dokument gilt für folgende Produkte.