Partager via

Topologies et composant utilisés pour les serveurs frontaux, la messagerie instantanée et la présence dans Lync Server 2013

  • Article

 

Rubrique Dernière modification : 2014-10-24

Les seuls composants requis pour la messagerie instantanée et la présence sont :

  • Serveurs frontaux ou serveurs Standard Edition de votre organisation. Les fonctionnalités de messagerie instantanée et de présence sont toujours activées sur ces serveurs.

  • Un programme d’équilibrage de la charge, si vous avez un pool frontal Enterprise Edition. Pour plus d’informations, consultez les exigences d’équilibrage de charge pour Lync Server 2013.

Planification du déploiement de pools frontaux

Dans Lync Server 2013, l’architecture du pool frontal a changé et ces modifications affectent la façon dont vous devez planifier et gérer vos pools frontaux.

Nous vous recommandons d’inclure au moins trois serveurs frontaux dans tous vos pools frontaux Êdition Entreprise. Dans Lync Server, l’architecture des pools frontaux utilise un modèle de systèmes distribués, avec les données de chaque utilisateur conservées sur trois serveurs frontaux dans le pool. Pour plus d’informations sur cette nouvelle architecture, consultez les modifications apportées à la topologie dans Lync Server 2013.

Si vous ne souhaitez pas déployer trois serveurs frontaux Êdition Entreprise et souhaitez une récupération d’urgence, nous vous recommandons d’utiliser Lync Server Standard Edition et de créer deux pools avec une relation de sauvegarde jumelée. Cela fournit une solution de récupération d’urgence avec seulement deux serveurs. Pour plus d’informations sur les topologies et fonctionnalités de haute disponibilité et de récupération d’urgence, consultez Planification de la haute disponibilité et de la récupération d’urgence dans Lync Server 2013.

Planification de la gestion des pools frontaux

Pour les pools frontaux, suivez les instructions de cette section.

S’assurer que les pools sont fonctionnels

Avec le nouveau modèle distribué pour les pools frontaux, certains nombres de serveurs d’un pool doivent être en cours d’exécution pour que le pool fonctionne. Il existe deux modes de perte pour un pool

  • Perte de quorum au niveau du groupe de routage, provoquée par lʼinsuffisance des serveurs réplica pour un groupe de routage particulier. Un groupe de routage est une agrégation d’un ensemble d’utilisateurs hébergés dans le pool. Chaque groupe de routage a trois réplicas dans le pool : un principal et deux secondaires.

  • Perte de quorum au niveau du pool, provoquée par une insuffisance du nombre de serveurs d’amorçage en cours d’exécution dans le pool.

Perte de quorum au niveau du groupe de routage

Lors du premier démarrage d’un nouveau nouveau pool frontal, il est primordial que 85 % des serveurs soient opérationnels, comme indiqué dans le tableau ci-après. Si un pourcentage inférieur de serveurs est en cours d’exécution, les services risquent de rester bloqués dans leur état de démarrage et le pool risque de ne pas démarrer.

Nombre total de serveurs dans le pool Nombre de serveurs devant être en cours d’exécution pour que le pool démarre la première fois

2

1

3

3

4

3

5

4

6

5

7

5

8

6

9

7

10

8

11

9

12

10

Chaque fois que le pool est démarré ultérieurement, 85 % des serveurs doivent être démarrés (comme indiqué dans le tableau précédent). S’il n’est pas possible de démarrer ce nombre de serveurs (mais que suffisamment de serveurs peuvent être démarrés pour éviter une perte de quorum au niveau du pool), vous pouvez utiliser l’applet de commande Reset-CsPoolRegistrarState –ResetType QuorumLossRecovery pour permettre au pool de récupérer de cette perte de quorum au niveau du groupe de routage et d’avancer. Pour plus d’informations sur l’utilisation de cette applet de commande, consultez Reset-CsPoolRegistrarState.

Remarque

Étant donné que Lync Server utilise la base de données SQL principale en tant que témoin, si vous arrêtez la base de données primaire et basculez vers la copie miroir et arrêtez suffisamment de serveurs frontaux afin qu’ils ne soient pas suffisamment exécutés conformément au tableau précédent, l’ensemble du pool tombe en panne. Pour plus d’informations, consultez témoin de mise en miroir de bases de données.

Perte de quorum au niveau du pool

Pour qu’un pool frontal fonctionne, il ne peut pas y avoir de perte de quorum au niveau du pool. Si le nombre de serveurs en cours d’exécution est inférieur au niveau fonctionnel, comme indiqué dans le tableau suivant, les serveurs restants dans le pool arrêtent tous les services Lync Server. Notez que les nombres du tableau suivant supposent que les serveurs principaux du pool sont en cours d’exécution.

Nombre total de serveurs frontaux dans le pool Nombre de serveurs devant être exécutés pour que le pool soit opérationnel

2

1

3-4

2 (n’importe lesquels)

5-6

3 (n’importe lesquels)

7

4 (n’importe lesquels)

8-9

4 (n’importe lesquels parmi les 7 premiers serveurs)

10-12

5 (n’importe lesquels parmi les 9 premiers serveurs)

Dans le tableau précédent, les « premiers serveurs » sont les serveurs qui ont été élevés en premier, chronologiquement, lorsque le pool a été démarré pour la première fois. Pour déterminer ces serveurs, vous pouvez utiliser l’applet de commande Get-CsComputer avec l’option –PoolFqdn . Cette applet de commande affiche les serveurs dans l’ordre dans lequel ils apparaissent dans la topologie, et ceux situés en haut de la liste sont les premiers serveurs.

Pools frontaux avec deux serveurs frontaux

Nous vous déconseillons de déployer un pool frontal qui ne contient que deux serveurs frontaux. Si vous avez besoin de déployer un tel pool, suivez les instructions suivantes :

  • Si l’un des deux serveurs frontaux tombe en panne, vous devez essayer de sauvegarder le serveur défaillant dès que possible. De même, si vous devez mettre à niveau l’un de ces serveurs, remettez-le en ligne dès la fin de la mise à niveau.

  • Si, pour une raison ou une autre, vous devez arrêter les deux serveurs en même temps procédez comme suit lorsque l’interruption de service du pool est terminé :

    • La meilleure pratique consiste à redémarrer les deux serveurs frontaux en même temps.

    • Si les deux serveurs ne peuvent pas être redémarrés en même temps, vous devez les rétablir dans l’ordre inverse de leurs arrêts.

    • Si vous ne pouvez pas les remettre dans cet ordre, utilisez l’applet de commande suivante avant de sauvegarder le pool :

      Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery -PoolFQDN <FQDN>

Étapes supplémentaires pour vérifier que les pools sont fonctionnels

Vous devez prêter attention à deux autres facteurs pour vous assurer que vos pools frontaux restent opérationnels.

  • Lorsque vous déplacez des utilisateurs vers le pool pour la première fois, assurez-vous qu’au moins trois des serveurs frontaux sont en cours d’exécution.

  • Si vous établissez une relation d’appairage entre ce pool et un autre pool à des fins de récupération d’urgence, après avoir établi cette relation, vous devez être sûr que trois serveurs frontaux s’exécutent simultanément à un moment donné pour synchroniser correctement les données avec le pool de sauvegarde. Pour plus d’informations sur les fonctionnalités de jumelage de pool et de récupération d’urgence, consultez Planification de la haute disponibilité et de la récupération d’urgence dans Lync Server 2013.

Amélioration de la fiabilité des mises à niveau de pool

Lorsque vous devez mettre à niveau ou corriger les serveurs dans un pool frontal, suivez le flux de travail indiqué dans Mettre à niveau ou mettre à jour des serveurs frontaux dans Lync Server 2013, ainsi que les instructions suivantes :

  • Lorsque vous passez d’un domaine de mise à niveau à un autre pour les mises à niveau (en suivant le flux de travail lors de la mise à niveau ou de la mise à jour des serveurs frontaux dans Lync Server 2013), vous utilisez l’applet de commande Get-CsPoolUpgradeReadinessState et vérifiez l’état prêt. L’ajout d’une attente de 20 minutes entre chaque domaine de mise à niveau une fois « Prêt » rendra les mises à niveau plus fiables. S’il n’est pas prêt pendant ces 20 minutes, redémarrez le minuteur de 20 minutes. En outre, vous pouvez exécuter l’applet de commande Get-CsPoolFabricState avant et après le démarrage de l’intervalle de 20 minutes et vous assurer qu’il n’y a aucune modification des bases de données primaires et secondaires des groupes de routage.

  • Ne passez pas au domaine de mise à niveau suivant si l’un des serveurs du dernier domaine de mise à niveau corrigé est bloqué ou n’est pas redémarré. Cela s’applique également si l’un des serveurs d’une mise à niveau ne peut pas démarrer. Exécutez Get-CsPoolFabricState pour vous assurer que tous les groupes de routage ont un principal et au moins un secondaire ; cela confirmera si tous les utilisateurs disposent d’un service.

  • Si certains utilisateurs ont un service et d’autres non, exécutez Get-CsPoolFabricState avec l’option –Verbose pour rechercher les groupes de routage qui ont des réplicas manquants. Ne redémarrez pas l’intégralité du pool en tant que première étape de résolution des problèmes. Pour plus d’informations sur cette applet de commande, consultez Get-CsPoolFabricState.

  • Assurez-vous que toutes les instances des fenêtres observateur d'événements ou Analyseur de performances sont fermées pour les installations/désinstallations windows Fabric.

Modification de la configuration d’un pool frontal

Chaque fois que vous ajoutez des serveurs frontaux à un pool ou que vous les supprimez du pool, puis que vous publiez la nouvelle topologie, suivez les instructions suivantes :

  • Une fois la nouvelle topologie publiée, vous devez redémarrer chaque serveur frontal dans le pool. Redémarrez-les un par autre.

  • Si l’ensemble du pool a été arrêté pendant la modification de la configuration, exécutez l’applet de commande suivante après la publication de la nouvelle topologie :

    Reset-CsPoolRegistrarState -PoolFQDN <PoolFQDN> -ResetType ServiceReset

Si un serveur frontal échoue et qu’il est peu probable qu’il soit remplacé pendant quelques jours ou plus, supprimez le serveur de la topologie. Ajoutez le nouveau serveur frontal à la topologie lorsqu’il est à nouveau disponible.