Gestión de sesiones de suscriptores en caso de réplica de sesiones establecida en CPS

Introducción

Este documento describe el manejo de sesiones de suscriptor en caso de réplica de sesión establecida en Cisco Policy Suite (CPS).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Linux
• CPS
• MongoDB

Nota: Cisco recomienda que debe tener acceso de raíz con privilegios a la CLI de CPS.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• CPS 20.2
• Unified Computing System (UCS)-B
• MongoDB-v3.6.17

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

CPS utiliza MongoDB, donde se ejecutan los procesos de mongood en las máquinas virtuales (VM) sessionmgr para constituir su estructura básica de base de datos.

La configuración mínima recomendada para disponer de alta disponibilidad para un conjunto de réplicas es un conjunto de réplicas de tres miembros con tres miembros que contienen datos: un miembro primario y dos miembros secundarios. En algunas circunstancias (por ejemplo, si tiene un árbitro principal y un secundario pero las restricciones de costo prohíben agregar otro secundario), puede optar por incluir un árbitro. Un árbitro participa en las elecciones pero no tiene datos (es decir, no proporciona redundancia de datos). En el caso de CPS, normalmente las bases de datos de sesión se configuran de esta manera.

Puede verificar en /etc/broadhop/mongoConfig.cfg la configuración del conjunto de réplicas para su configuración de 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 tiene otro concepto llamado Sharding que ayuda a la redundancia y la velocidad de un clúster. Los archivos compartidos separan la base de datos en conjuntos indexados, lo que permite una velocidad mucho mayor de escritura, lo que mejora el rendimiento general de la base de datos. Las bases de datos compartidas se suelen configurar de modo que cada recurso compartido sea un conjunto de réplicas.

• Sesión compartida: Sesión de semillas compartidas y sus bases de datos:

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

• Uso compartido de clave secundaria: Secondary Key comparte semillas y sus bases de datos:
  

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. Crecimiento constante del consumo de memoria de los miembros de datos debido a un fallo en un solo miembro.

Cuando un miembro con datos cae en 3 miembros (2 con datos +1 árbitro), el único miembro con datos que queda asume la función de conjunto principal y de réplica sigue funcionando, pero con carga pesada y conjunto de réplicas sin redundancia de base de datos. Con una arquitectura PSA de tres miembros, la presión de caché aumenta si algún nodo con datos está caído. Esto da lugar a un aumento constante del consumo de memoria para el nodo con datos restante (principal), lo que podría provocar el fallo del nodo debido al agotamiento de la memoria disponible si se deja desatendido y, en última instancia, provoca un fallo del conjunto 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
------------------------------------------------------------------------------------------------

Problema 2. Impacto en la gestión de sesiones debido a un error de doble miembro.

Cuando tanto los miembros que contienen datos (Sessionmgr01 y sessionmgr02) se desactivan en dichos conjuntos de réplicas (Double-failure), todo el conjunto de réplicas se desactiva y su función básica de base de datos se ve comprometida.

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

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

Este error en el conjunto de réplicas provoca un error en la llamada en el caso de los conjuntos de réplicas de sesiones, ya que los procesos de gestión de llamadas de CPS (procesos de Quantum Network Suite (qns)) no pueden tener acceso a las sesiones que ya están almacenadas en esos conjuntos de réplicas con errores.

Solución

Enfoque 1. Para fallos de un solo miembro.

Debe poder recuperar el miembro del conjunto de réplicas que ha fallado en una arquitectura de Árbitro primario-secundario (PSA) con un período de tiempo corto. En caso de que la restauración de un miembro portador de datos fallido en una arquitectura PSA lleve tiempo, debe quitar el miembro fallado.

Paso 1.1. Identifique el miembro portador de datos fallido en el conjunto de réplicas determinado con arquitectura PSA de tres miembros. Ejecute este comando desde el Administrador de clústeres.

  #diagnostics.sh --get_r

Paso 1.2. Remueva el miembro del cojinete de datos fallido del conjunto de réplicas determinado.

 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

Paso 1.3. Compruebe que el miembro con error se ha quitado del conjunto de réplicas.

 #diagnostics.sh --get_r

Enfoque 2. Para fallos de miembro doble.

Esta no es una solución alternativa permanente cuando ambos miembros portadores de datos se desactivan en un conjunto de réplicas PSA 3. Más bien, se trata de una solución temporal para evitar o reducir los errores de llamada y garantizar una gestión del tráfico sin problemas, mediante la eliminación de los miembros con errores del conjunto de réplicas respectivo, el uso compartido de sesión y el uso compartido de sk en consecuencia. Usted debe trabajar en la restauración de los miembros fallidos tan pronto como sea posible, para evitar cualquier efecto indeseable adicional.

Paso 2.1. Dado que los conjuntos de réplicas de sesiones están inactivos al estar inactivos Sessionmgr09 y Sessionmgr10, debe eliminar las entradas de estos conjuntos de réplicas del recurso compartido de sesión y del recurso compartido de la consola 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

Paso 2.2. Elimine estos fragmentos de sesión:

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

Paso 2.3. Retire estos fragmentos:

osgi> removeskshard 2
osgi> removeskshard 3

Paso 2.4.Antes de volver a equilibrar, verifique la base de datos de administración (verifique que la versión de la instancia coincida para todas las máquinas virtuales 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 }

Ejecute este comando en la base de datos compartida de administración (utilizando el nombre de host adecuado):

Nota: Si está en un miembro secundario, utilice rs.slaveOk() para poder ejecutar comandos.

[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

Paso 2.5. Ahora ejecute el reequilibrio del recurso compartido de sesión.

Login to osgi console.

#telnet qns0x 9091

osgi>listshards

osgi>rebalance

osgi>rebalancestatus

Verify shards:

osgi>listshards

Paso 2.6. Ejecute sk shard rebalance:

Login to osgi console.

#telnet qns0x 9091

osgi>listskshard

osgi>rebalancesk

osgi>rebalanceskstatus

Verify shards:

osgi>listshards

Paso 2.7. Remueva el conjunto de réplicas set01a y set01g (ejecute en cluman):

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

Paso 2.8. Reinicie el servicio qns (ejecute en el clúster):

#restartall.sh

Paso 2.9. Remueva las líneas set01a y set01g del archivo mongoConfig.cfg. Ejecute esto en el Administrador de clústeres:

#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]

Paso 2.10. Después de eliminar las líneas, guarde y salga.

Ejecute build_etc en el Administrador de clústeres.

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

Paso 2.11. Verifique que el conjunto de réplicas set01d se elimine mediante el diagnóstico.

#diagnostics.sh --get_r