Haute disponibilité du serveur principal dans Skype Entreprise Server
Découvrez les options de haute disponibilité du serveur principal prises en charge dans Skype Entreprise Server, notamment les groupes de disponibilité AlwaysOn, les instances de cluster de basculement AlwaysOn, la mise en miroir de bases de données et les clustering de basculement SQL.
Pour améliorer la haute disponibilité de vos serveurs principaux, vous disposez de quatre options :
Mise en miroir de bases de données
Groupes de disponibilité AlwaysOn
Instances de cluster de basculement AlwaysOn (FCI)
Clustering SQL avec basculement
L’utilisation d’une de ces solutions est facultative mais est recommandée pour préserver la continuité des activités de votre organisation. Sinon, l’arrêt d’un serveur de base de données unique peut entraîner une perte importante de données Skype Entreprise Server.
Vous pouvez configurer la mise en miroir de bases de données à l’aide du Générateur de topologie uniquement. Pour les groupes de disponibilité AlwaysOn, les instances de cluster de basculement AlwaysOn ou les clustering de basculement SQL, vous utilisez SQL Server pour créer la solution à haute disponibilité, puis vous pouvez utiliser le Générateur de topologie pour l’associer à un pool frontal.
Si vous utilisez la haute disponibilité du serveur principal sur un pool frontal 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.
Mise en miroir de bases de données
Skype Entreprise Server prend en charge la mise en miroir avec les logiciels de base de données suivants :
SQL Server 2019, Êdition Entreprise et Standard Edition
SQL Server 2017, Êdition Entreprise et Standard Edition
SQL Server 2016, Êdition Entreprise et Standard Edition
SQL Server 2014, Êdition Entreprise et Standard Edition
SQL Server 2012 SP2 et CU2, Êdition Entreprise et Standard Edition
Remarque
La mise en miroir SQL est disponible dans Skype Entreprise Server 2015, mais n’est plus prise en charge dans Skype Entreprise Server 2019. Les méthodes groupes de disponibilité AlwaysOn, instances de cluster de basculement AlwaysOn (FCI) et basculement SQL clustering sont les seules options prises en charge avec Skype Entreprise Server 2019.
La mise en miroir asynchrone de bases de données n’est pas prise en charge pour la haute disponibilité du serveur principal dans Skype Entreprise Server. Dans le reste du document, sauf mention explicite, la mise en miroir sous-entend une mise en miroir synchrone.
Lorsque vous déployez la mise en miroir de bases de données dans un pool frontal, toutes les bases de données Skype Entreprise Server du pool sont mises en miroir, y compris le magasin central de gestion, s’il se trouve dans ce pool, ainsi que la base de données d’applications Response Group et la base de données d’application de parcage d’appels, si ces applications s’exécutent dans le pool.
La mise en miroir de base de données vous permet de ne pas avoir à utiliser de stockage partagé pour les serveurs. Chaque serveur garde sa copie des bases de données en local.
Vous pouvez déployer la mise en miroir de base de données 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.
Directives pour la planification de la mise en miroir du serveur frontal
En général, la configuration de la mise en miroir SQL entre deux serveurs principaux avec un témoin exige ce qui suit :
La version du serveur principal de SQL Server doit prendre en charge la mise en miroir SQL.
Le principal, le miroir et le témoin (s’il est déployé) doivent disposer de la même version de SQL Server.
Le principal et le miroir doivent disposer de la même édition de SQL Server. Le témoin peut en avoir une différente.
Pour connaître les meilleures pratiques sql concernant les versions sql prises en charge pour un rôle Témoin, consultez « Témoin de mise en miroir de bases de données » dans MSDN Library.
Avant de configurer la mise en miroir des serveurs, vous devez d’abord configurer les autorisations de base de données SQL correctement. Pour plus d’informations, consultez « Configurer des comptes de connexion pour la mise en miroir de bases de données ou les groupes de disponibilité AlwaysOn (SQL Server) ».
Avec la mise en miroir SQL, le mode de récupération de la base de données a toujours la valeur Complète, ce qui signifie que vous devez surveiller de près la taille du journal des transactions et sauvegarder les journaux des transactions de manière régulière afin d’éviter toute insuffisance d’espace disque sur les serveurs principaux. La fréquence des sauvegardes des journaux des transactions dépend de la vitesse à laquelle leur taille augmente, laquelle dépend à son tour des transactions de base de données induites par les activités des utilisateurs sur le pool frontal. Nous vous recommandons d’estimer l’accroissement des journaux des transactions pour la charge de travail de votre déploiement Lync afin de procéder à une planification en conséquence. Les articles suivants fournissent des informations supplémentaires sur la gestion des journaux et sauvegardes SQL :
Important
L’utilisation du Générateur de topologie ou des applets de commande pour configurer et supprimer la mise en miroir SQL est prise en charge uniquement lorsque les serveurs principal, miroir et témoin (si vous le souhaitez) appartiennent tous au même domaine. Si vous voulez configurer la mise en miroir SQL entre des serveurs de différents domaines, reportez-vous à votre documentation SQL Server.
Remarque
La mise en miroir SQL est disponible dans Skype Entreprise Server 2015, mais n’est plus prise en charge dans Skype Entreprise Server 2019. Les méthodes groupes de disponibilité AlwaysOn, instances de cluster de basculement AlwaysOn (FCI) et basculement SQL clustering sont recommandées avec Skype Entreprise Server 2019.
Temps de récupération pour le basculement automatique de serveur principal avec la mise en miroir de base de données
Pour le basculement automatique de serveur principal avec la mise en miroir de base de données, la cible d’ingénierie pour la durée maximale d’interruption admissible (RTO, Recovery Time Objective) est de 5 minutes. Par l’usage de la mise en miroir de base de données synchrone, nous ne prévoyons pas de perte de données en cas de panne du serveur principal sauf dans de rares cas où les serveurs frontaux et le serveur principal s’arrêtent de fonctionner en même temps pendant un transfert de 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 en cas de panne du serveur principal avec la mise en miroir de base de données
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 de base de données et avez configuré un témoin et qu’une panne se produit au niveau du serveur principal, le basculement du serveur principal se fait 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 principal n’est toujours pas restauré ou si 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 des tâches nécessitant 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.
Groupes de disponibilité AlwaysOn et instances de cluster de basculement AlwaysOn
Skype Entreprise Server prend en charge les groupes de disponibilité AlwaysOn uniquement en tant qu’actifs/passifs, et non actifs/actifs.
Pour utiliser des groupes de disponibilité AlwaysOn ou des instances de cluster de basculement AlwaysOn, vous devez d’abord utiliser SQL Server pour configurer la solution de haute disponibilité. Vous pouvez ensuite utiliser le Générateur de topologie pour l’associer à un pool frontal.
Skype Entreprise Server prend en charge AlwaysOn avec les logiciels de base de données suivants :
SQL Server Êdition Entreprise 2019
SQL Server 2019 Standard Edition avec des limitations, voir la remarque ci-dessous
SQL Server Êdition Entreprise 2017
SQL Server 2017 Standard Edition avec des limitations, voir la remarque ci-dessous
SQL Server Êdition Entreprise 2016
SQL Server 2016 Standard Edition avec des limitations, voir la remarque ci-dessous
Êdition Entreprise SQL Server 2014
SQL Server 2012 SP2 et CU2 Êdition Entreprise
Remarque
SQL Server 2019, 2017 et 2016 sont les seules versions prises en charge par Skype Entreprise Server 2019.
Remarque
Always On groupes de disponibilité n’est pas pris en charge dans SQL 2016, 2017 et 2019 Standard Edition, mais vous pouvez utiliser Always On instances de cluster de basculement. Pour en savoir plus, consultez Éditions et fonctionnalités prises en charge de SQL Server 2016.
Important
Les noms d’instance de plusieurs instances de groupe de disponibilité AlwaysOn doivent être identiques.
Pour connaître les étapes de déploiement de groupes de disponibilité AlwaysOn, consultez Déployer un groupe de disponibilité AlwaysOn sur un serveur principal dans Skype Entreprise Server.
Clustering de basculement de SQL Server
Skype Entreprise Server prend en charge les clustering de basculement SQL Server avec les logiciels de base de données suivants :
SQL Server 2019, Êdition Entreprise et Standard Edition
SQL Server 2017, Êdition Entreprise et Standard Edition
SQL Server 2016, Êdition Entreprise et Standard Edition
SQL Server 2014, Êdition Entreprise et Standard Edition
SQL Server 2012 SP2 et CU2, Êdition Entreprise et Standard Edition
Pour utiliser le basculement SQL clustering, vous devez d’abord configurer le cluster SQL Server avant de déployer votre pool frontal. Pour obtenir des meilleures pratiques et des instructions de configuration pour les clustering de basculement dans SQL Server 2012, consultez https://technet.microsoft.com/library/hh231721.aspx.
Remarque
SQL Server 2019, 2017 et SQL Server 2016 sont les seules versions prises en charge par Skype Entreprise Server 2019.
Pour utiliser le basculement SQL clustering, vous devez d’abord configurer le cluster SQL Server avant de déployer votre pool frontal. Pour obtenir des meilleures pratiques et des instructions de configuration pour les clustering de basculement dans SQL Server 2014 et 2016, consultez https://technet.microsoft.com/library/hh231721.aspx. Pour les clustering de basculement dans SQL Server 2008, consultez https://technet.microsoft.com/library/ms189134(v=sql.105).aspx.
Lorsque vous installez SQL Server, vous devez installer SQL Server Management Studio pour gérer les emplacements des bases de données et des fichiers journaux. SQL Server Management Studio est installé en tant que composant facultatif lorsque vous installez SQL Server.