Procedimento para restaurar o CRD do estado inválido no CPS

Introduction

Este documento descreve o procedimento para restaurar a tabela de Dados de Referência Personalizada (CRD - Custom Reference Data) do Cisco Policy Suite (CPS) do estado BAD.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Linux
• CPS
• MongoDB

A Cisco recomenda que você tenha acesso privilegiado:

• Acesso raiz à CLI do CPS
• acesso de usuário "qns-svn" às GUIs do CPS (Policy Builder e CPS Central)
  
  

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

No CPS, a tabela de CRD é usada para armazenar informações de configuração de política personalizada que são publicadas do Policy Builder e associadas ao CRD DB que está presente na instância MongoDB hospedada no sessionmgr. As operações de exportação e importação são executadas na tabela CRD por meio da GUI Central do CPS para manipular os dados da tabela do CRD.

Problema 

Se houver algum tipo de erro ao importar todas as operações, o CPS interrompe o processo, define o sistema no estado BAD e bloqueia a execução de APIs do CRD. O CPS envia uma resposta de erro ao cliente que afirma que o sistema está no estado BAD. Se o sistema estiver no estado BAD e você reiniciar o servidor Quantum Network Suite (QNS)/User Data Channel (UDC), o cache de CRD será criado com o uso de dados de cartão dourado. Se o estado BAD do sistema for FALSE, o cache do CRD será criado com MongoDB.

Aqui estão as imagens de erro do CPS Central para referência.

Se o sistema de CRD for BAD, então:

1. A manipulação de CRD está bloqueada. Você só pode exibir os dados.
2. As APIs do CRD, exceto _import_all, _list, _query, estão bloqueadas.
3. A reinicialização do QNS coleta dados de CRD do local da placa de ouro.
4. Uma reinicialização do QNS/UDC não corrige o estado BAD do sistema nem quedas de chamada, ele só cria o cache do CRD a partir da placa de ouro.
5. Cache de CRD criado com dados de placa de ouro. Se o estado BAD do sistema for FALSE, o cache do crd será criado com MongoDB.

Aqui estão mensagens associadas no 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

Procedimento para restaurar o CRD do estado BAD

Abordagem 1.

Para limpar o estado do sistema, você precisa importar o esquema de CRD válido e correto do Policy Builder que envolva a importação de dados de CRD válidos do CPS Central. Se a importação de todos for bem-sucedida, ele limpará o estado do sistema e todas as APIs e operações de CRD serão desbloqueadas.

Veja aqui as etapas detalhadas:

Etapa 1. Execute esse comando para fazer backup do banco de dados de 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

Note: Para o host e a porta do CRD DB, consulte Configuração de Dados de Referência Personalizada em PB, como mostrado nesta imagem.

Etapa 2. Descarte a tabela de CRD (DB inteiro) com o uso desse procedimento.

Etapa 2.1. Faça login na instância mongo onde o CRD DB está presente.

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

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

Etapa 2.2. Execute esse comando para exibir todos os DBs presentes na instância 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> 

Etapa 2.3. Execute esse comando para Alternar para o CRD DB.

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

Etapa 2.4. Execute esse comando para descartar o CRD DB.

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>

Etapa 3. Verifique se não há nenhum db com o nome cust_ref_data que exista com o 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> 

Etapa 4. Faça login no Policy Builder com o usuário "qns-svn" e publique um esquema de CRD válido.

Etapa 5. Reinicie o processo qns em todos os nós com restartall.sh do Gerenciador de Cluster.

Etapa 6. Verifique se o diagnóstico está correto e se não há entrada na tabela CRD. Deve haver apenas um esquema presente nas tabelas do CRD, por exemplo, sem nenhum dado.

Passo 7. Faça login no CPS Central com o usuário "qns-svn" e importe dados de CRD válidos.

Etapa 8. Verifique se, importe todas as devoluções mensagem bem-sucedida e a mensagem de erro "system - CRD is BAD" não é exibida no CPS Central.

Etapa 9. Verifique se, agora, todas as APIs de CRD estão desbloqueadas, você pode manipular os dados de CRD agora.

Se a primeira abordagem não funcionou, então vá para a segunda abordagem.

Abordagem 2.

Etapa 1. Identifique o host e a porta na qual a instância do DMIN DB Mongo é hospedada com o 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 |
|----------------------------------------------------------------------------------------------------------------------------------------|

Etapa 2. Faça login na instância mongo onde o ADMIN DB está presente.

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

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

Etapa 3. Execute esse comando para exibir todos os DBs presentes na instância 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>

Etapa 4. Execute este comando para alternar para ADMIN DB.

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

Etapa 5. Execute esse comando para exibir todas as tabelas presentes no DB ADMIN.

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

Etapa 6. Execute esse comando para verificar o estado atual do sistema.

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

Aqui você pode ver que "isSystemBad" : verdadeiro. Portanto, você deve atualizar esse campo para "false" para limpar o estado de CRD BAD, com o comando fornecido na próxima etapa.

Passo 7. Atualize o campo "isSystemBAD" com o 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>

Etapa 8. Execute o comando db.state.find() para verificar se isSystemBad o valor do campo mudou para false.

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

Etapa 9. Verifique se todas as APIs de CRD estão desbloqueadas agora, você pode manipular os dados de CRD agora.