Procedura per l'autorizzazione al reso (RMA) del server AIO basato su RCM nell'implementazione di CNDP
Opzioni per il download
Linguaggio senza pregiudizi
La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Informazioni su questa traduzione
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Sommario
Introduzione
Questo documento descrive la procedura dettagliata per l'autorizzazione restituzione materiale (RMA) per il server All-in-One (AIO) basato su RCM (Redundancy Configuration Manager) nell'implementazione di Cloud Native Deployment Platform (CNDP) per qualsiasi problema hardware o attività correlata alla manutenzione.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- RCM
- Kubernetes
Componenti usati
Il riferimento delle informazioni contenute in questo documento è la versione di RCM - rcm.2021.02.1.i18
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Informazioni sullo schema IP di RCM
In questo documento viene illustrato il design di RCM, costituito da due nodi AIO con due opscenter RCM e un RCM CEE ciascuno per il nodo AIO.
Il nodo AIO di destinazione di RCM per RMA in questo articolo è AIO-1 (AI0301) che contiene entrambi gli opscenter di RCM nello stato PRIMARY.
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 |
Procedura di backup
Eseguire il backup della configurazione
Per iniziare, raccogliere il backup di configurazione del running-config dagli opscenter di RCM in esecuzione sul nodo AIO di destinazione.
# show running-config | nomore
Raccogliere la configurazione di esecuzione dagli opacenter RCM CEE in esecuzione sul nodo AIO di destinazione.
# show running-config | nomore
Procedura di verifica preliminare
Controlli preliminari all'AIO
Raccogliere l'output del comando da entrambi i nodi AIO e verificare che tutti i pod siano in stato Running.
# kubectl get ns
# kubectl get pods -A -o wide
Output dei controlli preliminari di esempio
Notare che i due opscenter RCM e un opscenter RCM CEE vengono eseguiti sul nodo AIO-1
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:~$
Accedere all'opscenter RCM di AIO-1 e verificare lo stato.
[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#
Ripetere gli stessi passaggi sul nodo AIO-2 in cui sono presenti gli altri due opuscoli RCM corrispondenti al nodo AIO-1.
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:~$
Accedere all'opscenter RCM di AIO-2 e verificare lo stato.
[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#
Procedura di esecuzione
Operazioni da eseguire su RCM prima di arrestare il nodo AIO
- Poiché gli RCM su AIO-1 sono entrambi MASTER, è possibile migrarli a BACKUP.
a. A tale scopo, è necessario eseguire il comando rcm migrate primary sugli RCM attivi prima di spegnere il server AIO-1.
[up0300-aio-1/rm0301] rcm# rcm migrate primary
[up0300-aio-1/rm0303] rcm# rcm migrate primary
b. Verificare che lo stato sia BACKUP su AIO-1.
[up0300-aio-1/rm0301] rcm# rcm show-status
[up0300-aio-1/rm0303] rcm# rcm show-status
c. Verificare che lo stato sia MASTER su AIO-2 e che siano MASTER.
[up0300-aio-1/rm0302] rcm# rcm show-status
[up0300-aio-1/rm0304] rcm# rcm show-status
d. Arrestare RCM su rm0301 e 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. È inoltre necessario disattivare le operazioni CEE eseguite su AIO-1, ovvero i comandi utilizzati.
[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
Attendere qualche minuto e controllare il sistema per visualizzare 0,0%.
[up0300-aio-1/rce301] cee# show system
3. Verificare che non vi siano pod per gli spazi dei nomi RCM e CEE, ad eccezione dei pod documentazione, smart-agent, ops-center-rcm e ops-center-cee
# kubectl get pods -n rcm-rm0301 -o wide
# kubectl get pods -n rcm-rm0303 -o wide
# kubectl get pods -n cee-rce302 -o wide
Passi da eseguire sul nodo Kubernetes prima della chiusura del nodo AIO
Svuotare il nodo Kubernetes in modo che i pod e i servizi associati vengano terminati normalmente. L'utilità di pianificazione non selezionerà più questo nodo Kubernetes e rimuoverà i pod da tale nodo. Svuotare un singolo nodo alla volta.
Accedere a Gestione cluster SMI.
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 -
Svuotare il nodo master:
[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
Contrassegnare il nodo master-1 in modalità manutenzione:
[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
Eseguire la sincronizzazione del cluster e monitorare i registri per l'azione di sincronizzazione:
[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
Output di esempio per i registri di sincronizzazione del cluster:
[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
Procedura di manutenzione del server
Spegnere correttamente il server da CIMC. Procedere con l'attività di manutenzione relativa all'hardware definita nel MoP hardware e verificare che tutti i controlli di integrità siano stati superati dopo l'accensione del server.
Nota: in questo articolo non vengono illustrati i piani dei criteri di gestione dell'attività di manutenzione o hardware del server, in quanto si differenziano dalla descrizione del problema
Procedura di ripristino Kubernetes
Passi da eseguire sul nodo Kubernetes dopo l'accensione sul nodo AIO
Accedere a Gestione cluster SMI:
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 -
Disattivare il flag di manutenzione per il master-1 da aggiungere nuovamente al cluster.
[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
Ripristinare i pod e i servizi del nodo master con l'azione di sincronizzazione del cluster.
[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
Monitorare i registri per l'azione di sincronizzazione.
[bot-deployer-cm-primary] SMI Cluster Deployer# clusters up0100-aio-1 nodes master-1 actions sync logs
Controllare lo stato del cluster del dispositivo master AIO-1.
[bot-deployer-cm-primary] SMI Cluster Deployer# clusters up0300-aio-1 actions k8s cluster-status
Output di esempio:
[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
Procedura di ripristino di RCM
Procedure di esecuzione su centri operativi CEE e RCM per il ripristino dell'applicazione
Attivare la modalità di esecuzione per l'operatore CEE e l'operatore RCM.
Configurare la modalità di esecuzione per 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
Attendere alcuni minuti e verificare che il sistema sia al 100,0%.
[up0300-aio-1/rce301] cee# show system
Configurare la modalità in esecuzione per 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>
Attendere qualche minuto e verificare che il sistema sia al 100%.
[up0300-aio-1/rm0301] cee# show system
Configurare la modalità in esecuzione per 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>
Attendere alcuni minuti e verificare che il sistema sia al 100,0%.
[up0300-aio-1/rm0303] cee# show system
Procedura di verifica
Verificare che i pod siano tutti nello stato UP e Running su entrambi i nodi AIO con questi comandi.
on AIO nodes:
kubectl get ns
kubectl get pods -A -o wide
on RCM ops-centers:
rcm show-status
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
20-Jul-2022 |
Il comando cluster sync è stato aggiunto e i passaggi della procedura Restoration sono stati modificati. |
1.0 |
11-Jan-2022 |
Versione iniziale |
Contributo dei tecnici Cisco
- Venkata Naga Rajesh BadvetiCisco TAC Engineer
Feedback