Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Alta disponibilidad de IM y presencia (HA)

Configuración del grupo de redundancia

Servicios de IM y presencia supervisados

Proceso de conmutación por error del usuario

Temporizador de reconexión del cliente Jabber

Tipos de reserva de IM y presencia

Reserva manual

Reserva automática

El repliegue automático no es la configuración predeterminada, pero se puede habilitar.  Para habilitar el repliegue automático, cambie el parámetro Enable Automatic Fallback (Activar reserva automática) en Server Recovery Manager Service Parameters (Parámetros de servicio del administrador de recuperación del servidor) al valor True (Verdadero).

Troubleshoot

Registros que se recopilarán para la resolución de problemas

Introducción

Este documento describe cómo funciona Instant Message and Presence (IM&P) High Availability (también conocido como Redundancy) en un entorno de IM and Presence empresarial y cómo resolverlo.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

- IM&P de Cisco Unified

- Clientes de Cisco Jabber

Componentes Utilizados

- Cisco Unified IM&P 10.0 y posterior.

- Clientes de Cisco Jabber 9.6 y posteriores.

La información de este documento se creó a partir de los componentes de un entorno de laboratorio específico. Todos los componentes utilizados en este documento comenzaron con una configuración (predeterminada) despejada. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Alta disponibilidad de IM y presencia (HA)

El servidor de servicios de presencia y mensajería instantánea ofrece alta disponibilidad o redundancia en forma de grupos de servidores lógicos en la configuración de CUCM. Esta configuración se pasa a IM and Presence y luego se utiliza para permitir la redundancia en caso de que se produzca una falla en el servicio de IM and Presence o en el servidor.  Cuando se produce un evento HA, las sesiones del usuario final se mueven del servidor que ha fallado a la copia de seguridad.  Cuando el servidor se ha restaurado a un estado normal, el administrador devuelve las sesiones de usuario de forma automática o manual.

Configuración del grupo de redundancia

El grupo de redundancia es el par de servidores lógicos que permite la asignación de un servidor al subclúster de IM y Presence, así como la configuración para HA.  Para acceder a esta parte de la configuración se puede encontrar en la página web del servidor CUCM.

System > Presence Redundancy Groups

Cuando el administrador agrega el editor de IM&P a la configuración System > Server en CUCM y se guarda el servidor de IM&P, se crea el grupo de redundancia DefaultCUPSubCluster con el editor asignado.

Cuando se crea, el grupo de redundancia tiene el siguiente aspecto:

Este grupo de redundancia se traduce al subgrupo IM and Presence. En el estado actual de la configuración de grupo de redundancia en CUCM, así sería en la página web de topología de clúster de IM y presencia:

Vemos que el editor de IM&P está asignado al subclúster de DefaultCUPSy el servidor del suscriptor no lo está.  Esto se debe a que el servidor de suscriptor de IM&P no está asignado al grupo de redundancia en la configuración de CUCM.

Asignación del Suscriptor al Grupo de Redundancia:

Para asignar el servidor del suscriptor al grupo de redundancia, simplemente seleccione el servidor del suscriptor del menú desplegable y luego guarde el cambio de configuración.

Después de agregar el suscriptor de IM&P al grupo de redundancia:

Después de agregar el nodo secundario (el suscriptor), verá que se puede seleccionar la opción Alta disponibilidad. Para habilitar la Alta Disponibilidad, simplemente necesitamos seleccionar la casilla de verificación Habilitar alta disponibilidad y Guardar el cambio de configuración.

Después de habilitar la alta disponibilidad:

A continuación, la página actualiza automáticamente el estado y el motivo del servidor.  Cuando el servidor se encuentra en estado de inicialización, esto significa que los dos servidores pueden comunicarse.  Los servidores luego verificarían el estado del servicio antes de que el estado pase a un estado normal.  Si los dos servidores se pueden conectar entre sí y todos los servicios supervisados están activos en ambos, entonces obtendríamos un estado Normal-Normal. Esto significa que todos los servicios supervisados están activos en los servidores IM&P.

Estado del grupo de redundancia normal:

Estado normal de alta disponibilidad en la página de topología de IM&P:

Servicios de IM y presencia supervisados

Dado que podría tener varios modelos de implementación: IM Only (Sólo IM), IM with SIP/XMPP Federation (IM con federación de SIP/XMPP), IM with Compliance (Mensajería instantánea con chat persistente), Remote Call Control Only (Sólo control de llamadas remoto), etc., la lista real de cuáles de estos procesos deben supervisarse es dinámica. De forma predeterminada, estos elementos siempre se supervisan cuando se habilita HA:

Base de datos IDS

Motor de presencia (si está activado)

Router XCP

El Administrador de recuperación de servidores comprueba si se ha configurado (y activado) el cumplimiento (Message Archiver), el chat persistente (Text Conference Manager), la federación SIP (SIP Federation Connection Manager) y la federación XMPP (XMPP Federation Connection Manager).

Si se configuran y activan, Server Recovery Manager (SRM) también supervisa esos servicios.

Precaución: Antes de continuar con el reinicio de uno o más de los servicios supervisados, debe inhabilitar la alta disponibilidad de los grupos de redundancia de presencia en el servidor CUCM. Lo mismo se aplica cuando se realiza un reinicio de uno o más de los nodos IM&P.

Proceso de conmutación por error del usuario

Cuando se produce una conmutación por fallas (automática o manual), el punto principal que se debe recordar es que la cuenta de usuario no se mueve de un servidor a otro, sino que sólo se mueve la sesión de usuario en el motor de presencia.  En las versiones anteriores a 10 de IM and Presence, la asignación de usuario se trasladó de un servidor a otro.  Este traslado del usuario fue muy costoso para los recursos del servidor y se agregó a la carga que estaba en el servidor.  En 10.X y posteriores, el usuario permanece en el servidor al que está asignado y la sesión del usuario final en el motor de presencia se mueve del nodo fallido al nodo funcional.  El usuario no tiene que salir de Jabber y volver a iniciar sesión cuando el cambio se produce con Server Recovery Manager (SRM).

Temporizador de reconexión del cliente Jabber

Para que la sesión del usuario se active completamente en el nodo de IM&P secundario después de un evento de failover, el usuario debe intentar iniciar sesión en ese servidor a través de SOAP(Agente de perfil del cliente).  Esto sucede automáticamente con la contraseña única que se pasa de la base de datos IMDB. Dado que los inicios de sesión son extremadamente costosos para los recursos del servidor de IM y Presence, debe haber una manera de limitar los inicios de sesión cuando se produce un evento de failover.  Este regulador o búfer permite a todos los usuarios iniciar sesión en el nodo secundario sin interrumpir el servicio para los usuarios del nodo secundario.  Los mecanismos que se utilizan para limitar los inicios de sesión de los usuarios son los parámetros de servicio Client Re-Login Lower Limit y Client Re-Login Upper Limit Server Recovery Manager (SRM).

Límite inferior de reinicio de sesión del cliente: parámetro que define la cantidad mínima de tiempo (en segundos) que el cliente Jabber espera antes de que el cliente intente iniciar sesión en el servidor secundario en caso de un evento HA.

Límite superior de reinicio de sesión del cliente: parámetro que define la cantidad máxima de tiempo (en segundos) que el cliente Jabber espera antes de que el cliente intente iniciar sesión en el servidor secundario en caso de un evento HA.

El cliente Jabber recibe estos parámetros al iniciar sesión en el servidor y almacena en memoria caché los valores para su uso futuro.  Cuando recibimos un evento HA del servidor de IM&P, el cliente elige un número aleatorio de segundos entre los límites superior e inferior y espera esa cantidad de tiempo antes de que el cliente Jabber intente iniciar sesión en el secundario.  Una vez que caduca el temporizador, el cliente entonces intenta iniciar sesión SOAP en el nodo secundario.

Tipos de reserva de IM y presencia

Si hay conmutación por error del usuario, debe haber una reserva del usuario cuando se restaura el servicio en el servidor problemático.  Hay dos tipos de reserva de servidor:

Reserva manual

La reserva manual (configuración predeterminada para Server Recovery Manager) se produce cuando se ha restaurado el servicio y el grupo de redundancia permite el botón de reserva. Cuando se selecciona este botón, las sesiones de usuario que se movieron al nodo secundario se mueven de nuevo a su nodo de inicio. El cliente Jabber luego aplica los límites superior e inferior para el reinicio de sesión.

Reserva automática

El repliegue automático se produce cuando el servidor supervisa los servicios y el servicio Server Recovery Manager (SRM) envía automáticamente a los usuarios a sus nodos alojados. La clave de esta configuración es que el servicio Server Recovery Manager (SRM) espera 30 minutos para que un servicio/servidor fallido permanezca activo antes de que se inicie una reserva automática.  Una vez que se establece este tiempo de actividad de 30 minutos, las sesiones de usuario se mueven de nuevo a sus nodos alojados. El cliente Jabber luego aplica los límites superior e inferior para el reinicio de sesión.

El repliegue automático no es la configuración predeterminada, pero se puede habilitar.  Para habilitar el repliegue automático, cambie el parámetro Enable Automatic Fallback (Activar reserva automática) en Server Recovery Manager Service Parameters (Parámetros de servicio del administrador de recuperación del servidor) al valor True (Verdadero).

Troubleshoot

Esta sección proporciona la información que puede utilizar para resolver problemas de su configuración.

Al solucionar problemas de alta disponibilidad en el servidor de servicio de IM&P, hay dos temporizadores importantes que debe tener en cuenta.

- Los servidores intercambian 4 keepalives cada 60 segundos, si no hay respuesta después de los 60 segundos, Cisco Service Recovery Manager (SRM) considera que el nodo que no responde se desconectó y activa un comando Fail Over. Como muestra el siguiente fragmento, el último latido ocurrió hace 62 segundos.

2021-05-13 02:48:48,244 INFO[HS]rsrm.RsrmHeartBeatHandler - RsrmHeartBeatHandler: peer down, time since last heartbeat[s]= 62

2021-05-13 02:48:48,244 INFO [HS] rsrm.RsrmAutomaticFallback - RsrmAutomaticFallback: peer states vector changed to [Normal,Running in Backup Mode]

Consejo: En esta situación, si ha encontrado alguna latencia en su red, se recomienda aumentar el temporizador de tiempo de espera de latido de 60 a 90 segundos.

Navegue hasta la página web de administración de CUCM > Sistema > Configuración de parámetros de servicio > Seleccione el servidor de IM&P > Seleccione Configuración de Cisco Recovery Manager > En el tiempo de espera Mantener activo (latido) aumente el número a 90 segundos.

- El servidor del suscriptor de IM&P espera 90 segundos, si detecta que uno o más de los servicios monitoreados está inactivo, el servidor del suscriptor toma el control.

Registros que se recopilarán para la resolución de problemas

- Registros de Server Recover Manager (SRM) desde antes y después del evento de failover (nivel de depuración si es posible)

- El resultado del comando a través de la interfaz de línea de comandos de IM&P ejecuta sql select * de enterprisessubcluster

- La tabla enterprise subcluster en IM&P aloja la configuración del grupo de redundancia

- El resultado del comando a través de la interfaz de línea de comandos IM&P run sql select * from enterprisenode

- La tabla enterprisenode muestra la información del nodo y la asignación de subclúster del nodo

- Si el error se produce al detener un servicio, recopile:

- Registros del sistema del visor de eventos

- Registros de aplicaciones del visor de eventos

- Registros del servicio que se detienen.