Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

RCM IP-Schema kennen

Sicherungsverfahren

Sicherung der Konfiguration

Perneut-Verfahren

Überprüfungen der AIO

Beispielausgaben

Ausführungsverfahren

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

Schritte zur Durchführung im Kuberettknoten vor dem Herunterfahren des AIO-Knotens

Serverwartungsverfahren

Kubernet-Wiederherstellungsverfahren

Schritte zur Durchführung mit Kuberettete Post Power on AIO Node

RCM Wiederherstellungsverfahren

Schritte zur Durchführung in CEE- und RCM-Betriebszentren zum Wiederherstellen der Anwendung

Überprüfungsverfahren

Einleitung

In diesem Dokument wird das detaillierte Verfahren zur Retourengenehmigung (Return Material Authorization, RMA) für die Bereitstellung des RCM-basierten All-in-One-Servers (AIO) 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

- Kubertisch

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 verstehen.

RCM IP-Schema kennen

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

Der Ziel-RCM-AIO-Knoten für die RMA in diesem Artikel ist AIO-1 (AI0301), der die beiden RCM-Ausgangsszenarien im PRIMÄREN Zustand 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

Sicherungsverfahren

Sicherung der Konfiguration

Zunächst sollten Sie die Konfigurationssicherung der laufenden Konfiguration von RCM-Betriebssystemen erfassen, die auf dem Ziel-AIO-Knoten ausgeführt werden.

# show running-config | nomore

Erfassen Sie die aktuelle Konfiguration von RCM CEE-Betriebssystemen, die auf dem Ziel-AIO-Knoten ausgeführt werden.

# show running-config | nomore

Perneut-Verfahren

Überprüfungen der AIO

Erfassen Sie die Befehlsausgabe von beiden AIO-Knoten, und überprüfen Sie, ob alle PODs im Running-Zustand sind.

# kubectl get ns

# kubectl get pods -A -o wide

Beispielausgaben

Beachten Sie, dass zwei RCM-Opszenarien und ein RCM CEE-Opscenter 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 auf dem AIO-2-Knoten, auf dem die beiden anderen RCM-Ausgangsszenarien 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 Durchführung auf dem RCM vor dem Herunterfahren des AIO-Knotens

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

antwort: 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. Überprüfen Sie, ob der Status jetzt "BACKUP" auf AIO-1 lautet.

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

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

c. Stellen Sie sicher, dass der Status auf AIO-2 jetzt "MASTER" lautet und MASTER lautet.

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

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

d. RCM herunterfahren sowohl auf rm0301 als auch auf rm0303.

[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. Außerdem müssen wir die CEE-Operations, die auf der AIO-1 ausgeführt werden, ausschalten. Verwendete Befehle.

[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 keine PODs für RCM- und CEE-Namespaces vorhanden sind, außer für Dokumentations-, Smart Agent-, Operations-Center-rcm- und Operations-Center-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 zur Durchführung im Kuberettknoten vor dem Herunterfahren des AIO-Knotens

Entleeren Sie den Kuberneten-Knoten, sodass die verknüpften PODs und Services ordnungsgemäß beendet werden. Der Scheduler würde diesen kuberneten Knoten und die Gerätepoden nicht mehr aus diesem Knoten auswählen. Bitte entladen 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   -

Entwässern Sie den Master-Knoten:

[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 Servicemodus 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 eine 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äß vom CIMC aus. Fahren Sie mit der hardwarebezogenen Wartungsaktivität wie im Hardware-MoP definiert fort, und stellen Sie sicher, dass alle Statusprüfungen nach dem Einschalten des Servers bestanden werden.

Anmerkung: Dieser Artikel behandelt nicht die MoP für Hardware- oder Wartungsaktivitäten des Servers, da sie sich von der Problembeschreibung unterscheiden

Kubernet-Wiederherstellungsverfahren

Schritte zur Durchführung mit Kuberettete Post Power on 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   -

Schalten Sie das Wartungs-Flag aus, damit der Master-1 wieder dem Cluster hinzugefügt wird.

[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 einer 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 Durchführung in CEE- und RCM-Betriebszentren zum Wiederherstellen der Anwendung

Aktualisieren Sie das CEE Opscenter und das RCM Opscenter in den Ausführungsmodus.

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 zu 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 überprüfen Sie, ob das System zu 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 zu 100,0 % eingestellt ist.

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

Überprüfungsverfahren

Überprüfen Sie, ob die PODs alle UP- und Running-Status auf beiden AIO-Knoten mit diesen Befehlen aufweisen.

on AIO nodes:

kubectl get ns

kubectl get pods -A -o wide

on RCM ops-centers:

rcm show-status