Requisitos del equilibrador de carga de hardware en Lync Server 2013

 

Última modificación del tema: 2015-05-11

La topología perimetral consolidada a escala de Lync Server 2013 está optimizada para el equilibrio de carga DNS para las nuevas implementaciones que se federan principalmente con otras organizaciones que usan Lync Server. Si se requiere alta disponibilidad para cualquiera de los siguientes escenarios, debe usarse un equilibrador de carga de hardware en los grupos de servidores perimetrales para lo siguiente:

• Federación con organizaciones que usan Office Communications Server 2007 R2 u Office Communications Server 2007

• Mensajería unificada de Exchange para usuarios remotos que usan la mensajería unificada de Exchange anterior a Exchange 2010 con SP1

• Conectividad con usuarios de mensajería instantánea (MI) pública

Importante

No se admite el uso del equilibrio de carga de DNS en una interfaz y del equilibrio de carga de hardware en otra. Necesita utilizar el equilibrio de carga de hardware o de DNS en ambas interfaces.

Nota

Si usa un equilibrador de carga de hardware, el equilibrador de carga que se haya implementado para las conexiones con la red interna necesitará configurarse para que solo equilibre la carga del tráfico de los servidores que ejecuten el servicio perimetral de acceso y el servicio perimetral A/V. No puede equilibrar la carga del tráfico al servicio perimetral de conferencia web interno o al servicio proxy XMPP interno.

Nota

El NAT de retorno directo del servidor (DSR) no es compatible con Lync Server 2013.

Para determinar si el equilibrador de carga de hardware admite las características necesarias requeridas por Lync Server 2013, consulte "Lync Server 2010 Load Balancer Partners" en https://go.microsoft.com/fwlink/p/?linkId=202452.

Requisitos de equilibrador de carga de hardware para servidores perimetrales que ejecutan el servicio perimetral A/V

Estos son los requisitos del equilibrador de carga de hardware para los servidores perimetrales que ejecutan el servicio perimetral A/V:

• Deshabilitar el algoritmo de Nagle de TCP para los puertos 443 internos y externos. El algoritmo de Nagle es el proceso de combinación de varios paquetes pequeños en un único paquete más grande para obtener una transmisión más eficiente.

• Deshabilitar el algoritmo de Nagle de TCP para el intervalo de puertos externos de 50 000 a 59 999.

• No utilizar NAT en el firewall interno o externo.

• La interfaz interna del perímetro debe estar en una red distinta de la interfaz externa del servidor perimetral y el enrutamiento entre ellos debe estar deshabilitado.

• La interfaz externa del servidor perimetral que ejecuta el servicio perimetral de A/V debe usar direcciones IP enrutables públicamente y ninguna nat o traducción de puertos en ninguna de las direcciones IP externas perimetrales.

Requisitos del equilibrador de carga de hardware

Los requisitos de afinidad basada en cookies se reducen considerablemente en Los servicios web de Lync Server 2013. Si va a implementar Lync Server 2013 y no conservará ningún servidor front-end de Lync Server 2010 ni grupos de servidores front-end, no necesita persistencia basada en cookies. Sin embargo, si conservará temporal o permanentemente los servidores front-end de Lync Server 2010 o los grupos de servidores front-end, seguirá usando la persistencia basada en cookies a medida que se implementa y configura para Lync Server 2010.

Nota

La utilización de la afinidad basada en cookies pese a que su implementación no la necesite no tiene repercusiones.

Para las implementaciones que no utilizarán la afinidad basada en cookies:

• En la regla de publicación del proxy inverso para el puerto 4443, establezca Reenviar encabezado de host en True. Esto garantizará que se reenviará la dirección URL original.

Para las implementaciones que utilizarán la afinidad basada en cookies:

• En la regla de publicación del proxy inverso para el puerto 4443, establezca Reenviar encabezado de host en True. Esto garantizará que se reenviará la dirección URL original.

• La cookie del equilibrador de carga de hardware NO NECESITA estar marcada como httpOnly

• La cookie del equilibrador de carga de hardware NO NECESITA tener tiempo de expiración

• La cookie del equilibrador de carga de hardware NECESITA tener el nombre MS-WSMAN (este es el valor esperado por los servicios web y no puede modificarse)

• La cookie del equilibrador de carga de hardware NECESITA estar establecida en cada respuesta HTTP para la que la solicitud HTTP entrante no tenía una cookie, independientemente de si una respuesta HTTP anterior en la misma conexión TCP ya había obtenido una cookie. Si el equilibrador de carga optimiza la inserción de cookies para que solo ocurra una vez por conexión TCP, la optimización NO NECESITA usarse.

Nota

Las configuraciones típicas del equilibrador de carga de hardware usan afinidad de dirección de origen y 20 minutos. Duración de la sesión TCP, que es válida para los clientes de Lync Server y Lync 2013 porque el estado de la sesión se mantiene mediante el uso del cliente y/o la interacción de la aplicación.

Si se implementan dispositivos móviles, es preciso que el equilibrador de carga de hardware pueda equilibrar la carga de una solicitud individual dentro de una sesión TCP (de hecho, necesita poder equilibrar la carga de una solicitud individual basada en la dirección IP de destino).

Advertencia

Los equilibradores de carga de hardware F5 tienen una característica llamada OneConnect que asegura que cada solicitud dentro de una conexión TCP tenga carga equilibrada individualmente. Si va a implementar dispositivos móviles, asegúrese de que su proveedor del equilibrador de carga de hardware admita la misma función. Las últimas aplicaciones móviles que utilizan Apple iOS requieren la versión 1.2 de la seguridad de la capa de transporte (TLS). Para ellos, F5 proporciona una configuración específica.
Para obtener más información sobre los equilibradores de carga de hardware de terceros, consulte https://go.microsoft.com/fwlink/p/?linkId=230700

A continuación, se muestran los requisitos del equilibrador de carga de hardware para los servicios web del grupo de servidores front-end y de directores:

• Para VIP de los servicios web internos, configure la persistencia Source_addr (puerto interno 80, 443) en el equilibrador de carga de hardware. Para Lync Server 2013, Source_addr persistencia significa que siempre se envían varias conexiones procedentes de una única dirección IP a un servidor para mantener el estado de la sesión.

• Use un tiempo de espera de inactividad de TCP de 1800 segundos.

• En el firewall entre el proxy inverso y el equilibrador de carga de hardware del grupo de servidores del próximo salto, cree una regla que permita el tráfico https: en el puerto 4443, desde el proxy inverso al equilibrador de carga de hardware. El equilibrador de carga de hardware necesita configurarse para que escuche los puertos 80, 443 y 4443.

Importante

Para obtener más información sobre la configuración del equilibrador de carga de hardware, revise Resumen del puerto: borde consolidado escalado con equilibradores de carga de hardware en Lync Server 2013.

Resumen de los requisitos de afinidad del equilibrador de carga de hardware

Ubicación de cliente/usuario	Requisitos de afinidad del FQDN de servicios web externos	Requisitos de afinidad del FQDN de servicios web internos
Lync Web App (usuarios internos y externos) Dispositivo móvil (usuarios internos y externos)	Sin afinidad	Afinidad de direcciones de origen
Lync Web App (solo usuarios externos) Dispositivo móvil (usuarios internos y externos)	Sin afinidad	Afinidad de direcciones de origen
Lync Web App (solo usuarios internos) Dispositivo móvil (no implementado)	Sin afinidad	Afinidad de direcciones de origen

Supervisión de puertos para los equilibradores de carga de hardware

Es necesario definir la supervisión de puertos en los equilibradores de carga de hardware para determinar cuándo determinados servicios dejan de estar disponibles por errores de comunicaciones o de hardware. Por ejemplo, si el servicio servidor front-end (RTCSRV) se detiene porque se produce un error en el servidor front-end o el grupo de servidores front-end, la supervisión de HLB también debe dejar de recibir tráfico en los servicios web. La supervisión de puertos en ECH tiene que implementarse para supervisar lo siguiente:

Grupo de usuarios del servidor front-end: interfaz interna de HLB

Puerto/IP virtual	Puerto de nodo	Monitor/máquina de nodo	Perfil de persistencia	Notas
<int_mco_443_vs web de la piscina> 443	443	Front-end 5061	Origen	HTTPS
<int_mco_80_vs web de la piscina> 80	80	Front-end 5061	Origen	HTTP

Grupo de usuarios del servidor front-end: interfaz externa HLB

Puerto/IP virtual	Puerto de nodo	Monitor/máquina de nodo	Perfil de persistencia	Notas
<web_mco_443_vs de la piscina> 443	4443	Front-end 5061	Ninguno	HTTPS
<web_mco_80_vs de la piscina> 80	8080	Front-end 5061	Ninguno	HTTP