Haute disponibilité du serveur principal dans Lync Server 2013
Rubrique Dernière modification : 2013-08-12
Pour garantir une haute disponibilité pour vos serveurs principaux, vous pouvez utiliser la mise en miroir SQL synchrone ou le clustering SQL. L’utilisation de l’une de ces solutions est facultative, mais il est recommandé de maintenir la continuité d’activité de votre organisation. La mise en miroir SQL asynchrone n’est pas prise en charge pour la haute disponibilité du serveur principal dans Lync Server 2013. Dans le reste de ce document, la mise en miroir SQL signifie la mise en miroir SQL synchrone, sauf indication contraire explicite.
Vous pouvez facilement configurer la mise en miroir SQL avec le Générateur de topologie. Pour le clustering SQL avec basculement, vous devez utiliser SQL Server pour la configuration.
Si vous utilisez la mise en miroir SQL ou le clustering SQL dans un pool associé à un autre pool frontal pour la récupération d’urgence, vous devez utiliser la même solution de haute disponibilité back-end dans les deux pools. Vous ne devez pas associer un pool à l’aide de la mise en miroir SQL à un pool à l’aide du clustering SQL.
Lorsque vous déployez la mise en miroir SQL, toutes les bases de données Lync Server du pool sont mises en miroir, y compris le magasin de gestion centrale, s’il se trouve dans ce pool, ainsi que la base de données d’application Response Group et la base de données d’application Call Park, si ces applications s’exécutent dans le pool.
Avec la mise en miroir SQL, vous n’avez pas besoin d’utiliser le stockage partagé pour les serveurs. Chaque serveur garde sa copie des bases de données en local.
Vous pouvez choisir de déployer la mise en miroir SQL avec ou sans témoin. Cela dit, nous vous recommandons d’en utiliser un, car il permet le basculement automatique du serveur principal. Dans le cas contraire, un administrateur doit appeler le basculement manuellement. Notez que même si un témoin est déployé, un administrateur peut au besoin appeler manuellement le basculement du serveur principal.
Si vous utilisez un témoin, celui-ci peut servir pour plusieurs paires de serveurs principaux. Il n’y a aucune correspondance stricte un-à-un entre les témoins et les paires de serveurs principaux. Les déploiements utilisant un seul témoin pour plusieurs paires de serveurs principaux ne sont simplement pas aussi résilients que les topologies faisant appel à un témoin à part pour chaque paire de serveurs principaux.
Pour plus d’informations sur la prise en charge du clustering SQL, consultez la prise en charge des logiciels de base de données dans Lync Server 2013. Pour plus d’informations sur le déploiement du clustering SQL, consultez Configurer le clustering SQL Server pour Lync Server 2013.
Temps de récupération pour le basculement automatique du serveur principal avec la mise en miroir SQL
Pour le basculement principal automatique avec la mise en miroir SQL, la cible d’ingénierie pour l’objectif de temps de récupération (RTO) est de 5 minutes. En raison de la mise en miroir SQL synchrone, nous n’anticipons pas la perte de données pendant les défaillances du serveur principal, sauf dans de rares cas où les serveurs frontaux et le serveur principal tombent en panne simultanément pendant le déplacement des données entre les serveurs. La cible d’ingénierie pour la perte de données maximale admissible (RPO, Recovery Point Objective) est de 5 minutes.
Expérience utilisateur lors d’une défaillance du serveur principal avec la mise en miroir SQL
L’expérience utilisateur en cas de panne dépend de la nature de la panne et de votre topologie.
Si vous utilisez la mise en miroir SQL et que vous avez configuré un témoin et que le principal échoue, le basculement du serveur principal se produit automatiquement et rapidement. Les utilisateurs actifs ne devraient pas remarquer d’interruption particulière de leurs sessions actives.
Si aucun témoin n’est configuré, l’administrateur peut perdre du temps à appeler manuellement le basculement. Pendant ce temps, les utilisateurs actifs peuvent s’en trouver affectés. Leurs sessions se poursuivent normalement pendant environ 30 minutes. Si le serveur principal n’est toujours pas restauré ou qu’un administrateur n’a pas basculé vers la sauvegarde, les utilisateurs passent en mode résilience, ce qui signifie qu’ils ne peuvent pas effectuer les tâches qui nécessitent une modification persistante sur Lync Server (par exemple, l’ajout d’un contact).
Si le serveur principal et les serveurs principaux en miroir tombent en panne, ou si l’un de ces derniers serveurs et le témoin tombent en panne, le serveur principal n’est alors plus disponible (même s’il fonctionne toujours). Dans ce cas, le mode de résistance s’active pour les utilisateurs actifs après une certaine durée.