Findings and Recommendations

 

Última modificación del tema: 2011-03-25

La solución de resistencia de sitios metropolitanos ha sido puesta a prueba y se ha declarado oficialmente compatible con Microsoft. No obstante, antes de implementar esta tecnología, deberá tener en cuenta las siguientes conclusiones y recomendaciones.

Conclusiones

  • La conmutación por error de los clústeres funcionó como se esperaba. No es necesario realizar operaciones manuales, salvo en el caso del servidor de chat en grupo, el servidor de archivado y el servidor de supervisión. Los servidores front-end se pudieron reconectar a los servidores de base de datos back-end después de la conmutación por error y reanudar el servicio normal. Los clientes de Microsoft Lync 2010 se reconectaron automáticamente.

  • La conmutación por error de los clústeres funcionó como se esperaba. Es importante asegurarse de que el almacenamiento se ha resincronizado antes de que inicie la conmutación por error.

    Los usuarios verán una rápida secuencia de cierre e inicio de sesión mientras son transferidos de vuelta a su servidor front-end habitual en el momento en que vuelva a estar disponible.

  • Cuando se produjo la conmutación por error, fue necesario iniciar manualmente el servicio de búsqueda del servicio de canal de chat en grupo en el sitio en el que se realiza la conmutación por error. Además se tuvo que actualizar manualmente la configuración del servidor de cumplimiento del chat en grupo. Si desea información detallada, consulte Copia de seguridad del servidor de cumplimiento en la documentación de operaciones.

Recomendaciones

  • A pesar de que durante las pruebas se usaron dos nodos (uno por sitio) en cada clúster de SQL Server, se recomienda implementar más nodos para lograr redundancia in situ para todos los componentes de la topología. Por ejemplo, si el nodo activo de SQL Server no está disponible, un nodo SQL Server de reserva situado en el mismo sitio y que forme parte del mismo clúster puede asumir la carga de trabajo hasta que el servidor que ha fallado vuelva a estar en línea o sea sustituido.

  • Para las pruebas utilizamos componentes de fabricantes concretos, pero la solución no depende del uso de componentes de proveedores concretos ni lo exige. Siempre y cuando los componentes estén certificados por Microsoft y sean compatibles con la marca, cualquier proveedor cualificado podrá valer.

  • Todos los componentes individuales de la solución (por ejemplo, los componentes de clústeres geográficamente dispersos) deben ser compatibles con Microsoft y, en su caso, estar certificados por Microsoft. No obstante, esto no significa que Microsoft ofrezca compatibilidad directamente a componentes individuales de terceros. Para obtener información sobre la compatibilidad de componentes concretos, póngase en contacto con el proveedor.

  • Si bien no se ha probado una implementación a escala completa, confiamos en que los números de escala publicados para Lync Server 2010 sean correctos. Teniendo eso en cuenta, debe planificar capacidad suficiente para continuar en funcionamiento si se produce una conmutación por error. Para obtener información detallada, consulte Planeación de la capacidad en la documentación de planeación.

  • La información de esta sección debe utilizarse como orientación. Antes de implementar la solución en un entorno de producción, deberá crearla y probarla usando su propia topología.

Nota

Microsoft no es compatible con implementaciones de esta solución en las que la latencia de red y de replicación de datos entre los sitios principal y secundario excede los 20 ms o cuando el ancho de banda no es compatible con el modelo de usuario de su organización. Cuando la latencia excede los 20 ms, la experiencia de usuario final se deteriora rápidamente. Además, es probable que el servidor de archivado y los servidores de cumplimiento de chat en grupo comiencen a quedarse atrás, lo que podría ocasionar a su vez que los servidores front-end y los servidores de búsqueda de chat en grupo se apaguen.