Configuration de la haute disponibilité du serveur de messagerie instantanée et de présence

Introduction

Ce document décrit comment la haute disponibilité des messages instantanés et de la présence (IM&P) (également appelée redondance) fonctionne dans un environnement de messagerie instantanée et de présence d'entreprise et comment la dépanner.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• IM&P Cisco Unified
• Clients Cisco Jabber

Composants utilisés

• Cisco Unified IM&P 10.0 et versions ultérieures.
• Clients Cisco Jabber 9.6 et versions ultérieures.

Les informations de ce document ont été créées à partir des composants d'un environnement de travaux pratiques spécifique. Tous les composants utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Haute disponibilité de la messagerie instantanée et de la présence (HA)

Le serveur de services de messagerie instantanée et de présence offre une haute disponibilité ou une redondance sous la forme de groupes de serveurs logiques dans la configuration CUCM. Cette configuration est transmise à la messagerie instantanée et à la présence, puis utilisée pour permettre la redondance en cas de défaillance du service de messagerie instantanée et de présence ou du serveur.  Lorsqu'un événement HA se produit, les sessions de l'utilisateur final sont déplacées du serveur défaillant vers la sauvegarde.  Lorsque le serveur a été restauré à un état normal, les sessions utilisateur sont ensuite déplacées automatiquement ou manuellement par l'administrateur.  

Configuration du groupe de redondance

Le groupe de redondance est la paire de serveurs logiques qui permet l'affectation d'un serveur au sous-cluster de la messagerie instantanée et de la présence, ainsi que la configuration de la haute disponibilité.  Afin d'accéder à cette partie de la configuration se trouve sur la page Web du serveur CUCM.

Système > Groupes de redondance de présence

Lorsque l'administrateur ajoute le serveur de publication IM&P à la configuration System > Server sur CUCM et que le serveur IM&P est enregistré, le groupe de redondance DefaultCUPSubCluster est créé avec le serveur de publication qui lui est affecté.  

Une fois créé, le groupe de redondance ressemble à ceci :

Ce groupe de redondance se traduit par le sous-cluster IM and Presence. Dans l'état actuel de la configuration du groupe de redondance dans CUCM, voici à quoi ressemblerait la page Web de la topologie du cluster de messagerie instantanée et de présence :

Nous voyons que le serveur de publication IM&P est affecté au sous-cluster DefaultCUPSet que le serveur d'abonnés ne l'est pas.  En effet, le serveur d'abonnés IM&P n'est pas affecté au groupe de redondance dans la configuration CUCM.

Attribuez l'abonné au groupe de redondance :

Afin d'affecter le serveur d'abonnés au groupe de redondance, sélectionnez simplement le serveur d'abonnés dans la liste déroulante, puis enregistrez la modification de configuration.

Une fois l'abonné IM&P ajouté au groupe de redondance :

Après l'ajout du noeud secondaire (l'abonné), l'option Haute disponibilité peut être sélectionnée. Pour activer la haute disponibilité, il suffit de cocher la case Activer la haute disponibilité et d'enregistrer la modification de configuration.

Une fois la haute disponibilité activée :

La page actualise ensuite automatiquement l'état et la raison du serveur.  Lorsque le serveur est en état d'initialisation, cela signifie que les deux serveurs peuvent communiquer.  Les serveurs vérifient ensuite l'état du service avant que l'état ne passe à l'état Normal.  Si les deux serveurs peuvent se connecter et que tous les services surveillés sont activés sur les deux, nous obtiendrions alors un état Normal-Normal. Cela signifie que tous les services surveillés sont actifs sur les serveurs IM&P.

État normal du groupe de redondance :

État de haute disponibilité normal-normal dans la page Topologie IM&P :

Services de présence et de messagerie instantanée surveillés

Étant donné que vous pouvez avoir différents modèles de déploiement : IM Only, IM with SIP/XMPP Federation, IM with Compliance, IM with persistent chat, Remote Call Control Only, etc., la liste réelle de ces processus à surveiller est dynamique. Par défaut, ces éléments sont toujours surveillés lorsque la HA est activée :

Base de données IDS

Moteur de présence (si activé)

Routeur XCP

Le Gestionnaire de récupération du serveur vérifie si la conformité (Archiveur de messages), la conversation persistante (Gestionnaire de conférences de texte), la fédération SIP (SIP Federation Connection Manager), la fédération XMPP (XMPP Federation Connection Manager) sont configurées (et activées).  

S'ils sont configurés et activés, le Gestionnaire de récupération de serveur (SRM) surveille également ces services.

Attention : Avant de redémarrer un ou plusieurs des services surveillés, vous devez désactiver la haute disponibilité à partir des groupes de redondance de présence sur le serveur CUCM. Il en va de même lorsqu'un redémarrage d'un ou de plusieurs noeuds IM&P est effectué.

Processus de basculement utilisateur

Lorsqu'un basculement a lieu (automatique ou manuel), le point principal à retenir est que le compte d'utilisateur n'est pas déplacé d'un serveur à l'autre, mais que seule la session utilisateur dans Presence Engine est déplacée.  Dans les versions antérieures à 10 de la messagerie instantanée et de la présence, l'affectation de l'utilisateur a été déplacée d'un serveur à l'autre.  Ce déplacement de l'utilisateur a été très coûteux pour les ressources du serveur et ajouté à la charge qui était sur le serveur.  Dans 10.X et les versions ultérieures, l'utilisateur reste hébergé sur le serveur auquel il est affecté et la session de l'utilisateur principal dans le moteur de présence est déplacée du noeud défaillant vers le noeud fonctionnel.  L'utilisateur ne doit pas quitter Jabber et se reconnecter lorsque la modification se produit avec Server Recovery Manager (SRM).

Minuteur de réouverture de session du client Jabber

Pour que la session utilisateur devienne pleinement active sur le noeud IM&P secondaire après un événement de basculement, l'utilisateur doit tenter de se connecter à ce serveur via SOAP (Client Profile Agent).  Cela se produit automatiquement avec le mot de passe unique transmis à partir de la base de données IMDB. Étant donné que les connexions sont extrêmement coûteuses pour les ressources du serveur de messagerie instantanée et de présence, il doit y avoir un moyen de limiter les connexions lorsqu'un événement de basculement se produit.  Cette limitation ou cette mémoire tampon permet à tous les utilisateurs de se connecter au noeud secondaire sans interruption de service pour les utilisateurs du noeud secondaire.  Les mécanismes utilisés pour limiter les connexions utilisateur sont les paramètres de service Client Re-Login Lower Limit et Client Re-Login Upper Limit Server Recovery Manager (SRM).  

Client Re-Login Lower Limit : paramètre qui définit la durée minimale (en secondes) que le client Jabber attend avant que le client tente de se connecter au serveur secondaire en cas d'événement HA.

Client Re-Login Upper Limit : paramètre qui définit la durée maximale (en secondes) que le client Jabber attend avant que le client tente de se connecter au serveur secondaire en cas d'événement HA.

Le client Jabber reçoit ces paramètres lors de la connexion au serveur et met en cache les valeurs pour une utilisation future.  Lorsque nous recevons un événement HA du serveur IM&P, le client choisit un nombre aléatoire de secondes entre les limites supérieure et inférieure et attend ce délai avant que le client Jabber tente de se connecter au secondaire.  Une fois le compteur expiré, le client tente ensuite de se connecter au noeud secondaire via SOAP.

Types de secours de messagerie instantanée et de présence

En cas de basculement d'utilisateur, il doit y avoir une reprise d'utilisateur lorsque le service est restauré sur le serveur problématique.  Il existe deux types de secours de serveur :

Reprise manuelle

La reprise manuelle (configuration par défaut pour Server Recovery Manager) a lieu lorsque le service a été restauré et que le groupe de redondance autorise le bouton de secours. Lorsque ce bouton est sélectionné, les sessions utilisateur qui ont été déplacées vers le noeud secondaire sont déplacées vers leur noeud hébergé. Le client Jabber applique ensuite les limites supérieure et inférieure de la reconnexion.

Reprise automatique

La reprise automatique a lieu lorsque le serveur surveille les services et que le service Server Recovery Manager (SRM) rebranche automatiquement les utilisateurs vers leurs noeuds hébergés. La clé de cette configuration est que le service Server Recovery Manager (SRM) attend 30 minutes pour qu'un service/serveur défaillant reste actif avant le lancement d'une reprise automatique.  Une fois cette disponibilité de 30 minutes établie, les sessions utilisateur sont déplacées vers leurs noeuds hébergés. Le client Jabber applique ensuite les limites supérieure et inférieure de la reconnexion. 

La reprise automatique n'est pas la configuration par défaut, mais elle peut être activée.  Pour activer la reprise automatique, modifiez le paramètre Enable Automatic Fallback dans les paramètres de service du Gestionnaire de récupération du serveur pour lui attribuer la valeur True.

Dépannage

Cette section fournit les informations que vous pouvez utiliser pour dépanner votre configuration.

Lors du dépannage de la haute disponibilité sur le serveur de services IM&P, vous devez tenir compte de deux temporisateurs importants.

• Les serveurs échangent 4 keepalives toutes les 60 secondes, s'il n'y a pas de réponse après les 60 secondes, Cisco Service Recovery Manager (SRM) considère que le noeud qui ne répond pas est hors ligne et déclenche une commande Fail Over. Comme le montre l'extrait suivant, la dernière pulsation s'est produite il y a 62 secondes.

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]

Astuce : Dans ce scénario, si vous avez détecté une certaine latence dans votre réseau, il est recommandé d'augmenter le délai d'attente de pulsation de 60 à 90 secondes.
Accédez à la page Web Administration de CUCM > Système > Configuration des paramètres de service > Sélectionnez le serveur IM&P > Sélectionnez Paramètres de Cisco Recovery Manager > Sur le délai d'attente Keep Alive (Heartbeat) augmentez le nombre à 90 secondes.

• Le serveur d'abonnés IM&P attend 90 secondes, s'il détecte qu'un ou plusieurs des services surveillés sont en panne, le serveur d'abonnés prend le relais.

Journaux à collecter pour le dépannage

• Journaux du Gestionnaire de récupération de serveur (SRM) avant et après l'événement de basculement (niveau de débogage si possible)
• La sortie de la commande via l'interface de ligne de commande IM&P exécute sql select * dans Enterprise-subbcluster
  • La table de sous-cluster d'entreprise dans IM&P héberge la configuration du groupe de redondance
• Résultat de la commande via l'interface de ligne de commande IM&P exécuter sql select * à partir du code d'entreprise
  • La table ententenode affiche les informations de noeud et l'affectation de sous-cluster du noeud
• Si le basculement est produit par un service arrêté, rassemblez :
  • Journaux système de l'observateur d'événements
  • Journaux d'application de l'observateur d'événements
  • Journaux du service qui sont arrêtés.