Configurar a Alta Disponibilidade do Servidor IM e Presence

Introduction

Este documento descreve como a Alta Disponibilidade de Mensagens Instantâneas e Presença (IM&P) (também conhecida como Redundância) funciona em um ambiente corporativo de IM e Presença e como solucioná-lo.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Cisco Unified IM&P
• Clientes Cisco Jabber

Componentes Utilizados

• Cisco Unified IM&P 10.0 e posterior.
• Clientes Cisco Jabber 9.6 e posteriores.

As informações neste documento foram criadas a partir dos componentes em um ambiente de laboratório específico. Todos os componentes usados neste documento foram iniciados com uma configuração limpa (padrão). Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Alta disponibilidade (HA) de mensagens instantâneas e presença

O Servidor de Serviços de IM e Presença oferece alta disponibilidade ou redundância na forma de grupos de servidores lógicos na configuração do CUCM. Essa configuração é passada para IM e Presence e, em seguida, utilizada para permitir a redundância no caso de uma falha de IM e Presence Service ou do servidor.  Quando um evento de HA ocorre, as sessões do usuário final são movidas do servidor com falha para o backup.  Quando o servidor é restaurado para um estado normal, as sessões de usuário são movidas de volta automática ou manualmente pelo administrador.  

Configuração do grupo de redundância

O grupo de redundância é o par de servidores lógicos que permite a atribuição de um servidor ao subcluster IM e Presence, bem como a configuração para HA.  Para acessar essa parte da configuração, acesse a página da Web do servidor CUCM.

Sistema > Grupos de redundância de presença

Quando o administrador adiciona o Editor de IM&P à configuração System > Server no CUCM e o servidor de IM&P é salvo, o grupo de redundância DefaultCUPSubCluster é criado com o Editor atribuído a ele.  

Quando criado, o grupo de redundância é semelhante a este:

Esse grupo de redundância é convertido para o subcluster IM e Presence. No estado atual da configuração do grupo de redundância no CUCM, seria assim que seria na página da Web Topologia de cluster de IM e presença:

Vemos que o Editor de IM&P está atribuído ao cluster DefaultCUPSubcluster e que o servidor de Assinante não está.  Isso ocorre porque o servidor do Assinante IM&P não está atribuído ao Grupo de Redundância na configuração do CUCM.

Atribua o assinante ao grupo de redundância:

Para atribuir o servidor do assinante ao grupo de redundância, basta selecionar o servidor do assinante no menu suspenso e salvar a alteração de configuração.

Depois que o Assinante IM&P for adicionado ao Grupo de redundância:

Após a adição do nó secundário (o assinante), você verá que a opção Alta disponibilidade pode ser selecionada. Para habilitar a alta disponibilidade, basta marcar a caixa de seleção Habilitar alta disponibilidade e Salvar a alteração de configuração.

Depois que a alta disponibilidade for habilitada:

A página atualiza automaticamente o estado e o motivo do servidor.  Quando o servidor está em um estado de inicialização, isso significa que os dois servidores podem se comunicar.  Em seguida, os servidores verificariam o status do serviço antes de o estado passar para um estado Normal.  Se os dois servidores puderem se conectar entre si e todos os serviços monitorados estiverem ativos em ambos, obteremos um estado Normal. Isso significa que todos os serviços monitorados estão ativos nos Servidores IM&P.

Estado normal do grupo de redundância:

Normal-Normal High Availability State na página de topologia IM&P:

Serviços de mensagens instantâneas e presença monitorados

Como você pode ter vários modelos de implantação: Somente IM, IM com SIP/XMPP Federation, IM com conformidade, IM com chat persistente, controle de chamada remoto apenas e assim por diante, a lista real de quais desses processos monitorar é dinâmica. Por padrão, esses itens são sempre monitorados quando o HA está ativado:

Banco de dados IDS

Mecanismo de presença (se ativado)

Roteador XCP

O Server Recovery Manager verifica se a conformidade (Message Archiver), o chat persistente (Text Conference Manager), a federação SIP (SIP Federation Connection Manager), a federação XMPP (XMPP Federation Connection Manager) estão configurados (e ativados).  

Se ambos estiverem configurados e ativados, o SRM (Server Recovery Manager, Gerenciador de Recuperação do Servidor) também monitora esses serviços.

Caution: Antes de continuar com uma reinicialização de um ou mais dos serviços monitorados, é necessário desativar a Alta Disponibilidade dos Grupos de Redundância de Presença no servidor CUCM. O mesmo se aplica quando uma reinicialização de um ou mais dos nós IM&P é executada.

Processo de failover do usuário

Quando ocorre um failover (automático ou manual), o ponto principal a ser lembrado é que a conta de usuário não é movida de um servidor para outro, mas apenas a sessão de usuário no Presence Engine é movida.  Nas versões anteriores a 10 do IM e Presence, a atribuição do usuário foi movida de um servidor para o outro.  Essa mudança de usuário era muito cara para os recursos do servidor e foi adicionada à carga que estava no servidor.  Na versão 10.X ou posterior, o usuário permanece hospedado no servidor ao qual está atribuído, e a sessão de usuário de back-end no mecanismo de presença é movida do nó com falha para o nó funcional.  O usuário não precisa sair do Jabber e fazer logon novamente quando a alteração acontece com o Server Recovery Manager (SRM).

Temporizador de Reinício de Sessão do Cliente Jabber

Para que a sessão do usuário se torne totalmente ativa no nó IM&P secundário após um evento de failover, o usuário deve tentar fazer login nesse servidor via SOAP (Client Profile Agent).  Isso acontece automaticamente com a senha única que é passada do banco de dados IMDB. Como os logins são extremamente caros para recursos no servidor IM e Presence, deve haver uma maneira de limitar os logins quando um evento de failover ocorre.  Essa limitação ou buffer permite que todos os usuários façam login no nó secundário sem interrupção do serviço para os usuários no nó secundário.  Os mecanismos usados para limitar os logins do usuário são os Limites Inferiores de Re-Login do Cliente e os parâmetros de serviço Limite Superior de Login do Cliente do SRM (Server Recovery Manager).  

Limite inferior de relogin do cliente - o parâmetro que define a quantidade mínima de tempo (em segundos) que o cliente Jabber espera antes que o cliente tente fazer login no servidor secundário no caso de um evento de HA.

Limite superior de relogin do cliente - o parâmetro que define a quantidade máxima de tempo (em segundos) que o cliente Jabber espera antes que o cliente tente fazer login no servidor secundário no caso de um evento de HA.

O cliente Jabber recebe esses parâmetros no login no servidor e armazena em cache os valores para uso futuro.  Quando recebemos um evento HA do servidor IM&P, o cliente escolhe um número aleatório de segundos entre os limites superior e inferior e espera esse tempo antes que o cliente Jabber tente fazer login no secundário.  Quando o temporizador expirar, o cliente tentará fazer login SOAP no nó secundário.

Tipos de retorno de mensagem instantânea e presença

Se houver failover de usuário, deve haver recuo de usuário quando o serviço for restaurado no servidor problemático.  Há dois tipos de fallback de servidor:

Reversão manual

O fallback manual (configuração padrão para o Server Recovery Manager) ocorre quando o serviço foi restaurado e o grupo de redundância permite o botão Fallback. Quando esse botão é selecionado, as sessões de usuário que foram movidas para o nó secundário são movidas de volta para o nó inicial. O cliente Jabber aplica o novo registro nos limites superior e inferior para o fallback.

Retorno de Chamada Automático

O fallback automático ocorre quando o servidor monitora os serviços e o serviço do Server Recovery Manager (SRM) automaticamente recua os usuários para seus nós domésticos. A chave nesta configuração é que o serviço do Server Recovery Manager (SRM) aguarda 30 minutos para que um serviço/servidor com falha permaneça ativo antes que um fallback automático seja iniciado.  Depois que esse tempo de atividade de 30 minutos é estabelecido, as sessões do usuário são movidas de volta para seus nós domésticos. O cliente Jabber aplica o novo registro nos limites superior e inferior para o fallback. 

O fallback automático não é a configuração padrão, mas pode ser ativado.  Para ativar o fallback automático, altere o parâmetro Ativar Fallback Automático nos Parâmetros de Serviço do Server Recovery Manager para o valor True.

Troubleshoot

Esta seção fornece as informações que você pode usar para solucionar problemas de sua configuração.

Ao solucionar problemas de alta disponibilidade no Servidor de Serviços IM&P, há dois temporizadores importantes que você precisa considerar.

• Os Servidores trocam 4 keepalives a cada 60 segundos, se não houver resposta após os 60 segundos, o Cisco Service Recovery Manager (SRM) considera que o nó não responsivo ficou offline e dispara um comando Fail Over. Como mostra o próximo trecho, o último heartbeat ocorreu há 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]

Tip: Nesse cenário, se você tiver encontrado alguma latência na rede, é recomendável aumentar o temporizador de tempo limite de pulsação de 60 para 90 segundos.
Navegue até página da Web do CUCM Administration > System > Service parameters configuration > Select the IM&P Server > Select Cisco Recovery Manager Settings > No tempo limite Keep Alive (Heartbeat) aumente o número para 90 segundos.

• O servidor do Assinante IM&P aguarda 90 segundos, se detectar que um ou mais dos serviços monitorados estão inoperantes, o servidor do Assinante assume o controle.

Registros a serem coletados para solução de problemas

• O Server Recover Manager (SRM) registra a partir de antes e depois do evento de failover (nível de depuração, se possível)
• A saída do comando através da interface de linha de comando IM&P executar sql select * de enterprisesubcluster
  • A tabela de subcluster empresarial no IM&P abriga a configuração do grupo de redundância
• A saída do comando através da interface de linha de comando IM&P executar sql select * de enterprise enode
  • A tabela de código empresarial exibe as informações do nó e a atribuição do subcluster do nó
• Se o failover for produzido por um serviço que está sendo interrompido, reúna:
  • Logs de sistema do visualizador de eventos
  • Logs de aplicativo do visualizador de eventos
  • Registros do serviço interrompido.