Topologie de référence pour plusieurs centres de données

 

Dernière rubrique modifiée : 2012-01-24

La topologie de référence de multiples centres de données est conçue pour toute taille d’entreprise dotée de plusieurs site centraux. La topologie exacte du diagramme suivant est prévue pour une organisation comportant 70 000 utilisateurs, dont 40 000 sur le site central A et 30 000 sur le site central B. Le type de topologie illustré dans ce diagramme peut convenir à toutes les organisations, quel que soit le nombre d’utilisateurs.

Cette topologie est présentée dans de nombreux diagrammes, avec tout d’abord une vue d’ensemble, suivie de vues détaillées des sites centraux.

Vue d’ensemble de la topologie de référence pour plusieurs centres de données

Topologie de référence pour plusieurs centres de données : vue détaillée du site central A

Topologie de référence pour plusieurs centres de données : vue détaillée du site central B

Topologie de référence pour plusieurs centres de données : vue détaillée du site central C

• Déploiement Active Directory.   Tous les déploiements Microsoft Lync Server 2010 logiciels de communication résident dans une seule forêt Active Directory. Pour cette topologie, le client a déployé Lync Server dans deux domaines enfants, retail.contoso.com et manufacturing.contoso.com.

• Augmentation du nombre d’utilisateurs pris en charge en ajoutant des serveurs frontaux supplémentaires :   l’organisation de ce diagramme dispose de cinq serveurs frontaux sur le site central A (pour 40 000 utilisateurs) et de quatre serveurs frontaux sur le site central B (pour 30 000 utilisateurs). Si un site doit répondre aux besoins d’un plus grand nombre d’utilisateurs, vous pouvez simplement ajouter des serveurs frontaux au pool de ce site. Le nombre maximal d’utilisateurs par pool est 80 000, avec huit serveurs frontaux.

  Néanmoins, chaque site peut prendre en charge davantage d’utilisateurs en ajoutant un autre pool frontal au site. Pour prendre en charge ces utilisateurs supplémentaires, vous ne devez ajouter qu’un seul pool frontal supplémentaire (des pools uniques sur chacun des sites de serveurs de conférence A/V, serveurs Edge et directeurs suffisent, même si des serveurs supplémentaires devront peut-être être ajoutés à ces pools).

• Utilisation d’un serveur Standard Edition au niveau d’un site de succursale :   Hormis son utilisation dans Lync Server, cette organisation considère le site C comme un site de succursale, car il ne dispose que de 600 employés. Toutefois, les utilisateurs y organisent beaucoup de conférences A/V entre eux. S’il était déployé dans Lync Server comme un site de succursale, le support de ces conférences s’exécuterait sur le réseau étendu en direction et en provenance d’un site central disposant d’un serveur de conférence A/V. Pour éviter cet éventuel problème de performance, ils ont installé sur ce site un serveur Standard Edition, qui hébergera ces conférences. Et dans la mesure où un serveur Standard Edition est installé sur ce site, par définition, Lync Server le considère comme un site central et il est traité comme tel dans le Générateur de topologies et l’outil de planification.

  Tant que les utilisateurs de ce site seront dotés d’un pool sur un autre site, défini comme leur pool de serveurs d’inscriptions de sauvegarde, ils disposeront d’un haut niveau de disponibilité pour Voix Enterprise ; le support vocal basculera automatiquement sur le site du serveur d’inscriptions de sauvegarde. Pour une solution haute disponibilité plus complète sur ce site, vous pouvez déployer un deuxième serveur Standard Edition.

  Bien que le site C soit considéré comme un site central, vous n’avez pas besoin d’y déployer des serveurs Edge. Dans cet exemple, le site C utilisera les serveurs Edge déployés sur le site A.

• Colocalisation du serveur de surveillance et du serveur d’archivage :   cette organisation déploie à la fois un serveur de surveillance et un serveur d’archivage. Pour les organisations qui déploient les deux serveurs, nous recommandons de les colocaliser pour protéger l’investissement correspondant. En cas de colocalisation, le serveur de surveillance et le serveur d’archivage peuvent chacun prendre en charge jusqu’à 100 000 utilisateurs.

  Notez que vous devez déployer ces serveurs sur un seul site central. Si la liaison entre les deux sites centraux tombe en panne, la technologie de Message Queuing (ou MSMQ) utilisée par les deux serveurs contribue à préserver les données pendant la perte temporaire de la liaison.

  Dans cette topologie, le serveur de surveillance et le serveur d’archivage utilisent un serveur de base de données distinct de celui d’un pool frontal. Les topologies dans lesquelles le serveur de surveillance et le serveur d’archivage partagent les mêmes serveurs de base de données que le pool frontal sont également prises en charge, bien que sur de grands déploiements, tels que celui-ci, des serveurs de base de données séparés sont recommandés pour garantir les performances.

• Options de déploiement de site de succursale.   L’organisation dans cette topologie a déployé Voix Entreprise en tant que solution de voix. Les sites de succursale 1 et 3 ne disposent pas d’une liaison de réseau étendu robuste avec le site central, par conséquent, des Survivable Branch Appliance ont été déployés pour fournir un service téléphonique en cas de panne de la liaison du réseau étendu avec le site central. Néanmoins, le site de succursale 2 comporte une liaison de réseau étendu robuste ; seule une passerelle PSTN est donc requise. La passerelle PSTN déployée ici prend en charge le contournement de média. Aucun serveur de médiation n’est donc requis sur le site de succursale B. Pour plus d’informations sur le choix des éléments à installer sur un site de succursale, voir Planification de la résistance de Voix entrerprise dans la documentation de planification.

• Jonction SIP et serveur de médiation :   Notez que sur un site A, le serveur de médiation n’est pas colocalisé avec les serveurs frontaux. En effet, un serveur de médiation autonome est préférable sur les sites qui utilisent une jonction SIP. Dans la plupart des autres cas, nous recommandons de colocaliser le serveur de médiation avec le serveur frontal. Pour plus d’informations sur les topologies de serveur de médiation, voir Composants et topologies pour le serveur de médiation dans la documentation de planification.

• Équilibrage de la charge DNS.   Le pool frontal, le pool de serveur Edge et le pool directeur ont un équilibrage de la charge DNS pour le trafic SIP déployé. Cela vous évite de devoir recourir à des programmes d’équilibrage de la charge matérielle pour l’interface interne des serveurs Edge et cela réduit significativement le temps consacré à leur configuration et maintenance pour les autres pools, étant donné que ces programmes sont requis uniquement pour le trafic HTTP. Pour plus d’informations sur l’équilibrage de charge DNS, voir Équilibrage de charge DNS dans la documentation de planification.

• Déploiement de la messagerie unifiée Exchange :  Lync Server 2010 fonctionne avec des déploiements locaux de la messagerie unifiée Exchange et avec la messagerie unifiée Exchange hébergée. Le site central A inclut un serveur de messagerie unifiée Exchange, qui exécute Microsoft Exchange Server, et non Lync Server. La fonctionnalité de messagerie unifiée Exchange pour Lync Server s’exécute sur le pool frontal.

  Le site central B utilise la version Exchange hébergée, de sorte que la fonctionnalité du serveur de messagerie unifiée Exchange l’est également.

  Pour plus d’informations sur la messagerie unifiée Exchange, voir Intégration de la messagerie unifiée Exchange sur site et Intégration de la messagerie unifiée Exchange hébergée dans la documentation de planification.