Información general

 

Última modificación del tema: 2012-10-18

La solución de resistencia de sitio metropolitano descrita en esta sección requiere:

• Dividir el grupo de servidores front-end en dos sitios físicos que llamaremos norte y sur. En el Generador de topologías, estos dos sitios geográficos se configuran en un solo sitio de Lync Server 2010.

• Crear clústeres dispersos geográficamente (clústeres separados físicamente para la conmutación por error de Windows Server 2008 R2) para:

  • Servidores back-end

  • Servidores de base de datos de chat en grupo

  • Servidores de archivos

• Implementar un testigo de recursos compartidos de archivos de Windows Server 2008 R2 al que se conecten todos los clústeres de servidores. Para determinar dónde colocar el testigo de recursos compartidos de archivos, consulte la documentación referente a los clústeres de conmutación por error para Windows Server 2008 R2 en https://go.microsoft.com/fwlink/?linkid=211216&clcid=0xC0A, en inglés.

• Habilitar la replicación sincronizada de datos entre los clústeres dispersos geográficamente.

• Implementar servidores que ejecutan ciertos roles de servidor en ambos sitios. Estos roles son el de servidor front-end, servidor de conferencias A/V, director, servidor perimetral y servidor de chat en grupo. Los servidores de cada tipo en ambos sitios se reúnen en un grupo de servidores de ese mismo tipo, que cruza a ambos lados. Salvo los servidores de chat en grupo, todos los servidores de estos tipos, en ambos sitios, están activos. En el caso de los servidores de chat en grupo, solo puede haber activos servidores en un sitio. Los servidores de chat en grupo del otro sitio deben estar inactivos.

  Además, los servidores de supervisión y de archivado se pueden implementar en ambos sitios. Sin embargo, solo el servidor de supervisión y el de archivado de un sitio están asociados con otros servidores de la implementación. El servidor de supervisión y el de archivado del otro sitio se implementan, pero no están asociados con ningún grupo y sirven como reserva.

En la figura siguiente se presenta la topología resultante.

Con la topología representada en la figura anterior, un sitio puede quedar no disponible por algún motivo pero los usuarios volverán a tener acceso a los servicios de comunicación unificada compatibles en cuestión de minutos, y no horas. Para obtener una descripción detallada de la topología utilizada para probar la solución ofrecida en esta sección, consulte Topología de resistencia de sitios.

Ámbito de las pruebas realizadas y compatibilidad

Esta solución de resistencia del sitio ha sido probada y certificada como compatible por Microsoft para las siguientes cargas de trabajo:

• Mensajería instantánea (IM) y presencia

• Escenarios de conexiones de punto a punto. Por ejemplo, sesiones de audio y vídeo de punto a punto

• Conferencia de mensajería instantánea

• Conferencia web

• Conferencia A/V

• Uso compartido de aplicaciones

• Integración de telefonía IP empresarial y telefonía

• Aplicaciones de Telefonía IP empresarial, como operador de conferencia, el servicio de anuncio de conferencia, control de voz externa y servicio de grupo de respuesta

• Dispositivos aprobados para comunicaciones unificadas

• Direcciones URL sencillas

• Chat en grupo

• UM de Exchange

Cargas de trabajo fuera del ámbito de las pruebas

Los siguientes escenarios se pueden implementar en la topología de resistencia de sitios metropolitanos, pero la conmutación por error automática de estas cargas de trabajo no ha sido designada ni aprobada como compatible:

• Federación y conectividad de mensajería instantánea pública

• Control remoto de llamadas

• Aplicaciones web de Microsoft Lync

• Puerta de enlace de XMPP