Test Results

 

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

Cette rubrique décrit le résultat des tests effectués par Microsoft sur la solution de basculement présentée dans cette section.

Latence des liens vers le site central

Nous avons utilisé un simulateur de latence réseau pour introduire la latence dans le lien WAN simulé entre les sites Nord et Sud. La topologie recommandée prend en charge une latence maximale de 20 ms entre les sites géographiques. Des améliorations de l'architecture de Lync Server 2010 ont permis d'accepter une latence supérieure à la latence maximale de 15 ms autorisée dans la topologie de résistance de sites métropolitains Microsoft Office Communications Server 2007 R2.

• 15 ms.  Nous avons commencé par introduire une latence de boucle de 15 ms, à la fois dans le chemin réseau entre deux sites et dans le chemin de données utilisé pour la réplication des données entre les deux sites. La topologie a continué à fonctionner sans problème dans ces circonstances.

• 20 ms.   Nous avons alors commencé à augmenter la latence. Avec une latence de boucle de 20 ms à la fois pour le trafic de réseau et de données, la topologie a continué à fonctionner sans problème. 20 ms est la latence de boucle maximale prise en charge pour cette topologie dans Lync Server 2010.

  Important :
  Microsoft ne prend pas en charge les solutions utilisant une latence réseau et de données supérieure à 20 ms.

• 30 ms.   Avec une latence de boucle de 30 ms, nous avons commencé à observer une dégradation des performances. Les files d'attente de message pour l'archivage et la surveillance des bases de données en particulier ont commencé à augmenter. Ceci a également provoqué une dégradation de l'expérience des utilisateurs. Le temps d'ouverture de session et le temps de création d'une conférence ont tous deux augmenté et la qualité A/V a subi une nette dégradation. Pour ces raisons, Microsoft ne prend pas en charge une solution dans laquelle la latence de boucle est supérieure à 20 ms.

Basculement

Comme indiqué précédemment, tous les clusters Windows Server 2008 R2 de la topologie utilisaient un quorum Nœud et Majorité de partage de fichiers. Par conséquent, pour simuler un basculement de site, nous avons dû isoler tous les serveurs et clusters en supprimant la connectivité à la fois vers le site Sud et le site témoin. Nous avons utilisé une fermeture inopinée de tous les serveurs sur le site Nord.

Les résultats et observations relevés après l'arrêt du site Nord étaient les suivants :

• Le nœud de clusters SQL Server passif est devenu actif en l'espace de quelques minutes. Le temps exact peut varier et dépend des détails de l'environnement. Les utilisateurs internes connectés au site Nord ont été déconnectés, puis reconnectés automatiquement. Au cours du basculement, les informations de présence n'ont pas été mises à jour et les nouvelles actions, telles que de nouvelles sessions de messagerie instantanée ou conférences, ont échoué avec les erreurs appropriées. Aucune autre erreur ne s'est produite une fois le basculement terminé.

• Tant qu'il existait un chemin réseau valide entre homologues, les appels d'égal à égal ont continué sans interruption.

• Les appels UC-PSTN ont été déconnectés si la passerelle prenant en charge l'appel n'était plus disponible. Dans ce cas, les utilisateurs pouvaient rétablir l'appel manuellement.

• Les utilisateurs Lync 2010 connectés au site Nord ont été déconnectés, puis reconnectés automatiquement au site Sud en l'espace de quelques minutes. Les utilisateurs pouvaient alors poursuivre comme auparavant.

• Pour se reconnecter, les utilisateurs du client Group Chat ont dû se déconnecter, puis se reconnecter. Les services de canal et de recherche Group Chat dans le site Sud, qui étaient normalement arrêtés ou désactivés sur le site, ont dû être démarrés manuellement.

• Les conférences hébergées sur le site Nord ont basculé automatiquement sur le site Sud. Tous les utilisateurs ont été invités à rejoindre leur conférence à la fin du basculement. Les clients ont pu rejoindre leur réunion. L'enregistrement de la réunion a continué pendant le basculement. L'archivage s'est arrêté jusqu'à ce que le serveur d'archivage de secours soit mis en ligne.

• La gestion des applications a continué à fonctionner pendant que le site Nord était hors service. Par exemple, les utilisateurs pouvaient être déplacés du Survivable Branch Appliance vers le pool frontal.

• Après l'arrêt du site Nord, les clusters SQL Server et les clusters de partage de fichiers du site Sud ont été mis en ligne en l'espace de quelques minutes.

• La durée de basculement du site, telle qu'observée dans nos tests, n'a pas dépassé quelques minutes.

Restauration automatique

Dans le cadre de nos tests, nous avons défini la restauration automatique comme la restauration de l'ensemble de la fonctionnalité du site Nord de sorte que les utilisateurs puissent se reconnecter à des serveurs sur ce site. Une fois le site Nord restauré, toutes les ressources de cluster ont été restaurées dans leurs nœuds sur le site Nord.

Nous vous recommandons d'effectuer la restauration automatique de façon contrôlée, de préférence en dehors des heures ouvrables, dans la mesure où les utilisateurs peuvent rencontrer des perturbations pendant les procédures de restauration. Les résultats et observations relevés lors de la restauration automatique du site Nord étaient les suivants :

• Avant que les ressources de clusters puissent être restaurés vers leurs nœuds sur le site Nord, le stockage a dû être complètement resynchronisé. Sans cette étape, les clusters n'auraient pas pu être mis en ligne. La resynchronisation du stockage s'est effectuée automatiquement.

• Pour réduire au minimum l'impact sur les utilisateurs, les clusters ont été définis de façon à ne pas être restaurés automatiquement. Nous recommandons de reporter la restauration automatique à la prochaine fenêtre de maintenance après avoir vérifié que le stockage a été complètement resynchronisé.

• Les serveurs frontaux seront mis en ligne lorsqu'ils seront en mesure de se connecter aux services de domaine Active Directory. Si la base de données principale n'est pas encore disponible lorsque les serveur frontaux sont mis en ligne, les utilisateurs disposeront d'une fonctionnalité limitée.

  Après la mise en ligne des serveurs frontaux sur le site Nord, de nouvelles connexions seront routées vers ces serveurs. Les utilisateurs qui sont en ligne et qui se connectent généralement par le biais des serveurs frontaux sur le site Nord seront déconnectés, puis reconnectés sur leur serveur habituel du site Nord.

  Si vous souhaitez empêcher les serveurs frontaux du site Nord de se remettre en ligne automatiquement (par exemple, si vous souhaitez mieux contrôler l'ensemble du processus, ou si la latence entre les deux sites n'a pas été restaurée à des niveaux acceptables), nous vous recommandons d'arrêter les serveurs frontaux.

• La durée de la restauration automatique du site telle qu'observée lors de nos tests était inférieure à une minute.