Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Achtergrondinformatie

Probleem

Procedure om de CRD in de BAD-staat te herstellen

Aanpak 1.

Aanpak 2.

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.