Findings and Recommendations

 

Dernière rubrique modifiée : 2011-03-25

La solution de résilience de site métropolitain a été testée et est officiellement prise en charge par Microsoft ; toutefois, avant de déployer cette topologie, vous devez tenir compte des constatations et des recommandations suivantes.

Constatations

• Le basculement de cluster a fonctionné comme prévu. Aucune intervention manuelle n’a été nécessaire, sinon pour le serveur Group Chat, le serveur d’archivage et le serveur de surveillance. Les serveurs frontaux ont pu se reconnecter aux serveurs de base de données principale après basculement et reprendre du service normalement. Les clients Microsoft Lync 2010 se sont reconnectés automatiquement.

• La restauration automatique du cluster a fonctionné comme prévu. Il est important de s’assurer que le stockage s’est resynchronisé avant que la restauration automatique ne débute.

  Les utilisateurs pourront constater une rapide séquence de fermeture/ouverture de session au moment d’être retransférés sur leur serveur frontal habituel, dès lors qu’il redeviendra disponible.

• Lorsque le basculement s’est produit, le service de canal Group Chat et le service de recherche ont dû être démarrés manuellement sur le site de basculement. De plus, le paramètre de serveur de conformité Group Chat a dû être mis à jour manuellement. Pour plus d’informations, voir Sauvegarde du serveur de conformité dans la documentation relative aux opérations.

Recommandations

• Même si, dans le cadre des tests, nous avons utilisé deux nœuds (un par site) dans chaque cluster SQL Server, nous vous recommandons de déployer des nœuds supplémentaires afin d’assurer une redondance sur site pour tous les composants de la topologie. Par exemple, si le nœud SQL Server actif devient indisponible, un nœud SQL Server de secours sur le même site et une partie du même cluster pourront assumer la charge de travail en attendant que le serveur défaillant soit rétabli ou remplacé.

• Bien que les composants utilisés lors de nos tests aient été fournis par certains fournisseurs tiers, la solution ne dépend pas ou ne prescrit pas de fournisseurs particuliers. Du moment que les composants sont agréés et pris en charge par Microsoft, vous pouvez faire appel à n’importe quel fournisseur qualifié.

• Tous les composants individuels de la solution (par exemple, les composants d’un cluster géographiquement dispersé) doivent être pris en charge et, le cas échéant, agréés Microsoft. Cela ne signifie pas pour autant que Microsoft assurera un support direct des composants tiers individuels. Pour bénéficier d’un support sur les composants, contactez leur fournisseur tiers respectif.

• Bien qu’aucun test n’ait porté sur un déploiement complet, les chiffres sur les différentes échelles, qui seront bientôt publiés pour Lync Server 2010, devraient se révéler rassurants. Compte tenu de cela, vous avez tout intérêt à prévoir une capacité suffisante pour assurer la continuité des opérations en cas de basculement. Pour plus d’informations, voir Planification de la capacité dans la documentation relative à la planification.

• Les informations contenues dans cette section sont fournies uniquement à titre indicatif. Avant de déployer cette solution dans un environnement de production, vous devez la bâtir et la tester en utilisant votre propre topologie.

Remarque :

Microsoft ne prend pas en charge les implémentations de cette solution lorsque le temps de réponse du réseau et la latence de la réplication des données entre les site principal et les sites secondaires dépassent 20 ms ou que la bande passante ne prend pas en charge le modèle utilisateur pour votre organisation. Lorsque le temps de réponse dépasse 20 ms, l’expérience de l’utilisateur se détériore rapidement. Par ailleurs, le serveur d’archivage et les serveurs de conformité Group Chat risquent de décrocher et de provoquer l’arrêt des serveurs frontaux et des serveurs de recherche Group Chat.