Procedure om CRD in slechte staat te herstellen in CPS

Inleiding

In dit document wordt de procedure beschreven om de tabel Aangepaste Referentie-gegevens (CRD) van Cisco Policy Suite (CPS) te herstellen vanuit de BAD-status.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Linux
• CPS
• MongoDB

Cisco raadt u aan bevoorrechte toegang te hebben:

• Toegang tot voet aan CPS CLI
• "qns-svn" gebruikerstoegang tot CPS GUI's (Policy building and CPS Central)
  
  

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

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

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Achtergrondinformatie

In CPS wordt de CRD-tabel gebruikt om informatie op te slaan over de configuratie van het op maat gesneden beleid, die wordt gepubliceerd in Policy Builder en gekoppeld aan de CRD-DB, die aanwezig is in de MongoDB-instantie die op sessionemer wordt georganiseerd. In de CRD-tabel worden door middel van CPS Central GUI export- en importbewerkingen uitgevoerd om de CRD-tabelgegevens te kunnen manipuleren.

Probleem 

Als er een fout is opgetreden tijdens het importeren van alle bewerkingen, stopt CPS het proces, stelt het systeem in de BAD-status in en blokkeert de uitvoering van CRD API's. CPS stuurt een foutreactie naar de client die aangeeft dat het systeem in BAD-toestand verkeert. Als het systeem in BAD-status is en u het Quantum Network Suite (QNS)/User Data Channel (UDC)-server herstart, dan wordt het CRD-cache gebouwd door het gebruik van gouden CD-gegevens. Als de BAD status FALSE is, dan wordt het CRD cache gebouwd met MongoDB.

Hier zijn CPS Central-foutenbeelden ter referentie.

Als het CRD-systeem SLECHT is, dan:

1. Manipulatie van CRD is geblokkeerd. U kunt alleen de gegevens bekijken.
2. CRD API's, behalve _import_all, _list en_query, worden geblokkeerd.
3. QNS halen opnieuw CRD-gegevens op van de gouden CD-locatie.
4. Een herstart van de QNS/UDC kan de BAD-status van het systeem niet herstellen en geen aanroepen doen, maar het bouwt alleen CRD-cache van gouden crd.
5. CRD cache met gouden cd-gegevens. Als de BAD status FALSE is, dan is het crd cache gebouwd met MongoDB.

Dit zijn gekoppelde berichten 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

Procedure om de CRD in de BAD-staat te herstellen

Aanpak 1.

Om de systeemstatus te wissen, moet u een geldig en correct CRD-schema van Policy Builder importeren dat de invoer van geldige CRD-gegevens van CPS Central omvat, als de invoer van alle gegevens succesvol is, moet u de systeemstatus klaren en alle CRD APIs en bewerkingen worden vrijgegeven.

Hieronder volgen de volgende stappen:

Stap 1. Start deze opdracht naar de back-up van de CRD-database.

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

Opmerking: Raadpleeg voor CRD DB host en poort de configuratie van aangepaste referentiegegevens in PB zoals in deze afbeelding.

Stap 2. Laat de CRD-tabel (volledige DB) vallen met behulp van deze procedure.

Stap 2.1. Meld u aan bij de mongoinstantie waar CRD DB aanwezig is.

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

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

Stap 2.2. Start deze opdracht om alle DB’s die in de mongoinstantie aanwezig zijn, weer te geven.

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> 

Stap 2.3. Start deze opdracht om naar CRD DB te Switches.

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

Stap 2.4. Start deze opdracht om CRD DB te laten vallen.

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>

Stap 3. Controleer dat er geen db met name cust_ref_data is die met het commando dbs bestaat.

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

Stap 4. Meld u aan bij Policy Building met "qns-svn" gebruiker en publiceer een geldig CRD-schema.

Stap 5. Start het qns-proces opnieuw op alle knooppunten met restartall.sh vanuit Cluster Manager.

Stap 6. Controleer dat de diagnostiek goed is en dat de CRD-tabel geen gegevens bevat. In de CRD-tabellen moet er alleen een schema aanwezig zijn, d.w.z. zonder gegevens.

Stap 7. Meld u aan bij CPS Central met de "qns-svn"-gebruiker en voer geldige CRD-gegevens in.

Stap 8. Controleer dat, alle opbrengsten uit een geslaagd bericht en de foutmelding "systeem - CRD is SLECHTS" niet in CPS Central wordt weergegeven.

Stap 9. Controleer dat, alle CRD API’s nu worden vrijgegeven, u CRD-gegevens nu kunt manipuleren.

Als de eerste aanpak niet werkte, ga dan voor de tweede aanpak.

Aanpak 2.

Stap 1. Identificeer de host en de poort waarin de ADMIN DB Mongo-instantie wordt georganiseerd met de opdracht diagnostiek.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 |
|----------------------------------------------------------------------------------------------------------------------------------------|

Stap 2. Meld u aan bij de mongoinstantie waar ADMIN DB aanwezig is.

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

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

Stap 3. Start deze opdracht om alle DB's weer te geven die in de mongoinstantie aanwezig zijn.

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>

Stap 4. Start deze opdracht om naar ADMIN DB te switches.

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

Stap 5. Start deze opdracht om alle tabellen in ADMIN-DB weer te geven.

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

Stap 6. Start deze opdracht om de huidige status van het systeem te controleren.

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

Hier zie je dat "isSystemBad" : Ja. Daarom moet u dit veld naar 'vals' bijwerken om de status van CRD BAD te wissen, met de opdracht in de volgende stap.

Stap 7. update het veld "isSystemBAD" met de opdracht db.state.updateOne (<_id:"state"}, {2$set: {isSystemBad:valse}).

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

Stap 8. Start de opdracht db.state.found() om te controleren of de veldwaarde SystemBad is gewijzigd in vals.

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

Stap 9. Controleer dat alle CRD API’s nu worden vrijgegeven, zodat u CRD-gegevens nu kunt manipuleren.