Einführung

In diesem Dokument wird das Problem der SMF NF PODs beschrieben, die nach dem Laden der Day-1-Konfiguration in SMF Ops Center nicht mehr angezeigt werden.

Voraussetzung

Anforderungen

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

• Subscriber Microservices Infrastructure (SMI)
• Docker
• Kubertisch
• 5 G

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• SMI
• Ops-Center
• SMF

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Problem 

Im Kunden-Setup verfügen sie über zwei SMF NFs, die mit derselben Version ausgeführt werden. Beide SMF NFs wurden gestern Abend auf die neueste Version aktualisiert. Vor dem Upgrade befanden sich bei beiden NF PODs im Ausführungszustand. Das Problem zeigt sich nur bei einem SMF, d. h. SMF-IMS. Die andere POD SMF-DATA wird aktualisiert und hat alle PODs im Ausführungszustand.

• SMF-Version vor dem Upgrade: smf.2020.01.0-12
• SMF-Version nach dem Upgrade: smf.2020.01.0-18

Abkürzungen

SMF	Sitzungsverwaltungsfunktion
NF	Netzwerkfunktion
MOE	Gemeinsame Ausführungsumgebung
POD	Es ist die kleinstmögliche Einheit in der Kuberneten Umgebung, d.h. mindestens ein Container.
IMS	IP-Multimedia-Subsystem
SMI	Subscriber Microservices-Infrastruktur

Beobachtungen

• Cluster-Synchronisierung zeigt erfolgreiche Bereitstellung.
• Kuberettes Master zeigt die PODS im Ausführungszustand mit Day-Zero-Konfiguration an.
• Wenn die Day-1-Konfiguration geladen wird, wird der neue PODS nicht angezeigt.
• Innerhalb des SMF ops-zentrums werden die Helmkarten im gelöschten Zustand angezeigt.
• Der Systemmodus wird heruntergefahren, und umgekehrt war dies nicht hilfreich.
• Das Hinzufügen einer neuen Day-1-Konfiguration war ebenfalls nicht hilfreich.

Symptome

• SMF-IMS NF zeigt die PODs mit Day-0-Konfiguration an.
• Im Ops-Center können wir uns anmelden.
• CEE Ops-Center ist in Betrieb.
• SMF-DATA Operations Center ist mit der Day-1-Konfiguration betriebsbereit. Diese NF mit funktionierenden PODs ist die andere.

~ubuntu@crucs501-cnat-cnat-core-master1:~$ kubectl get pods -n smf-ims

NAME                                              READY   STATUS    RESTARTS   AGE

api-smf-ims-ops-center-69f4d8f47b-hsqnx           1/1     Running   0          162m

base-entitlement-smf-998c8b84f-79r8v              1/1     Running   0          162m

documentation-65484db875-n4ljq                    1/1     Running   0          162m

ops-center-smf-ims-ops-center-6fb57bf79c-9dj29    5/5     Running   2          162m

smart-agent-smf-ims-ops-center-5dd679cf8b-hq4hs   1/1     Running   0          162m

swift-smf-ims-ops-center-745565bbf8-w5d7g         1/1     Running   0          162m

• Helmdiagrammstatus

crucs501-cnat/ims] smf# show helm

CHART              INSTANCE  STATUS   VERSION                                  REVISION  RELEASE                    NAMESPACE 

-------------------------------------------------------------------------------------------------------------------------------

infra-charts       -         DELETED  0.0.2-master-0031-200306111921-107580e   1         smf-ims-infra-charts       smf-ims   

smf-dashboard      -         DELETED  0.0.2-master-0018-200113112417-b028370   1         smf-ims-smf-dashboard      smf-ims   

smf-configuration  -         DELETED  0.0.6-master-1067-200303174113-9ee9665   1         smf-ims-smf-configuration  smf-ims   

li-ep              -         DELETED  0.0.1-master-0405-200306144054-3c56b02   1         smf-ims-li-ep              smf-ims   

smf-nodemgr        -         DELETED  0.0.2-master-3741-200304171906-5013914   1         smf-ims-smf-nodemgr        smf-ims   

smf-udp-proxy      -         DELETED  0.0.2-master-1420-200305182644-ebb4bc9   1         smf-ims-smf-udp-proxy      smf-ims   

gtpc-ep            -         DELETED  0.0.3-master-0926-200305203830-3306ff4   1         smf-ims-gtpc-ep            smf-ims   

smf-protocol       -         DELETED  0.0.2-master-4652-200304144735-d1e3798   1         smf-ims-smf-protocol       smf-ims   

smf-dns-proxy      -         DELETED  0.1.0-master-0541-200304144718-b028370   1         smf-ims-smf-dns-proxy      smf-ims   

smf-service        -         DELETED  0.0.5-master-18345-200305110040-5e8938b  1         smf-ims-smf-service        smf-ims   

smf-rest-ep        -         DELETED  0.3.3-master-6072-200304171221-7b0ff1a   1         smf-ims-smf-rest-ep        smf-ims   

etcd-cluster       -         DELETED  0.5.2-master-0046-200305044107-60d06f1   1         smf-ims-etcd-cluster       smf-ims   

ngn-datastore      -         DELETED  1.0.1-master-0619-200305030353-d255520   1         smf-ims-ngn-datastore      smf-ims 

Fehlerbehebung

1. Führen Sie die Cluster-Synchronisierung mehrmals über SMI-Deployer ohne Erfolg durch.
   
   
2. Die Day-1-Konfiguration wird verifiziert.
   
   
3. Entfernen Sie die Day-1-Konfiguration, und fügen Sie sie wieder hinzu.
   
   
4. Löschen Sie das Ops-Center aus Kuberetmaster.
   
   
5. Die vollständige Konfigurationsentfernung wird durchgeführt.
   
   
6. Löschen Sie die Konfigurationszuordnungen (CM).
   
   
7. Löschen Sie die Helmdiagramme vom Master.
   
   
8. Löschen Sie den Namespace.
   
   
9. Entfernen Sie die zugehörigen Dateien aus Deployer.
   
   
10. Da dasselbe neue SMF-Build auch für andere Bereitstellungen in der Kundenumgebung gut funktioniert, ist es ausgeschlossen, dass das Image zu Problemen führt.
    
    
11. SMF-DATA in der gleichen Konfiguration war fehlerfrei verfügbar.

Lösung

1. Löschen Sie die Cluster-Konfiguration des SMF-IMS Operations Center vom SMI-Bereitsteller.
   
   
2. Synchronisieren Sie den Cluster.
   
   
3. Fügen Sie die Konfiguration wieder hinzu.
   
   
4. Synchronisieren Sie den Cluster.

Es gibt noch eine Lösung für dieses Problem:

Löschen Sie die ältere Version des SMF-Pakets aus dem Verzeichnis, auf das sich SMI Deployer bei der Cluster-Synchronisierung bezieht.

Dies ist der Konfigurationsteil, der aus der SMI-Bereitstellungs-Konfiguration "ops-center running-config" entfernt und hinzugefügt wurde:

ops-centers smf ims

  repository               https://charts.10.192.1.xxx.nip.io/smf.2020.01.0-18

  sync-default-repository true

  netconf-ip              10.241.69.xx

  netconf-port            2024

  ssh-ip                  10.241.69.xx

  ssh-port                22

  ingress-hostname        10.241.69.xx.nip.io

  initial-boot-parameters use-volume-claims true

  initial-boot-parameters first-boot-password <xxxyyyzzz>

  initial-boot-parameters auto-deploy false

  initial-boot-parameters single-node false

 exit

Gemäß dem Anrufablauf der Bereitstellungen übernimmt SMI Deployer die Extraktion der Images für PODs aus dem darin gespeicherten Paket.

Normalerweise werden die heruntergeladenen Softwarepakete von SMF im lokalen Verzeichnis gespeichert, aus dem der SMI-Bereitsteller sie extrahiert und unter diesem Verzeichnis verschiebt: /data/software/packages/</strong >

Wenn die Liste der Pakete, die unter diesem Verzeichnis verfügbar sind, aktiviert ist, können Sie alle älteren Pakete zusammen mit der neuen Paketliste sehen.

ubuntu@xxxxx501-cnat-smi-cm-core-cm1:/data/software/packages$ ls -lrt

total 24

drwxrwxr-x 3 root root 4096 Mar 23 13:15 sample

drwxrwxr-x 3 root root 4096 Mar 24 05:48 smf.2020.01.0-12   >>> Older version of SMF

drwxrwxr-x 3 root root 4096 Mar 24 05:48 cee.2020.01.0-1

drwxrwxr-x 3 root root 4096 Apr 13 19:48 smf.2020.01.0-18   >>> Newer version of SMF

drwxr-xr-x 3 root root 4096 May  4 10:10 smf.2020.02.0.i66  >>> Older version os SMF

drwxr-xr-x 3 root root 4096 May  8 12:02 cee.2020.02.0

In dieser Ausgabe sind drei verschiedene SMF-Pakete verfügbar. Obwohl die richtige SMF-Version (d. h. smf.2020.01.0-18) in der SMI-Deployer-Konfiguration definiert ist, kann der SMI-Deployer trotzdem irgendwie nicht die richtigen Bilddateien für dieses Paket abrufen.

Nachdem die im Abschnitt "Lösung" erwähnte Problemumgehung durchgeführt wurde, wurde das Problem behoben.

Hinweis: Ähnliches Problem wird auch bei PODs der CEE beobachtet, für die eine ähnliche Problemumgehung wie im Abschnitt "Lösung" beschrieben angewendet wird.