Schritte zur RMA des RCM-basierten AIO-Servers in der CNDP-Bereitstellung

Einleitung

In diesem Dokument wird das detaillierte Verfahren für die Retourengenehmigung (Return Material Authorization, RMA) für den auf dem Redundancy Configuration Manager (RCM) basierenden All-in-One (AIO)-Server in der Cloud Native Deployment Platform (CNDP) bei Hardwareproblemen oder wartungsbezogenen Aktivitäten beschrieben.

Voraussetzungen

Anforderungen

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

• RCM
• Kubernetes

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf der RCM-Version - rcm.2021.02.1.i18

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.

Kennen Sie das RCM IP-Schema

In diesem Dokument wird das RCM-Design erläutert, das aus zwei AIO-Knoten mit zwei RCM Opscentern und je einem RCM CEE für den AIO-Knoten besteht.

Der Ziel-RCM-AIO-Knoten für die RMA in diesem Artikel ist AIO-1 (AI0301), der beide RCM-Optimierer im PRIMARY-Status enthält.

POD_NAME

NODE_NAME

IP_ADDRESS

DEVICE_TYPE

OS_TYPE

UP0300

RCE301

10.1.2.9

RCM_CEE_AIO_1

opscenter

UP0300

RCE302

10.1.2.10

RCM_CEE_AIO_2

opscenter

UP0300

AI0301

10.1.2.7

RCM_K8_AIO_1

linux

UP0300

AI0302

10.1.2.8

RCM_K8_AIO_2

linux

UP0300

RM0301

10.1.2.3

RCM1_ACTIVE

opscenter

UP0300

RM0302

10.1.2.4

RCM1_STANDBY

opscenter

UP0300

RM0303

10.1.2.5

RCM2_ACTIVE

opscenter

UP0300

RM0304

10.1.2.6

RCM2_STANDBY

opscenter

Backup-Verfahren

Sichern der Konfiguration

Sammeln Sie zunächst die Konfigurationssicherung der aktuellen Konfiguration von RCM-Optimierern, die auf dem Ziel-AIO-Knoten ausgeführt werden.

# show running-config | nomore

Sammeln Sie die Ausführungskonfiguration von RCM CEE-Opscentern, die auf dem Ziel-AIO-Knoten ausgeführt werden.

# show running-config | nomore

Voreck-Verfahren

Vorhaken bei AIO

Sammeln Sie die Befehlsausgabe von beiden AIO-Knoten, und überprüfen Sie, ob alle PODs den Status "Running" aufweisen.

# kubectl get ns
# kubectl get pods -A -o wide

Ausgabe von Beispielvorschecks

Beachten Sie die beiden RCM-Opscenter und ein RCM CEE-Opscenter, die auf dem AIO-1-Knoten ausgeführt werden.

cloud-user@up0300-aio-1-master-1:~$ kubectl get ns
NAME              STATUS   AGE
cee-rce301        Active   110d  <--
default           Active   110d
istio-system      Active   110d
kube-node-lease   Active   110d
kube-public       Active   110d
kube-system       Active   110d
nginx-ingress     Active   110d
rcm-rm0301        Active   110d  <--
rcm-rm0303        Active   110d  <--
registry          Active   110d
smi-certs         Active   110d
smi-node-label    Active   110d
smi-vips          Active   110d
cloud-user@up0300-aio-1-master-1:~$

Melden Sie sich beim RCM Opscenter von AIO-1 an, und überprüfen Sie den Status.

[up0300-aio-1/rm0301] rcm# rcm show-status
message :
{"status":[" Fri Oct 29 07:21:11 UTC 2021 : State is MASTER"]}
[up0300-aio-1/rm0301] rcm#

[up0300-aio-1/rm0303] rcm# rcm show-status
message :
{"status":[" Fri Oct 29 07:22:18 UTC 2021 : State is MASTER"]}
[up0300-aio-1/rm0303] rcm#

Wiederholen Sie die gleichen Schritte für den AIO-2-Knoten, bei dem die beiden anderen RCM-Optimierer dem AIO-1-Knoten entsprechen.

cloud-user@up0300-aio-2-master-1:~$ kubectl get ns
NAME              STATUS   AGE
cee-rce302        Active   105d  <--
default           Active   105d
istio-system      Active   105d
kube-node-lease   Active   105d
kube-public       Active   105d
kube-system       Active   105d
nginx-ingress     Active   105d
rcm-rm0302        Active   105d  <--
rcm-rm0304        Active   105d  <--
registry          Active   105d
smi-certs         Active   105d
smi-node-label    Active   105d
smi-vips          Active   105d
cloud-user@up0300-aio-2-master-1:~$

Melden Sie sich beim RCM Opscenter von AIO-2 an, und überprüfen Sie den Status.

[up0300-aio-2/rm0302] rcm# rcm show-status
message :
{"status":[" Fri Oct 29 09:32:54 UTC 2021 : State is BACKUP"]}
[up0300-aio-2/rm0302] rcm#

[up0300-aio-2/rm0304] rcm# rcm show-status
message :
{"status":[" Fri Oct 29 09:33:51 UTC 2021 : State is BACKUP"]}
[up0300-aio-2/rm0304] rcm#

Ausführungsverfahren

Schritte zur Ausführung auf dem RCM vor dem Herunterfahren des AIO-Knotens

1. Da beide RCMs von AIO-1 MASTER sind, können Sie sie zu BACKUP migrieren.

a. Dazu müssen Sie den Befehl rcm migrate primary auf den aktiven RCMs ausführen, bevor Sie den AIO-1-Server ausschalten.

[up0300-aio-1/rm0301] rcm# rcm migrate primary

[up0300-aio-1/rm0303] rcm# rcm migrate primary

b. Vergewissern Sie sich, dass jetzt der Status BACKUP auf AIO-1 lautet.

[up0300-aio-1/rm0301] rcm# rcm show-status

[up0300-aio-1/rm0303] rcm# rcm show-status

c. Vergewissern Sie sich, dass der Status jetzt MASTER für AIO-2 lautet, und dass es sich um MASTER handelt.

[up0300-aio-1/rm0302] rcm# rcm show-status

[up0300-aio-1/rm0304] rcm# rcm show-status

d. Führen Sie das Herunterfahren des RCM für rm0301 und rm0303 durch.

[up0300-aio-2/rm0301] rcm# config
Entering configuration mode terminal
[up0300-aio-2/rm0301] rcm(config)# system mode shutdown
[up0300-aio-1/rce301] rcm(config)# commit comment <CRNUMBER>

[up0300-aio-2/rm0303] rcm# config
Entering configuration mode terminal
[up0300-aio-2/rm0303] rcm(config)# system mode shutdown
[up0300-aio-1/rce303] rcm(config)# commit comment <CRNUMBER>

2. Wir müssen auch die CEE-Operationen, die auf dem AIO-1 laufen, die verwendeten Befehle abschalten.

[up0300-aio-1/rce301] cee# config
Entering configuration mode terminal
[up0300-aio-1/rce301] cee(config)# system mode shutdown
[up0300-aio-1/rce301] cee(config)# commit comment <CRNUMBER>
[up0300-aio-1/rce301] cee(config)# exit

Warten Sie einige Minuten, und überprüfen Sie, ob das System 0,0 % anzeigt.

[up0300-aio-1/rce301] cee# show system

3. Vergewissern Sie sich, dass es keine PODs für die RCM- und CEE-Namespaces gibt, mit Ausnahme von Dokumentation, Smart-Agent, ops-center-rcm und ops-center-cee-PODs.

# kubectl get pods -n rcm-rm0301 -o wide
# kubectl get pods -n rcm-rm0303 -o wide
# kubectl get pods -n cee-rce302 -o wide

Schritte zum Ausführen auf Kubernetes Node vor dem Herunterfahren AIO Node

Entleeren Sie den Kubernetes-Knoten, sodass die zugehörigen PODs und Services ordnungsgemäß terminiert werden. Der Scheduler würde diesen Kubernetes-Knoten nicht mehr auswählen und Pods aus diesem Knoten entfernen. Entleeren Sie jeweils einen Knoten.  

Melden Sie sich beim SMI Cluster Manager an.

cloud-user@bot-deployer-cm-primary:~$ kubectl get svc -n smi-cm
NAME                                          TYPE        CLUSTER-IP       EXTERNAL-IP      PORT(S)                                                 AGE
cluster-files-offline-smi-cluster-deployer    ClusterIP   10.102.108.177   <none>           8080/TCP                                                78d
iso-host-cluster-files-smi-cluster-deployer   ClusterIP   10.102.255.174   192.168.0.102    80/TCP                                                  78d
iso-host-ops-center-smi-cluster-deployer      ClusterIP   10.102.58.99     192.168.0.100    3001/TCP                                                78d
netconf-ops-center-smi-cluster-deployer       ClusterIP   10.102.108.194   10.244.110.193   3022/TCP,22/TCP                                         78d
ops-center-smi-cluster-deployer               ClusterIP   10.102.156.123   <none>           8008/TCP,2024/TCP,2022/TCP,7681/TCP,3000/TCP,3001/TCP   78d
squid-proxy-node-port                         NodePort    10.102.73.130    <none>           3128:31677/TCP                                          78d
cloud-user@bot-deployer-cm-primary:~$ ssh -p 2024 admin@<Cluster IP of ops-center-smi-cluster-deployer>

      Welcome to the Cisco SMI Cluster Deployer on bot-deployer-cm-primary
      Copyright © 2016-2020, Cisco Systems, Inc.
      All rights reserved.
admin connected from 192.168.0.100 using ssh on ops-center-smi-cluster-deployer-686b66d9cd-nfzx8
[bot-deployer-cm-primary] SMI Cluster Deployer#
[bot-deployer-cm-primary] SMI Cluster Deployer# show clusters
                   LOCK TO 
NAME               VERSION 
----------------------------
cp0100-smf-data  -       
cp0100-smf-ims   -       
cp0200-smf-data  -       
cp0200-smf-ims   -       
up0300-aio-1     -     <--  
up0300-aio-2     -       
up0300-upf-data  -       
up0300-upf-ims   -   

Den Master-Knoten entleeren:

[bot-deployer-cm-primary] SMI Cluster Deployer# clusters up0300-aio-1 nodes master-1 actions sync drain remove-node true
This would run drain on the node, disrupting pods running on the node.  Are you sure? [no,yes] yes
message accepted

Aktivieren Sie den Wartungsmodus für den Master-1-Knoten:

[bot-deployer-cm-primary] SMI Cluster Deployer# config 
Entering configuration mode terminal
[bot-deployer-cm-primary] SMI Cluster Deployer(config)# clusters up0300-aio-1
[bot-deployer-cm-primary] SMI Cluster Deployer(config-clusters-up0300-aio-1)# nodes master-1
[bot-deployer-cm-primary] SMI Cluster Deployer(config-nodes-master1)# maintenance true 
[bot-deployer-cm-primary] SMI Cluster Deployer(config-nodes-master1)# commit
Commit complete.
[bot-deployer-cm-primary] SMI Cluster Deployer(config-nodes-master1)# end

Führen Sie die Cluster-Synchronisierung aus, und überwachen Sie die Protokolle für die Synchronisierungsaktion:

[bot-deployer-cm-primary] SMI Cluster Deployer# clusters up0300-aio-1 nodes master-1 actions sync
This would run sync.  Are you sure? [no,yes] yes
message accepted
[bot-deployer-cm-primary] SMI Cluster Deployer# clusters up0300-aio-1 nodes master-1 actions sync logs

Beispielausgabe für Cluster-Synchronisierungsprotokolle:

[installer-master] SMI Cluster Deployer#  clusters kali-stacked nodes cmts-worker1-1 actions sync logs
Example Cluster Name: kali-stacked
Example WorkerNode: cmts-worker1
logs 2020-10-06 20:01:48.023 DEBUG cluster_sync.kali-stacked.cmts-worker1: Cluster name: kali-stacked
2020-10-06 20:01:48.024 DEBUG cluster_sync.kali-stacked.cmts-worker1: Node name: cmts-worker1
2020-10-06 20:01:48.024 DEBUG cluster_sync.kali-stacked.cmts-worker1: debug: false
2020-10-06 20:01:48.024 DEBUG cluster_sync.kali-stacked.cmts-worker1: remove_node: true
PLAY [Check required variables] ************************************************
TASK [Gathering Facts] *********************************************************
Tuesday 06 October 2020  20:01:48 +0000 (0:00:00.017)       0:00:00.017 *******
ok: [master3]
ok: [master1]
ok: [cmts-worker1]
ok: [cmts-worker3]
ok: [cmts-worker2]
ok: [master2]
TASK [Check node_name] *********************************************************
Tuesday 06 October 2020  20:01:50 +0000 (0:00:02.432)       0:00:02.450 *******
skipping: [master1]
skipping: [master2]
skipping: [master3]
skipping: [cmts-worker1]
skipping: [cmts-worker2]
skipping: [cmts-worker3]
PLAY [Wait for ready and ensure uncordoned] ************************************
TASK [Cordon and drain node] ***************************************************
Tuesday 06 October 2020  20:01:51 +0000 (0:00:00.144)       0:00:02.594 *******
skipping: [master1]
skipping: [master2]
skipping: [master3]
skipping: [cmts-worker2]
skipping: [cmts-worker3]
TASK [upgrade/cordon : Cordon/Drain/Delete node] *******************************
Tuesday 06 October 2020  20:01:51 +0000 (0:00:00.205)       0:00:02.800 *******
changed: [cmts-worker1 -> 172.22.18.107]
PLAY RECAP *********************************************************************
cmts-worker1               : ok=2    changed=1    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0  
cmts-worker2               : ok=1    changed=0    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0  
cmts-worker3               : ok=1    changed=0    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0  
master1                    : ok=1    changed=0    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0  
master2                    : ok=1    changed=0    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0  
master3                    : ok=1    changed=0    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0  
Tuesday 06 October 2020  20:02:29 +0000 (0:00:38.679)       0:00:41.479 *******
===============================================================================
2020-10-06 20:02:30.057 DEBUG cluster_sync.kali-stacked.cmts-worker1: Cluster sync successful
2020-10-06 20:02:30.058 DEBUG cluster_sync.kali-stacked.cmts-worker1: Ansible sync done
2020-10-06     0:02:30.058 INFO cluster_sync.kali-stacked.cmts-worker1: _sync finished.  Opening lock

Serverwartungsverfahren

Schalten Sie den Server ordnungsgemäß aus dem CIMC aus. Fahren Sie mit den im Hardware-MoP definierten hardwarebezogenen Wartungsaktivitäten fort, und stellen Sie sicher, dass alle Statusprüfungen nach dem Einschalten des Servers bestanden werden.

Hinweis: Dieser Artikel behandelt nicht die Hardware- oder Wartungsaktivitäten MoP für den Server, da sie sich von der Problemaussage unterscheiden

Kubernetes Wiederherstellungsverfahren

Schritte zur Ausführung auf Kubernetes Node Post Power auf AIO Node

Melden Sie sich beim SMI-Cluster-Manager an:

cloud-user@bot-deployer-cm-primary:~$ kubectl get svc -n smi-cm
NAME                                          TYPE        CLUSTER-IP       EXTERNAL-IP      PORT(S)                                                 AGE
cluster-files-offline-smi-cluster-deployer    ClusterIP   10.102.108.177   <none>           8080/TCP                                                78d
iso-host-cluster-files-smi-cluster-deployer   ClusterIP   10.102.255.174   192.168.0.102    80/TCP                                                  78d
iso-host-ops-center-smi-cluster-deployer      ClusterIP   10.102.58.99     192.168.0.100    3001/TCP                                                78d
netconf-ops-center-smi-cluster-deployer       ClusterIP   10.102.108.194   10.244.110.193   3022/TCP,22/TCP                                         78d
ops-center-smi-cluster-deployer               ClusterIP   10.102.156.123   <none>           8008/TCP,2024/TCP,2022/TCP,7681/TCP,3000/TCP,3001/TCP   78d
squid-proxy-node-port                         NodePort    10.102.73.130    <none>           3128:31677/TCP                                          78d
cloud-user@bot-deployer-cm-primary:~$ ssh -p 2024 admin@<ClusterIP of ops-center-smi-cluster-deployer>
      Welcome to the Cisco SMI Cluster Deployer on bot-deployer-cm-primary
      Copyright © 2016-2020, Cisco Systems, Inc.
      All rights reserved.
admin connected from 192.168.0.100 using ssh on ops-center-smi-cluster-deployer-686b66d9cd-nfzx8
[bot-deployer-cm-primary] SMI Cluster Deployer#
[bot-deployer-cm-primary] SMI Cluster Deployer# show clusters
                   LOCK TO 
NAME               VERSION 
----------------------------
cp0100-smf-data  -       
cp0100-smf-ims   -       
cp0200-smf-data  -       
cp0200-smf-ims   -       
up0300-aio-1     -     <--  
up0300-aio-2     -       
up0300-upf-data  -       
up0300-upf-ims   -   

Deaktivieren Sie das Wartungsflag für die Master-1, die wieder dem Cluster hinzugefügt werden soll.

[bot-deployer-cm-primary] SMI Cluster Deployer# config
Entering configuration mode terminal
[bot-deployer-cm-primary] SMI Cluster Deployer(config)# clusters up0300-aio-1
[bot-deployer-cm-primary] SMI Cluster Deployer(config-clusters-up0300-aio-1)# nodes master-1
[bot-deployer-cm-primary] SMI Cluster Deployer(config-nodes-master-1)# maintenance false
[bot-deployer-cm-primary] SMI Cluster Deployer(config-nodes-master-1)# commit
Commit complete.
[bot-deployer-cm-primary] SMI Cluster Deployer(config-nodes-master-1)# end

Stellen Sie die Master-Knoten-PODs und -Dienste mit Cluster-Synchronisierungsaktion wieder her.

[bot-deployer-cm-primary] SMI Cluster Deployer# clusters up0100-aio-1 nodes master-1 actions sync run debug true
This would run sync.  Are you sure? [no,yes] yes
message accepted

Überwachen Sie die Protokolle für die Synchronisierungsaktion.

[bot-deployer-cm-primary] SMI Cluster Deployer# clusters up0100-aio-1 nodes master-1 actions sync logs

Überprüfen Sie den Cluster-Status des AIO-1-Masters.

[bot-deployer-cm-primary] SMI Cluster Deployer# clusters up0300-aio-1 actions k8s cluster-status

Beispiel für das Ergebnis:

[installer-] SMI Cluster Deployer# clusters kali-stacked actions k8s cluster-status
pods-desired-count 67
pods-ready-count 67
pods-desired-are-ready true
etcd-healthy true
all-ok true

RCM Wiederherstellungsverfahren

Schritte zur Ausführung in CEE- und RCM-Betriebszentren zur Wiederherstellung der Anwendung

Aktualisieren Sie CEE opscenter und RCM opscenter in den Betriebsmodus.

Konfigurieren Sie den Ausführungsmodus für rce301.

[up0300-aio-1/rce301] cee# config
Entering configuration mode terminal
[up0300-aio-1/rce301] cee(config)# system mode running
[up0300-aio-1/rce301] cee(config)# commit comment <CRNUMBER>
[up0300-aio-1/rce301] cee(config)# exit

Warten Sie einige Minuten, und überprüfen Sie, ob das System auf 100,0 % eingestellt ist.

[up0300-aio-1/rce301] cee# show system

Konfigurieren Sie den Ausführungsmodus für rm0301.

[up0300-aio-2/rm0301] rcm# config
Entering configuration mode terminal
[up0300-aio-2/rm0301] rcm(config)# system mode running
[up0300-aio-1/rce301] rcm(config)# commit comment <CRNUMBER>

Warten Sie einige Minuten, und stellen Sie sicher, dass das System auf 100,0 % eingestellt ist.

[up0300-aio-1/rm0301] cee# show system

Konfigurieren Sie den Ausführungsmodus für rm0303.

[up0300-aio-2/rm0303] rcm# config
Entering configuration mode terminal
[up0300-aio-2/rm0303] rcm(config)# system mode running
[up0300-aio-1/rce303] rcm(config)# commit comment <CRNUMBER>

Warten Sie einige Minuten, und überprüfen Sie, ob das System auf 100,0 % eingestellt ist.

[up0300-aio-1/rm0303] cee# show system

Prüfverfahren

Stellen Sie mit diesen Befehlen sicher, dass alle PODs auf beiden AIO-Knoten den Status "UP" und "Running" aufweisen.

on AIO nodes:
kubectl get ns
kubectl get pods -A -o wide

on RCM ops-centers:
rcm show-status