Gestion des sessions des abonnés en cas d'établissement d'un réplica de session dans CPS

Introduction

Ce document décrit la gestion des sessions d'abonné en cas de configuration d'un réplica de session dans Cisco Policy Suite (CPS).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Linux
• CPS
• base de données mongole

Remarque : Cisco recommande de disposer d'un accès racine privilégié à l'interface de ligne de commande CPS.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• CPS 20.2
• Système d'informatique unifiée (UCS)-B
• MongoDB-v3.6.17

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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

CPS utilise MongoDB où les processus mongod s'exécutent sur les machines virtuelles (VM) sessionmgr afin de constituer sa structure de base de données de base.

La configuration minimale recommandée pour bénéficier d'une haute disponibilité pour un jeu de réplicas est un jeu de réplicas à trois membres avec trois membres porteurs de données : un membre principal et deux membres secondaires. Dans certaines circonstances (par exemple, si vous avez un arbitre principal et un arbitre secondaire, mais que les contraintes de coût interdisent l'ajout d'un autre arbitre secondaire), vous pouvez choisir d'inclure un arbitre. Un arbitre participe aux élections mais ne détient pas de données (c'est-à-dire qu'il ne fournit pas de redondance des données). Dans le cas de CPS, les bases de données de session sont normalement configurées de cette manière.

Vous pouvez vérifier dans /etc/broadhop/mongoConfig.cfg la configuration du jeu de réplicas pour votre configuration 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 a un autre concept appelé Partage qui aide la redondance et la vitesse pour un cluster. Les fragments séparent la base de données en ensembles indexés, ce qui permet d'accélérer les écritures et d'améliorer les performances globales de la base de données. Les bases de données partagées sont souvent configurées de sorte que chaque partage soit un jeu de réplicas.

• Partage de session : Seeds partagés de session et ses bases de données :

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

• Partage de clé secondaire : Secondary Key partage les semences et ses bases de données :
  

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

Problème

Problème 1. Croissance régulière de la consommation de mémoire des membres de données en raison d’une défaillance d’un seul membre.

Lorsqu'un élément porteur de données tombe en panne dans 3 éléments (2 éléments porteurs de données + 1 arbitre), le seul élément porteur de données restant joue le rôle de principal et de réplica, mais avec une charge et un réplica lourds sans redondance de base de données. Avec une architecture PSA à trois éléments, la pression du cache augmente si un noeud porteur de données tombe en panne. Cela se traduit par une augmentation constante de la consommation de mémoire pour le noeud porteur de données restant (principal), ce qui peut entraîner la défaillance du noeud en raison de la pénurie de mémoire disponible si elle n'est pas surveillée et, finalement, la défaillance du jeu de réplicas.

------------------------------------------------------------------------------------------------
|[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
------------------------------------------------------------------------------------------------

Problème 2. Impact sur le traitement des sessions en raison d’une défaillance de deux membres.

Lorsque les deux éléments porteurs de données (Sessionmgr01 et Sessionmgr02) tombent en panne dans ces jeux de réplicas (Double-failure), l'ensemble du jeu de réplicas tombe en panne et sa fonction de base de données est compromise.

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

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

Cet échec du jeu de réplicas entraîne un échec d'appel dans le cas des jeux de réplicas de session, car les processus de traitement des appels CPS (processus Quantum Network Suite (qns)) ne peuvent pas accéder aux sessions qui sont déjà stockées dans ces jeux de réplicas en échec.

Solution

Approche 1. Pour la défaillance d'un seul membre.

Vous devez être en mesure de rétablir le membre de jeu de réplicas défaillant dans une architecture PSA (Primary-Secondary-Arbitre) avec un court laps de temps. Si la restauration d'un élément porteur de données défaillant dans une architecture PSA prend du temps, vous devez supprimer l'élément défaillant.

Étape 1.1. Identifiez le membre portant des données défaillant dans le jeu de réplicas particulier avec l’architecture PSA à trois membres. Exécutez cette commande à partir du Gestionnaire de cluster.

  #diagnostics.sh --get_r

Étape 1.2. Supprimer le membre portant des données défaillant du jeu de réplicas particulier.

 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

Étape 1.3. Vérification de la suppression du membre défaillant du jeu de réplicas

 #diagnostics.sh --get_r

Approche 2. En Cas De Défaillance De Double Membre.

Il ne s'agit pas d'une solution de contournement permanente lorsque les deux membres porteurs de données tombent en panne dans un jeu de réplicas 3 PSA. Il s'agit plutôt d'une solution de contournement temporaire visant à éviter ou à réduire les échecs d'appel et à assurer une gestion transparente du trafic, en supprimant les membres défaillants du jeu de réplicas, du partage de session et du partage de tâche respectifs en conséquence. Vous devez travailler sur la restauration des membres défaillants dès que possible, afin d'éviter tout autre effet indésirable.

Étape 2.1. Puisque les jeux de réplicas de session sont désactivés lorsque Sessionmgr09 et Sessionmgr10 sont désactivés, vous devez supprimer ces entrées de jeux de réplicas de session shard et skshard de la 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

Étape 2.2. Supprimez ces partages de session :

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

Étape 2.3. Retirez ces tessons :

osgi> removeskshard 2
osgi> removeskshard 3

Étape 2.4.Avant d'effectuer le rééquilibrage, vérifiez la base de données d'administration (vérifiez que la version de l'instance correspond à toutes les machines virtuelles 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 }

Exécutez cette commande sur la base de données de partage admin (en utilisant le nom d'hôte approprié) :

Remarque : Si vous êtes sur un membre secondaire, utilisez rs.slaveOk() pour pouvoir exécuter des commandes.

[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

Étape 2.5. Exécutez à présent le rééquilibrage du partage de session.

Login to osgi console.

#telnet qns0x 9091

osgi>listshards

osgi>rebalance

osgi>rebalancestatus

Verify shards:

osgi>listshards

Étape 2.6. Exécutez le rééquilibrage du partage de disque :

Login to osgi console.

#telnet qns0x 9091

osgi>listskshard

osgi>rebalancesk

osgi>rebalanceskstatus

Verify shards:

osgi>listshards

Étape 2.7. Supprimez les jeux de réplicas set01a et set01g (exécutés sur la colonne) :

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

Étape 2.8. Redémarrez le service qns (exécuté sur la colonne) :

#restartall.sh

Étape 2.9. Supprimez les lignes set01a et set01g du fichier mongoConfig.cfg. Exécutez ceci sur le Gestionnaire de 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]

Étape 2.10. Après avoir supprimé les lignes, enregistrez et quittez.

Exécutez build_etc sur Cluster Manager.

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

Étape 2.11. Vérifiez que le jeu de réplicas set01d est supprimé par le biais des diagnostics.

#diagnostics.sh --get_r