Vue d’ensemble

 

Dernière rubrique modifiée : 2012-10-18

La solution de résistance de site métropolitain décrite dans cette section implique les tâches suivantes :

• Partager le pool frontal entre deux sites physiques, désignés ci-après « Nord » et « Sud ». Dans le Générateur de topologies, ces deux sites géographiques sont configurés comme un site Lync Server 2010 unique.

• Créer des clusters distincts géographiquement dispersés (des clusters de basculement Windows Server 2008 R2 séparés physiquement) pour les éléments suivants :

  • Serveurs principaux

  • Serveurs de base de données Group Chat

  • Serveurs de fichiers

• Déployer un témoin de partage de fichiers Windows Server 2008 R2 auquel tous les clusters de serveurs sont connectés. Pour déterminer l’emplacement adéquat du témoin de partage de fichiers, reportez-vous à la documentation relative aux clusters de basculement Windows Server 2008 R2 à l’adresse https://go.microsoft.com/fwlink/?linkid=211216&clcid=0x40C.

• Permettre la réplication de données synchrone entre les clusters géographiquement dispersés.

• Déployer des serveurs exécutant certains rôles serveur sur les deux sites. Il s’agit notamment des rôles Serveur frontal, Serveur de conférence A/V, Directeur, Serveur Edge et Serveur Group Chat. Les serveurs de chaque type sur les deux sites se trouvent dans un pool de ce type, qui englobe les deux sites. À l’exception du serveur Group Chat, tous les serveurs de ces sites sont actifs sur les deux sites. Tel n’est pas le cas des serveurs Group Chat, qui peuvent être actifs sur un seul site à la fois. Les serveurs Group Chat de l’autre site doivent être inactifs.

  Par ailleurs, il est possible de déployer un serveur de surveillance et un serveur d’archivage sur les deux sites ; en revanche, seuls sont associés aux autres serveurs de votre déploiement le serveur de surveillance et le serveur d’archivage d’un seul site. Le serveur de surveillance et le serveur d’archivage de l’autre site sont déployés mais ne sont associés à aucun pool et font office de serveurs de secours.

La figure suivante offre une vue d’ensemble de la topologie qui en résulte.

Dans la topologie illustrée dans la figure précédente, même si pour une raison quelconque l’un des deux sites venait à être indisponible, les utilisateurs pourraient toujours accéder aux services de communications unifiées pris en charge en quelques minutes, et non en heures. Pour obtenir une description détaillée de la topologie ayant servi à tester la solution présentée dans cette section, voir Topologie de résistance de site.

Portée des tests et de la prise en charge

Cette solution de résistance de site a été testée et validée par Microsoft pour les charges de travail suivantes :

• Messagerie instantanée et présence

• Scénarios d’égal à égal (p.ex., sessions audio/vidéo d’égal à égal)

• Conférence par messagerie instantanée

• Conférence web

• Conférence A/V

• Partage d’application

• Intégration de la Voix Entreprise et de la téléphonie

• Applications Voix Entreprise, notamment Intendant Conférence, le service d’annonce de conférence, le contrôle vocal extérieur et le service Response Group

• Périphériques de communications unifiées approuvés

• URL simples

• Group Chat

• Messagerie unifiée Exchange

Charges de travail en dehors du champ

Bien que les scénarios suivants puissent être déployés dans la topologie de résistance de site métropolitain, le basculement automatique de ces charges de travail n’est ni validé, ni pris en charge :

• Fédération et solution PIC

• Contrôle d’appel distant

• Microsoft Lync Web App

• Passerelle XMPP