Fehlerbehebung bei HA-Knotenproblemen im CNDP-Cluster Manager und Neuinstallation von Force-VM-Redeploy

Einleitung

In diesem Dokument wird das Verfahren zur Wiederherstellung des Cluster Manager vom ursprünglichen Server in der Konfiguration der Cloud Native Deployment Platform (CNDP) beschrieben.

Voraussetzungen

Anforderungen

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

• Cisco Subscriber Microservices Infrastructure (SMI)
• 5G CNDP- oder SMI-Bare-Metal-Architektur (BM)
• Distributed Replicate Block Device (DRBD)

Verwendete Komponenten

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

• SMI 2020,02,2,35
• Kubernetes v1.21.0
  
  

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 möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Was ist SMI Cluster Manager?

Ein Cluster-Manager ist ein Keepalive-Cluster mit zwei Knoten, der als Ausgangspunkt für die Cluster-Bereitstellung auf Kontroll- und Benutzerebene verwendet wird. Es führt einen Kubernetes-Cluster mit einem Knoten und eine Reihe von PODs aus, die für die gesamte Cluster-Einrichtung verantwortlich sind. Nur der primäre Cluster-Manager ist aktiv, und der sekundäre übernimmt nur bei einem Ausfall oder wird aus Wartungsgründen manuell heruntergefahren.

Was ist ein Inception Server?

Dieser Knoten übernimmt die Lebenszyklusverwaltung des zugrunde liegenden Cluster Managers (CM). Von hier aus können Sie die Day0-Konfiguration übertragen.

Dieser Server wird in der Regel regional oder im selben Rechenzentrum wie die übergeordnete Orchestrierungsfunktion (z. B. NSO) bereitgestellt und läuft in der Regel als VM.

Problem

Der Cluster-Manager wird in einem Cluster mit zwei Knoten und verteilten replizierten Blockgeräten (DRBD) gehostet und als primärer Cluster-Manager und sekundärer Cluster-Manager weitergeführt. In diesem Fall schaltet sich der sekundäre Cluster Manager automatisch aus, während das Betriebssystem im UCS initialisiert bzw. installiert wird. Dies weist auf eine Beschädigung des Betriebssystems hin.

cloud-user@POD-NAME-cm-primary:~$ drbd-overview status
0:data/0 WFConnection Primary/Unknown UpToDate/DUnknown /mnt/stateful_partition ext4 568G 369G 170G 69% 

Verfahren für die Wartung

Dieser Prozess unterstützt die Neuinstallation des Betriebssystems auf dem CM-Server.

Identifizieren von Hosts

Melden Sie sich bei Cluster-Manager an, und identifizieren Sie Hosts:

cloud-user@POD-NAME-cm-primary:~$ cat /etc/hosts | grep 'deployer-cm'
127.X.X.X POD-NAME-cm-primary POD-NAME-cm-primary
X.X.X.X POD-NAME-cm-primary
X.X.X.Y POD-NAME-cm-secondary

Clusterdetails vom Überwachungsserver identifizieren

Melden Sie sich beim Inception-Server an, wechseln Sie zum Deployer, und überprüfen Sie den Clusternamen mit hosts-IP vom Cluster-Manager.

Melden Sie sich nach erfolgreicher Anmeldung beim Inception-Server wie hier gezeigt im Betriebszentrum an.

user@inception-server: ~$ ssh -p 2022 admin@localhost

Überprüfen Sie den Clusternamen von Cluster Manager SSH-IP (ssh-ip = Node SSH IP ip-address = ucs-server cimc ip-address).

[inception-server] SMI Cluster Deployer# show running-config clusters * nodes * k8s ssh-ip | select nodes * ssh-ip | select nodes * ucs-server cimc ip-address | tab
                               SSH 
NAME             NAME          IP     SSH IP           IP ADDRESS 
------------------------------------------------------------------------------
POD-NAME-deployer     cm-primary    -      X.X.X.X          10.X.X.X ---> Verify Name and SSH IP if Cluster is part of inception server SMI.
                 cm-secondary  -      X.X.X.Y          10.X.X.Y

Überprüfen Sie die Konfiguration für den Zielcluster.

[inception-server] SMI Cluster Deployer# show running-config clusters POD-NAME-deployer

Entfernen Sie das virtuelle Laufwerk, um das Betriebssystem vom Server zu löschen.

Stellen Sie eine Verbindung zum CIMC des betroffenen Hosts her, löschen Sie das Boot-Laufwerk, und löschen Sie das virtuelle Laufwerk.

a) CIMC > Storage > Cisco 12G Modular Raid Controller > Storage Log > Clear Boot Drive
b) CIMC > Storage > Cisco 12G Modular Raid Controller > Virtual drive > Select the virtual drive > Delete Virtual Drive

Cluster-Synchronisierung ausführen

Führen Sie die standardmäßige Cluster-Synchronisierung für den Cluster-Manager vom Initialisierungsserver aus.

[inception-server] SMI Cluster Deployer# clusters POD-NAME-deployer actions sync run debug true
This will run sync. Are you sure? [no,yes] yes
message accepted
[inception-server] SMI Cluster Deployer#

Wenn die standardmäßige Cluster-Synchronisierung fehlschlägt, führen Sie für eine vollständige Neuinstallation eine Cluster-Synchronisierung mit der Option "force-vm redeploy" durch (die Clustersynchronisierungsaktivität kann ca. 45-55 Minuten in Anspruch nehmen, abhängig von der Anzahl der im Cluster gehosteten Knoten).

[inception-server] SMI Cluster Deployer# clusters POD-NAME-deployer actions sync run debug true force-vm-redeploy true
This will run sync. Are you sure? [no,yes] yes
message accepted
[inception-server] SMI Cluster Deployer#

Überwachen der Cluster-Synchronisierungs-Synchronisierungsprotokolle

[inception-server] SMI Cluster Deployer# monitor sync-logs POD-NAME-deployer
2023-02-23 10:15:07.548 DEBUG cluster_sync.POD-NAME: Cluster name: POD-NAME 
2023-02-23 10:15:07.548 DEBUG cluster_sync.POD-NAME: Force VM Redeploy: true
2023-02-23 10:15:07.549 DEBUG cluster_sync.POD-NAME: Force partition Redeploy: false 
2023-02-23 10:15:07.549 DEBUG cluster_sync.POD-NAME: reset_k8s_nodes: false 
2023-02-23 10:15:07.549 DEBUG cluster_sync.POD-NAME: purge_data_disks: false 
2023-02-23 10:15:07.549 DEBUG cluster_sync.POD-NAME: upgrade_strategy: auto 
2023-02-23 10:15:07.549 DEBUG cluster_sync.POD-NAME: sync_phase: all 
2023-02-23 10:15:07.549 DEBUG cluster_sync.POD-NAME: debug: true 
...
...
...

Der Server wird erneut bereitgestellt und durch erfolgreiche Cluster-Synchronisierung installiert.

PLAY RECAP *********************************************************************
cm-primary :   ok=535 changed=250 unreachable=0 failed=0 skipped=832 rescued=0 ignored=0 
cm-secondary : ok=299 changed=166 unreachable=0 failed=0 skipped=627 rescued=0 ignored=0 
localhost :    ok=59  changed=8   unreachable=0 failed=0 skipped=18  rescued=0 ignored=0 

Thursday 23 February 2023 13:17:24 +0000 (0:00:00.109) 0:56:20.544 *****. ---> ~56 mins to complete cluster sync

===============================================================================

2023-02-23 13:17:24.539 DEBUG cluster_sync.POD-NAME: Cluster sync successful
2023-02-23 13:17:24.546 DEBUG cluster_sync.POD-NAME: Ansible sync done
2023-02-23 13:17:24.546 INFO cluster_sync.POD-NAME: _sync finished. Opening lock

Verifizierung

Überprüfen Sie, ob der betroffene Cluster-Manager erreichbar ist und ob der DRBD-Überblick über den primären und sekundären Cluster-Manager den Status "UpToDate" aufweist.

cloud-user@POD-NAME-cm-primary:~$ ping X.X.X.Y
PING X.X.X.Y (X.X.X.Y) 56(84) bytes of data.
64 bytes from X.X.X.Y: icmp_seq=1 ttl=64 time=0.221 ms
64 bytes from X.X.X.Y: icmp_seq=2 ttl=64 time=0.165 ms
64 bytes from X.X.X.Y: icmp_seq=3 ttl=64 time=0.151 ms
64 bytes from X.X.X.Y: icmp_seq=4 ttl=64 time=0.154 ms
64 bytes from X.X.X.Y: icmp_seq=5 ttl=64 time=0.172 ms
64 bytes from X.X.X.Y: icmp_seq=6 ttl=64 time=0.165 ms
64 bytes from X.X.X.Y: icmp_seq=7 ttl=64 time=0.174 ms

--- X.X.X.Y ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6150ms
rtt min/avg/max/mdev = 0.151/0.171/0.221/0.026 ms

cloud-user@POD-NAME-cm-primary:~$ drbd-overview status
0:data/0 Connected Primary/Secondary UpToDate/UpToDate /mnt/stateful_partition ext4 568G 17G 523G 4%

Der betroffene Cluster-Manager wird erfolgreich installiert und im Netzwerk erneut bereitgestellt.