Test Results

Latencia del vínculo en un sitio central

Utilizamos un simulador de latencia de red para introducir latencia en un vínculo WAN simulado entre norte y sur. La topología recomendada admite una latencia máxima de 20 ms entre los sitios geográficos. Las mejoras en la arquitectura de Lync Server 2010 hacen que la latencia permitida sea superior a los 15 ms máximos que se permiten en la topología de resistencia de sitios metropolitanos de Microsoft Office Communications Server 2007 R2.

• 15 ms.   Comenzamos introduciendo una latencia de recorrido de ida y vuelta de 15 ms en la ruta de red entre dos sitios y la ruta de datos empleadas para la replicación de datos entre dos sitios. La topología continuó funcionando sin problema en estas condiciones y con carga.

• 20 ms.   A continuación, comenzamos a aumentar la latencia. Con una latencia de recorrido de ida y vuelta de 20 ms para el tráfico de red y de datos, la topología continuó funcionando sin problemas. Estos 20 ms es la latencia de ida y vuelta máxima que se admite en esta topología en Lync Server 2010.

  Importante:
  Microsoft no admite soluciones cuya latencia de red y de datos supere los 20 ms.

• 30 ms.   Con una latencia de recorrido de ida y vuelta de 30 ms, comenzamos a observar cierta degradación del rendimiento. Concretamente, las colas de mensajes de las bases de datos de archivado y supervisión comenzaron a aumentar; de modo que la experiencia del usuario también se degrada. Asimismo, aumentó el tiempo de inicio de sesión y de creación de conferencias, además de que la experiencia de A/V se degradó notablemente. Por estos motivos, Microsoft no admite soluciones en las que la latencia del recorrido de ida y vuelta sea superior a 20 ms.

Conmutación por error

Como se ha mencionado anteriormente, todos los clústeres de Windows Server 2008 R2 de la topología utilizaban un quórum Mayoría de recurso compartido de archivos y nodo. De modo que para simular una conmutación por error en el sitio, tuvimos que aislar todos los servidores y clústeres mediante la pérdida de conectividad tanto al sitio del sur, como en el sitio testigo. Utilizamos un "cierre con errores" en todos los servidores del sitio norte.

Los resultados y las observaciones tras el fallo del sitio norte son los siguientes:

• El nodo de clústeres de SQL Server pasivo se activó en unos minutos. El tiempo exacto puede variar y depende de los detalles del entorno. Se cerró la sesión de los usuarios internos conectados al sitio norte y se les volvió a conectar automáticamente. Durante la conmutación por error, no se actualizó la presencia y las acciones nuevas, como las sesiones de mensajería instantánea y las conferencias nuevas, arrojaron los errores correspondientes. No ocurrieron más errores después de completada la conmutación por error.

• Siempre y cuando haya una ruta de red válida entre usuarios, las llamadas entre usuarios en curso continúan sin interrupción.

• Las llamadas UC-RTC se desconectaban si la puerta de enlace por la que se realizaba la llamada quedaba no disponible. En ese caso, los usuarios podían restablecer manualmente la llamada.

• Los usuarios de Lync 2010 conectados al sitio norte se desconectaban y volvían a conectar automáticamente al sitio sur en minutos. Los usuarios podían entonces continuar como hasta el momento.

• Para volver a conectarse, los usuarios cliente del chat en grupo tenían que salir y volver a iniciar sesión. El servicio de canal de chat en grupo y el servicio de búsquedas del sitio sur, que normalmente se detenían o deshabilitaban en el sitio, tenían que iniciarse manualmente.

• Las conferencias alojadas en el sitio norte se conmutaron automáticamente por error al sitio sur. Se pidió a todos los usuarios que volvieran a unirse a la conferencia después de realizar la conmutación por error y pudieron volver a unirse a la reunión. La grabación de la reunión no se interrumpió durante la conmutación por error. El archivado se interrumpió hasta que el servidor de archivado en espera activa volvió a conectarse.

• La manejabilidad continuó funcionando mientras el sitio norte estaba inoperativo. Los usuarios podían, por ejemplo, moverse desde la Aplicación de sucursal con funciones de supervivencia hasta el grupo de servidores front-end.

• Unos minutos después de que el sitio norte quedara sin línea, los clústeres de SQL Server y los clústeres de recursos compartidos de archivos del sitio sur se conectaron.

• La duración de la conmutación del sitio por error observada en las pruebas realizadas fue de solo unos minutos.

Conmutación por recuperación

En el contexto de las pruebas realizadas, el término "conmutación por recuperación" significa restaurar todas las funciones del sitio norte de modo que los usuarios se puedan volver a conectar a los servidores de ese sitio. Después de restaurar el sitio norte, todos los recursos de los clústeres se devolvieron a sus nodos en el sitio norte.

Se recomienda que la conmutación por recuperación se lleve a cabo de forma controlada, preferiblemente durante las horas de inactividad, puesto que el proceso puede generar algunas molestias para los usuarios. Los resultados y las observaciones tras la conmutación por recuperación del sitio norte son los siguientes:

• Antes de poder devolver los recursos de los clústeres a sus nodos del sitio norte, hubo que resincronizar completamente el almacenamiento. Si no se resincroniza el almacenamiento, los clústeres no pueden volver a conectarse. La resincronización del almacenamiento es automática.

• Para garantizar el mínimo impacto en el usuario, se configuraron los clústeres para que la conmutación por recuperación no fuera automática. Se recomienda posponer la conmutación por recuperación hasta el siguiente período de mantenimiento, después de comprobar que el almacenamiento se ha resincronizado completamente.

• Los servidores front-end estarán en línea cuando puedan conectarse a los servicios de dominio de Active Directory. Si la base de datos back-end todavía no se encuentra disponible cuando los servidores front-end estén en línea, los usuarios verán limitadas las funcionalidades.

  Una vez que los servidores front-end del sitio norte estén en línea, se encaminarán las nuevas conexiones hacia ellos. Se cerrará la sesión de los usuarios que estén en línea y que se suelan conectar a través de los servidores front-end del sitio norte y se les volverá a iniciar sesión en su servidor habitual del sitio norte.

  Si quiere evitar que los servidores front-end del sitio norte vuelvan a conectarse automáticamente, por ejemplo, si quiere controlar mejor todo el proceso o si la latencia entre los dos sitios no ha sido restaurada todavía a niveles aceptables, le recomendamos que apague los servidores front-end.

• La duración de la conmutación del sitio por recuperación observada durante las pruebas fue inferior a un minuto.