Serveurs dans la topologie de résistance de site métropolitain
Dernière rubrique modifiée : 2011-10-18
La topologie de résistance de sites métropolitains peut inclure divers types de rôles de serveur, comme suit :
Pool frontal
Ce pool héberge tous les utilisateurs Lync Server. Chacun des sites, Nord et Sud, comprend quatre serveurs frontaux configurés de façon identique. La base de données principale est déployée en tant que deux nœuds de clusters SQL Server 2008 actifs/passifs dispersés géographiquement, exécutés sur le service Clustering avec basculement de Windows Server 2008 R2. La réplication des données synchrones est requise entre les deux serveurs de la base de données principale.
Dans notre topologie test, le serveur de médiation était colocalisé avec un serveur frontal. Les topologies comportant un serveur de médiation autonome sont également prises en charge.
Notre topologie test utilisait l'équilibrage de charge DNS pour équilibrer le trafic SIP dans le pool, avec des programmes d'équilibrage de la charge matérielle déployés pour le trafic HTTP.
Les topologies qui utilisent uniquement des programmes d'équilibrage de la charge matérielle pour équilibrer tous les types de trafic sont également prises en charge pour la résistance des sites.
Pools de conférence A/V
Nous avons déployé un seul pool de conférence A/V avec quatre serveurs de conférence A/V, deux dans chaque site.
Pool directeur
Nous avons déployé un seul pool directeur avec quatre directeurs, deux dans chaque site.
Pool de serveurs Edge
Les serveurs Edge exécutaient tous les services (services Edge d'accès, de conférence A/V et de conférence Web), mais nous les avons testés uniquement pour des scénarios d'utilisateurs distants. La fédération et la solution PIC n'entraient pas dans le cadre de ce document.
Nous recommandons l’équilibrage de charge DNS pour le pool Edge, mais nous prenons également en charge l’utilisation de programmes d’équilibrage de la charge matérielle. Les interfaces Edge interne et externe doivent utiliser le même type d’équilibrage de la charge. Vous ne pouvez pas utiliser l’équilibrage de la charge DNS sur une interface Edge et l’équilibrage de la charge matérielle sur l’autre interface Edge. Si vous utilisez des programmes d’équilibrage de la charge matérielle pour le pool Edge, le programme sur un site sert de programme principal d’équilibrage de la charge et répond aux demandes en retournant l’adresse VIP du service Edge approprié. Si le programme principal d’équilibrage de la charge n’est pas disponible, le programme secondaire sur l’autre site prend la relève. Chaque site a son propre sous-réseau IP ; les réseaux de périmètre n’ont pas été étendus sur les sites Nord et Sud.
Serveurs Group Chat
Chaque site héberge un service de canal et un service de recherche, mais ces services peuvent être actifs uniquement dans l'un des deux sites à la fois. Le service de canal et le service de recherche de l'autre site doivent être arrêtés ou désactivés. Dans le cas d'un basculement de site, une intervention manuelle est nécessaire pour démarrer ces services sur le site de basculement.
Chaque site héberge en outre un serveur de conformité, mais un seul de ces serveurs peut être actif à la fois. Dans le cas d'un basculement et de la restauration automatique du site, une intervention manuelle est nécessaire pour restaurer le service. Pour plus d'informations, voir Sauvegarde du serveur de conformité dans la documentation des opérations.
Nous avons déployé la base de données principale Group Chat en tant que deux nœuds de clusters actifs/passifs SQL Server 2008 dispersés géographiquement, exécutés en plus de la fonctionnalité Clustering avec basculement de Windows Server 2008 R2. La réplication des données entre les deux serveurs de la base de données principale doit être synchrone. Une seule instance de base de données est utilisée à la fois pour les données de Group Chat et de conformité.
Serveur de surveillance et serveur d’archivage
Pour les serveurs de surveillance et d'archivage, nous recommandons un déploiement de secours. Déployez ces rôles de serveur sur les deux sites, sur un seul serveur sur chaque site. Un seul de ces serveurs est actif, et les pools de votre déploiement sont tous associés à ce serveur actif. L'autre serveur est déployé et installé, mais il n'est associé à aucun pool.
Si le serveur principal n'est plus disponible, vous utilisez le Générateur de topologies pour associer manuellement les pools au serveur de secours, qui devient alors le serveur principal.
Cluster de serveurs de fichiers
Nous avons déployé un serveur de fichiers en tant que ressource à deux nœuds de clusters dispersés géographiquement à l'aide de la fonctionnalité Clustering avec basculement de Windows Server 2008 R2. La réplication synchrone des données était requise. Toute fonction Lync Server nécessitant un partage de fichiers et divisée entre les deux sites doit utiliser ce cluster de partage de fichiers. Ceci inclut notamment :
Emplacement du contenu de la réunion
Emplacement des métadonnées de la réunion
Emplacement des archives de la réunion
Magasin de fichiers du serveur de carnet d'adresses
Magasin de données des applications
Magasin de données des mises à jour clientes
Référentiel de fichiers de conformité Group Chat
Emplacement des fichiers de téléchargement Group Chat
Proxy inverse
Un serveur proxy inverse est déployé sur chacun des sites. Dans notre topologie test, ces serveurs exécutaient Microsoft Forefront Threat Management Gateway. Chaque serveur exécutant Microsoft Forefront Threat Management Gateway fonctionnait indépendamment de l'autre serveur. Un programme d'équilibrage de la charge matérielle était déployé sur chacun des sites.