Gestione delle sessioni del sottoscrittore in caso di replica di sessione impostata in CPS

Introduzione

In questo documento viene descritta la gestione delle sessioni del sottoscrittore in caso di replica di sessione impostata in Cisco Policy Suite (CPS).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Linux
• CPS
• MongoDB

Nota: Cisco consiglia di disporre dell'accesso privilegiato alla CLI di CPS root.

Componenti usati

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

• CPS 20.2
• Unified Computing System (UCS)-B
• MongoDB 3.6.17

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

CPS utilizza MongoDB dove i processi mongood vengono eseguiti sulle macchine virtuali (VM) sessionmgr per costituire la struttura di base del database.

La configurazione minima consigliata per ottenere un'elevata disponibilità per un set di repliche è un set di repliche di tre membri con tre membri contenenti dati: un membro primario e due secondari. In alcune circostanze, ad esempio se si dispone di un server principale e di un server secondario ma i vincoli di costo non consentono l'aggiunta di un server secondario, è possibile scegliere di includere un arbitro. Un arbitro partecipa alle elezioni ma non detiene i dati (cioè, non fornisce la ridondanza dei dati). Nel caso di CPS, normalmente i database di sessione sono configurati in questo modo.

È possibile verificare in /etc/broadhop/mongoConfig.cfg la configurazione del set di repliche per l'installazione di CPS.

[SESSION-SET1]
SETNAME=set01a 
OPLOG_SIZE=5120
ARBITER1=arbitervip:27717
ARBITER_DATA_PATH=/var/data/sessions.27717
MEMBER1=sessionmgr01:27717
MEMBER2=sessionmgr02:27717
DATA_PATH=/var/data/sessions.1/d
SHARD_COUNT=4
SEEDS=sessionmgr01:sessionmgr02:27717
[SESSION-SET1-END]

[SESSION-SET7]
SETNAME=set01g
OPLOG_SIZE=5120
ARBITER1=arbitervip:37717
ARBITER_DATA_PATH=/var/data/sessions.37717
MEMBER1=sessionmgr02:37717
MEMBER2=sessionmgr01:37717
DATA_PATH=/var/data/sessions.1/g
SHARD_COUNT=2
SEEDS=sessionmgr02:sessionmgr01:37717
[SESSION-SET7-END]

MongoDB ha un altro concetto chiamato Sharding che aiuta la ridondanza e la velocità per un cluster. Le partizioni separano il database in set indicizzati che consentono una maggiore velocità di scrittura, migliorando le prestazioni complessive del database. I database condivisi vengono spesso configurati in modo che ogni partizione sia un set di repliche.

• Condivisione sessione: Seed condivise di sessione e relativi database:

osgi> listshards

Shard Id Mongo DB State Backup DB Removed Session Count

1 sessionmgr01:27717/session_cache online false false 109306
2 sessionmgr01:27717/session_cache_2 online false false 109730
3 sessionmgr01:27717/session_cache_3 online false false 109674
4 sessionmgr01:27717/session_cache_4 online false false 108957

• Condivisione chiave secondaria: Seed e relativi database delle condivisioni di chiavi secondarie:
  

osgi> listskshards

Shard Id Mongo DB State Backup DB Removed Session Count

2 sessionmgr02:37717/sk_cache online false false 150306
3 sessionmgr02:37717/sk_cache_2 online false false 149605

Problema

Problema 1. Crescita costante del consumo di memoria del membro dati a causa di un errore del membro singolo.

Quando un membro cuscinetto dati diventa inattivo in 3 membri (2 data-bearing +1 arbitro), l'unico membro cuscinetto dati rimanente assume il ruolo di set primario e di replica continua a funzionare, ma con un carico pesante e set di repliche senza alcuna ridondanza DB. Con un'architettura PSA a tre membri, la pressione della cache aumenta se un nodo portante dati è inattivo. Ciò determina un aumento costante del consumo di memoria per il nodo cuscinetto dati rimanente (primario), potenzialmente portando al guasto del nodo a causa dell'esaurimento della memoria disponibile se lasciato incustodito e causando infine un errore del set di repliche.

------------------------------------------------------------------------------------------------
|[SESSION:set01a]|
|[Status via sessionmgr02:27717 ]|
|[Member-1 - 27717 : 192.168.29.100 - ARBITER - arbitervip - ON-LINE
|[Member-2 - 27717 : 192.168.29.35  - UNKNOWN - sessionmgr01 - OFF-LINE 19765 days 
|[Member-3 - 27717 : 192.168.29.36  - PRIMARY - sessionmgr02 - ON-LINE
------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------
|[SESSION:set01g]|
|[Status via sessionmgr02:37717 ]|
|[Member-1 - 37717 : 192.168.29.100 - ARBITER - arbitervip - ON-LINE
|[Member-2 - 37717 : 192.168.29.35  - UNKNOWN - sessionmgr01 - OFF-LINE 19765 days 
|[Member-3 - 37717 : 192.168.29.36  - PRIMARY - sessionmgr02 - ON-LINE
------------------------------------------------------------------------------------------------

Problema 2. Impatto sulla gestione della sessione a causa di un errore del doppio membro.

Quando entrambi i membri contenenti dati (Sessionmgr01 e sessionmgr02) diventano inattivi in tali set di repliche (errore doppio), l'intero set di repliche diventa inattivo e la relativa funzione di base del database viene compromessa.

Current setup have problem while connecting to the server on port : 27717

Current setup have problem while connecting to the server on port : 37717

L'errore di questo set di repliche determina un errore di chiamata in caso di set di repliche di sessione, poiché i processi di gestione delle chiamate CPS (Quantum Network Suite (qns) Processes) non sono in grado di accedere alle sessioni già archiviate in tali set di repliche con errori.

Soluzione

Approccio 1. In Caso Di Guasto Di Un Singolo Membro.

È necessario essere in grado di ripristinare il membro del set di repliche non riuscito in un'architettura PSA (Primary-Secondary-Arbiter) in un breve intervallo di tempo. Se il ripristino di un membro del supporto dati non riuscito in un'architettura PSA richiede tempo, è necessario rimuovere il membro non riuscito.

Passaggio 1.1. Identificare il membro contenitore di dati con errori nel set di repliche specifico con architettura PSA a tre membri. Eseguire questo comando da Gestione cluster.

  #diagnostics.sh --get_r

Passaggio 1.2. Rimuovere il membro cuscinetto dati non riuscito dal set di repliche specifico.

 Syntax:

 Usage: build_set.sh <--option1> <--option2> [--setname SETNAME] [--help]

 option1: Database name
 option2: Build operations (create, add or remove members)

 Example:

 #build_set.sh --session --remove-failed-members --setname set01a --force
 #build_set.sh --session --remove-failed-members --setname set01g --force

Passaggio 1.3. Verificare che il membro non riuscito sia stato rimosso dal set di repliche.

 #diagnostics.sh --get_r

Approccio 2. In Caso Di Errore Di Doppio Membro.

Questa soluzione non è definitiva quando entrambi i membri contenenti dati sono disattivati in un set di repliche PSA 3. Si tratta piuttosto di una soluzione temporanea per evitare o ridurre gli errori di chiamata e garantire una gestione del traffico senza interruzioni, rimuovendo i membri danneggiati dal rispettivo set di repliche, dalla condivisione di sessione e dalla condivisione di chiave. Dovete lavorare al ripristino dei membri falliti il prima possibile, al fine di evitare ulteriori effetti indesiderati.

Passaggio 2.1. Poiché i set di repliche della sessione sono inattivi perché Sessionmgr09 e Sessionmgr10 sono inattivi, è necessario rimuovere le voci di questi set di repliche dalla condivisione di sessione e dalla partizione dalla console OSGI:

#telnet qns0x 9091

osgi> listshards

Shard Id Mongo DB State Backup DB Removed Session Count

1 sessionmgr01:27717/session_cache online false false 109306
2 sessionmgr01:27717/session_cache_2 online false false 109730
3 sessionmgr01:27717/session_cache_3 online false false 109674
4 sessionmgr01:27717/session_cache_4 online false false 108957

osgi> listskshards

Shard Id Mongo DB State Backup DB Removed Session Count
2 sessionmgr02:37717/sk_cache online false false 150306
3 sessionmgr02:37717/sk_cache_2 online false false 149605

Passaggio 2.2. Rimuovere le seguenti schede di sessione:

 osgi> removeshard 1
 osgi> removeshard 2
 osgi> removeshard 3
 osgi> removeshard 4

Passaggio 2.3. Rimuovere i seguenti skard:

osgi> removeskshard 2
osgi> removeskshard 3

Passaggio 2.4.Prima di eseguire il ribilanciamento, verificare il database di amministrazione (verificare che la versione dell'istanza corrisponda per tutte le VM qns):

 #mongo sessionmgrxx:xxxx/sharding.     [Note: use the primary sessionmgr hostname and respective port for login]

 #set05:PRIMARY>  db.instances.find()
 { "_id" : "qns02-1", "version" : 961 }
 { "_id" : "qns07-1", "version" : 961 }
 { "_id" : "qns08-1", "version" : 961 }
 { "_id" : "qns04-1", "version" : 961 }
 { "_id" : "qns08-1", "version" : 961 }
 { "_id" : "qns05-1", "version" : 961 }

Note: if the sharding versions (previous output) are different for some QNS instances. For example, if you see:

{ "_id" : "qns08-1", "version" : 961 }
{ "_id" : "qns04-1", "version" : 962 }

Eseguire questo comando sul database di condivisione di amministrazione (utilizzando il nome host corretto):

Nota: Se il membro è secondario, utilizzare rs.slaveOk() per eseguire i comandi.

[root@casant01-cm csv]#  mongo sessionmgr01:27721/shardin
set05:PRIMARY>
set05:PRIMARY> db.instances.remove({ “_id” : “$QNS_hostname”})


Example:

set05:PRIMARY> db.instances.remove({ “_id” : “qns04-1”})
set05:PRIMARY> exit

Passaggio 2.5. Eseguire il ribilanciamento della condivisione di sessione.

Login to osgi console.

#telnet qns0x 9091

osgi>listshards

osgi>rebalance

osgi>rebalancestatus

Verify shards:

osgi>listshards

Passaggio 2.6. Eseguire il ribilanciamento delle condivisioni di chiave:

Login to osgi console.

#telnet qns0x 9091

osgi>listskshard

osgi>rebalancesk

osgi>rebalanceskstatus

Verify shards:

osgi>listshards

Passaggio 2.7. Rimuovere il set di repliche set01a e set01g (esegui su colonna):

#build_set.sh --session --remove-replica-set --setname set01a --force
#build_set.sh --session --remove-replica-set --setname set01g --force

Passaggio 2.8. Riavviare il servizio qns (eseguito su una colonna):

#restartall.sh

Passaggio 2.9. Rimuovere le righe set01a e set01g dal file mongoConfig.cfg. Esegui in Gestione cluster:

#cd /etc/broadhop/
#/bin/cp -p mongoConfig.cfg mongoConfig.cfg_backup_
#vi mongoConfig.cfg

[SESSION-SET1]
SETNAME=set01a 
OPLOG_SIZE=5120
ARBITER1=arbitervip:27717
ARBITER_DATA_PATH=/var/data/sessions.27717
MEMBER1=sessionmgr01:27717
MEMBER2=sessionmgr02:27717
DATA_PATH=/var/data/sessions.1/d
SHARD_COUNT=4
SEEDS=sessionmgr01:sessionmgr02:27717
[SESSION-SET1-END]

[SESSION-SET7]
SETNAME=set01g
OPLOG_SIZE=5120
ARBITER1=arbitervip:37717
ARBITER_DATA_PATH=/var/data/sessions.37717
MEMBER1=sessionmgr02:37717
MEMBER2=sessionmgr01:37717
DATA_PATH=/var/data/sessions.1/g
SHARD_COUNT=2
SEEDS=sessionmgr02:sessionmgr01:37717
[SESSION-SET7-END]

Passaggio 2.10. Dopo aver rimosso le linee, salvare e uscire.

Eseguire build_etc in Gestione cluster.

#/var/qps/install/current/scripts/build/build_etc.sh

Passaggio 2.11. Verificare che il set di repliche set01d venga rimosso mediante la diagnostica.

#diagnostics.sh --get_r