Procedura per ripristinare la CRD da uno stato non valido in CPS

Introduzione

In questo documento viene descritta la procedura per ripristinare la tabella dei dati di riferimento personalizzati (CRD) di Cisco Policy Suite (CPS) dallo stato BAD.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Linux
• CPS
• MongoDB

Cisco consiglia di disporre dei privilegi di accesso:

• Accesso alla radice alla CLI di CPS
• Accesso utente "qns-svn" alle interfacce utente di CPS (Policy Builder e CPS Central)
  
  

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• CPS 20.2
• MongoDB v3.6.17
• UCS-B

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.

Premesse

In CPS, la tabella CRD viene utilizzata per archiviare le informazioni di configurazione dei criteri personalizzate pubblicate da Policy Builder e associate al database CRD presente nell'istanza di MongoDB ospitata in sessionmgr. Le operazioni di esportazione e importazione vengono eseguite nella tabella CRD mediante l'interfaccia grafica utente di CPS Central per modificare i dati della tabella CRD.

Problema 

Se si verifica un errore durante l'importazione di tutte le operazioni, CPS interrompe il processo, imposta il sistema in stato BAD e blocca l'esecuzione delle API CRD. CPS invia una risposta di errore al client che indica che il sistema è in stato BAD. Se lo stato del sistema è BAD e si riavvia il server Quantum Network Suite (QNS)/User Data Channel (UDC), la cache CRD viene creata utilizzando i dati della scheda dorata. Se lo stato BAD del sistema è FALSE, la cache CRD viene creata con MongoDB.

Ecco alcune immagini di errore di CPS Central.

Se il sistema CRD è BAD, allora:

1. La manipolazione della CRD è bloccata. È possibile visualizzare solo i dati.
2. Le API CRD, ad eccezione di _import_all, _list, _query, sono bloccate.
3. Il riavvio del sistema QNS preleva i dati della scheda dalla posizione della scheda dorata.
4. Un riavvio di QNS/UDC non corregge lo stato BAD del sistema né i cali di chiamata, ma crea solo la cache CRD da golden-card.
5. Cache CRD creata con dati golden-card. Se lo stato BAD del sistema è FALSE, la cache delle schede verrà creata con MongoDB.

Di seguito sono riportati i messaggi associati in CPS qns.log:

qns02 qns02 2021-07-29 11:16:50,820 [pool-50847-thread-1] 
INFO c.b.c.i.e.ApplicationInterceptor - System - 
CRD is in bad state. All CRD APIs (except import all, list and query), 
are blocked and user is not allowed to use. 
Please verify your crd schema/crd data and try again!
qns02 qns02 2021-07-28 11:33:59,788 [pool-50847-thread-1] 
WARN c.b.c.i.CustomerReferenceDataManager - 
System is in BAD state. Data will be fetched from svn golden-crd repository.
qns01 qns01 2021-07-28 11:55:24,256 [pool-50847-thread-1] 
WARN c.b.c.i.e.ApplicationInterceptor - ApplicationInterceptor: Is system bad: true

Procedura per il ripristino della CRD dallo stato BAD

Approccio 1.

Per cancellare lo stato del sistema, è necessario importare uno schema CRD valido e corretto da Policy Builder che implica l'importazione di dati CRD validi da CPS Central. Se l'importazione ha esito positivo, lo stato del sistema viene cancellato e tutte le API e le operazioni CRD vengono sbloccate.

Di seguito sono riportati i passaggi dettagliati:

Passaggio 1. Eseguire questo comando per eseguire il backup del database CRD.

Command template:
#mongodump --host <session_manager> --port <cust_ref_data_port> 
--db cust_ref_data -o cust_ref_data_backup 

Sample command:
#mongodump --host sessionmgr01 --port 27717 --db cust_ref_data -o cust_ref_data_backup

Nota: Per l'host e la porta del database CRD, vedere Configurazione dei dati di riferimento personalizzati in PB, come mostrato in questa immagine.

Passaggio 2. Eliminare la tabella CRD (intero DB) utilizzando questa procedura.

Passaggio 2.1. Accedere all'istanza mongo in cui è presente il database CRD.

Command template:
#mongo --host <sessionmgrXX> --port <cust_ref_data_port>

Sample command:
#mongo --host sessionmgr01 --port 27717

Passaggio 2.2. Eseguire questo comando per visualizzare tutti i database presenti nell'istanza mongo.

set01:PRIMARY> show dbs
admin 0.031GB
config 0.031GB
cust_ref_data 0.125GB
local 5.029GB
session_cache 0.031GB
sk_cache 0.031GB
set01:PRIMARY> 

Passaggio 2.3. Eseguire questo comando per passare al database CRD.

set01:PRIMARY> use cust_ref_data
switched to db cust_ref_data
set01:PRIMARY

Passaggio 2.4. Eseguire questo comando per eliminare il database CRD.

set01:PRIMARY> db.dropDatabase()
{
"dropped" : "cust_ref_data",
"ok" : 1,
"operationTime" : Timestamp(1631074286, 13),
"$clusterTime" : {
"clusterTime" : Timestamp(1631074286, 13),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}}}
set01:PRIMARY>

Passaggio 3. Verificare che non esista alcun database con il nome cust_ref_data esistente con il comando show dbs.

set01:PRIMARY> show dbs
admin 0.031GB
config 0.031GB
local 5.029GB
session_cache 0.031GB
sk_cache 0.031GB
set01:PRIMARY> 

Passaggio 4. Accedere a Policy Builder con l'utente "qns-svn" e pubblicare uno schema CRD valido.

Passaggio 5. Riavviare il processo qns su tutti i nodi con restartall.sh da Gestione cluster.

Passaggio 6. Verificare che la diagnostica sia corretta e che non vi siano voci nella tabella CRD. Nelle tabelle CRD deve essere presente solo uno schema, ovvero senza dati.

Passaggio 7. Accedere a CPS Central con l'utente "qns-svn" e importare dati CRD validi.

Passaggio 8. Verificare che, import all returns success message and "system - CRD is BAD" error message not displayed in CPS Central.

Passaggio 9. Verificare che tutte le API CRD siano sbloccate e che sia possibile modificare i dati CRD.

Se il primo approccio non ha funzionato, passare al secondo.

Approccio 2.

Passaggio 1. Identificare l'host e la porta in cui è ospitata l'istanza ADMIN DB Mongo con il comando diagnostics.sh —get_r.

[root@installer ~]# diagnostics.sh --get_r
CPS Diagnostics HA Multi-Node Environment
---------------------------
Checking replica sets...
|----------------------------------------------------------------------------------------------------------------------------------------|
| Mongo:v3.6.17 MONGODB REPLICA-SETS STATUS INFORMATION Date : 2021-09-14 02:56:23 |
|----------------------------------------------------------------------------------------------------------------------------------------|
| SET NAME - PORT : IP ADDRESS - REPLICA STATE - HOST NAME - HEALTH - LAST SYNC - PRIORITY |
|----------------------------------------------------------------------------------------------------------------------------------------|
| ADMIN:set06 |
| Status via arbitervip:27721 sessionmgr01:27721 sessionmgr02:27721 |
| Member-1 - 27721 : - PRIMARY - sessionmgr01 - ON-LINE - -------- - 3 |
| Member-2 - 27721 : - SECONDARY - sessionmgr02 - ON-LINE - 1 sec - 2 |
| Member-3 - 27721 : 192.168.10.146 - ARBITER - arbitervip - ON-LINE - -------- - 0 |
|----------------------------------------------------------------------------------------------------------------------------------------|

Passaggio 2. Accedere all'istanza mongo in cui è presente ADMIN DB.

Command template:
#mongo --host <sessionmgrXX> --port <Admin_DB__port> 

Sample Command:
#mongo --host sessionmgr01 --port 27721

Passaggio 3. Eseguire questo comando per visualizzare tutti i database presenti nell'istanza mongo.

set06:PRIMARY> show dbs
admin 0.078GB
config 0.078GB
diameter 0.078GB
keystore 0.078GB
local 4.076GB
policy_trace 2.078GB
queueing 0.078GB
scheduler 0.078GB
sharding 0.078GB
set06:PRIMARY>

Passaggio 4. Eseguire questo comando per passare al database ADMIN.

set06:PRIMARY> use admin
switched to db admin
set06:PRIMARY>

Passaggio 5. Eseguire questo comando per visualizzare tutte le tabelle presenti nel database ADMIN.

set06:PRIMARY> show tables
state
system.indexes
system.keys
system.version
set06:PRIMARY>

Passaggio 6. Eseguire questo comando per verificare lo stato corrente del sistema.

set06:PRIMARY> db.state.find()
{ "_id" : "state", "isSystemBad" : true, "lastUpdatedDate" : ISODate("2021-08-11T15:01:13.313Z") }
set06:PRIMARY> 

Qui si può vedere che "isSystemBad" : vero. È quindi necessario aggiornare questo campo su "false" per cancellare lo stato BAD della CRD, con il comando fornito nel passaggio successivo.

Passaggio 7. Aggiornare il campo "isSystemBAD" con il comando db.state.updateOne({_id:"state"},{$set:{isSystemBad:false}}.

set06:PRIMARY> db.state.updateOne({_id:"state"},{$set:{isSystemBad:false}})
{ "acknowledged" : true, "matchedCount" : 0, "modifiedCount" : 0 }
set06:PRIMARY>

Passaggio 8. Eseguire il comando db.state.find() per verificare se il valore del campo isSystemBad è stato modificato in false.

set06:PRIMARY> db.state.find()
{ "_id" : "state", "isSystemBad" : false, "lastUpdatedDate" : ISODate("2021-08-11T15:01:13.313Z") }
set06:PRIMARY>

Passaggio 9. Verificare che tutte le API CRD siano sbloccate. È possibile modificare i dati CRD ora.