Requisitos del equilibrio de carga para Skype Empresarial

 

Última modificación del tema:2017-11-17

Resumen:  Revise la carga equilibrio consideraciones antes de implementar Skype Empresarial Server 2015.

Equilibrio de carga distribuye el tráfico entre los servidores de un grupo. Si tiene grupos de Grupos de servidores front-end, Grupos de servidores de mediación o Servidor perimetral, tiene que implementar el equilibrio de carga en estos grupos.

Skype Empresarial Serveradmite dos tipos de soluciones para el tráfico de cliente a servidor de equilibrio de carga: sistema de nombres de dominio (DNS) de equilibrio de carga y a menudo (abreviado como HLB) de equilibrio de carga de hardware. El equilibrio de carga de DNS ofrece varias ventajas, como una administración más sencilla, una solución de problemas más eficaz y la capacidad de aislar gran parte del tráfico de Skype Empresarial Server de posibles problemas en el equilibrador de carga de hardware.

Decidir por sí mismo qué solución de equilibrio de carga es adecuada para cada grupo en su implementación, pero tenga en cuenta las siguientes restricciones:

  • La interfaz perimetral interna y la interfaz perimetral externa necesitan usar el mismo tipo de equilibrio de carga. No puede usar el equilibrio de carga de DNS en una interfaz y el equilibrio de carga de hardware en la otra.

  • Algunos tipos de tráfico requieren un equilibrador de carga de hardware. Por ejemplo, el tráfico HTTP requiere un equilibrador de carga de hardware en lugar del equilibrio de carga de DNS. El equilibrio de carga de DNS no funciona con tráfico web del cliente al servidor.

Si decide usar el equilibrio de carga de DNS para un grupo, pero aún tiene que implementar equilibradores de carga de hardware para el tráfico, como el tráfico HTTP, la administración de los equilibradores de carga de hardware será mucho más sencilla. Por ejemplo, configurar el equilibrador de carga de hardware será más sencillo, pues solamente administrará el tráfico HTTPS y HTTP, mientras que el equilibrio de carga de DNS administrará todos los demás protocolos. Para obtener más información, consulte DNS equilibrio de carga.

Para un tráfico de servidor a servidor, Skype Empresarial Server usa un equilibrio de carga preparado para la topología. Los servidores leen la topología publicada en el Almacén de administración central para obtener los FQDN de los servidores en la topología y distribuir automáticamente el tráfico entre los servidores. Los administradores no necesitan configurar ni administrar este tipo de equilibrio de carga.

Si utiliza el equilibrio de carga de DNS y necesita bloquear el tráfico a un equipo específico, no es suficiente con solo quitar las entradas de direcciones IP del FQDN del grupo de servidores. También es preciso quitar la entrada de DNS para el equipo.

La topología perimetral consolidada con escala de Skype Empresarial Server está optimizada para el equilibrio de carga de DNS de las nuevas implementaciones que se federan principalmente con otras organizaciones por medio de Skype Empresarial Server o Lync Server. En caso de que se necesite alta disponibilidad en cualquiera de los siguientes escenarios, se necesitará usar un equilibrador de carga de hardware en grupos de Servidor perimetral para lo siguiente:

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

  • Mensajería unificada de Exchange para los usuarios remotos que utilicen Mensajería unificada de Exchange antes de Exchange 2010 con SP1

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

importantImportante:
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.
noteNota:
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.
noteNota:
Skype Empresarial Server no es compatible con NAT de Direct Server Return (DSR).

Para saber si su equilibrador de carga de hardware admite las características que necesita Skype Empresarial Server, consulte Infraestructura para Skype Empresarial.

A continuación, se muestran los requisitos del equilibrador de carga de hardware para Servidores perimetrales que ejecuten un 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 perimetral y la interfaz externa del Servidor perimetral necesitan estar en redes diferentes, y es preciso deshabilitar el enrutamiento entre ellas.

  • La interfaz externa del Servidor perimetral que ejecute el servicio perimetral A/V necesita usar direcciones IP públicamente enrutables y ninguna NAT o ninguna conversión de puerto en ninguna de las direcciones IP externas perimetrales.

  • El equilibrador de carga no necesita cambiar la dirección de origen del cliente.

Los requisitos de afinidad basada en cookies se han reducido en gran medida en Skype Empresarial Server para los servicios web. Si va a implementar Skype Empresarial Server y no va a mantener ninguno de los Servidores front-end o los Grupos de servidores front-end de Lync Server 2010, no necesita la persistencia basada en cookies. Pero, si va a mantener de forma temporal o permanente algunos de los Servidores front-end o los Grupos de servidores front-end de Lync Server 2010, necesitará seguir utilizando la persistencia basada en cookies tal como está implementada y configurada para Lync Server 2010.

noteNota:
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.

noteNota:
Las configuraciones típicas del equilibrador de carga de hardware usan la afinidad de direcciones de origen y una duración de sesión TCP de 20 minutos, que es adecuada para clientes de Lync Server y Lync 2013 porque el estado de la sesión se mantiene a través del uso del cliente o la interacción de aplicaciones.

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).

warningAdvertencia:
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 más detalles sobre los equilibradores de carga de hardware de terceros, consulte Infraestructura para Skype Empresarial.

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 Skype Empresarial Server, la persistencia Source_addr significa que se envían siempre varias conexiones 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.

 

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

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 del Servidor front-end (RTCSRV) se detiene por un error en el Servidor front-end o en el Grupo de servidores front-end, la supervisión de ECH también necesita dejar de recibir tráfico del 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 ECH

Puerto/IP virtual Puerto de nodo Monitor/máquina de nodo Perfil de persistencia Notas

<pool>web-int_mco_443_vs

443

443

Front-end

5061

Origen

HTTPS

<pool>web-int_mco_80_vs

80

80

Front-end

5061

Origen

HTTP

Grupo de usuarios del Servidor front-end: interfaz externa de ECH

Puerto/IP virtual Puerto de nodo Monitor/máquina de nodo Perfil de persistencia Notas

<pool>web_mco_443_vs

443

4443

Front-end

5061

Ninguno

HTTPS

<pool>web_mco_80_vs

80

8080

Front-end

5061

Ninguno

HTTP

Skype Empresarial Server permite el equilibrio de carga de DNS, una solución de software que puede reducir considerablemente la sobrecarga de administración para el equilibrio de carga en la red. El equilibrio de carga de DNS equilibra el tráfico de red que solo pertenece a Skype Empresarial Server, como el tráfico SIP y el tráfico de medios.

Si implementa el equilibrio de carga de DNS, se reducirá considerablemente la sobrecarga de administración de la organización correspondiente a los equilibradores de carga de hardware. Además, se evitará la solución de problemas complejos asociados a errores de configuración de equilibradores de carga del tráfico SIP. También puede impedir que se establezcan conexiones de servidores para poder desconectar servidores. El equilibrio de carga de DNS también garantiza que los problemas relacionados con los equilibradores de carga de hardware no afecten a elementos de tráfico SIP, como el enrutamiento de llamadas básico.

Si se utiliza el equilibrio de carga de DNS también podrá adquirir equilibradores de carga de hardware a un precio más económico que si usa equilibradores de carga de hardware para todos los tipos de tráfico. Necesitará utilizar equilibradores de carga que hayan superado las pruebas de calificación de interoperabilidad con Skype Empresarial Server. Para obtener más información acerca de pruebas de interoperabilidad de equilibrador de carga, consulte Asociados de equilibrador de carga de Lync Server 2010. Allí, el contenido se aplica a Skype Empresarial Server.

El equilibrio de carga de DNS es compatible con grupos de servidores front-end, grupos de servidores perimetrales, grupos de servidores de director y grupos de servidores de mediación independientes.

El equilibrio de carga de DNS suele implementarse en la aplicación. La aplicación (por ejemplo, un cliente que ejecuta Skype Empresarial), intenta conectarse a un servidor en un grupo conectándose a una de las direcciones IP obtenidas a raíz de la consulta del registro A y AAAA (si se usa el direccionamiento IPv6) de DNS para el nombre de dominio completo (FQDN) del grupo.

Por ejemplo, si hay tres servidores front-end en un grupo denominado pool01.contoso.com, pasará lo siguiente:

  • Los clientes que ejecutan Skype Empresarial envían una consulta al DNS para pool01.contoso.com y esta obtendrá como resultado tres direcciones IP que almacenará en caché de la forma siguiente (no necesariamente en este orden):

    pool01.contoso.com      192.168.10.90

    pool01.contoso.com      192.168.10.91

    pool01.contoso.com      192.168.10.92

  • Luego, el cliente intenta establecer una conexión del Protocolo de control de transmisión (TCP) con una de las direcciones IP. Si no funciona, lo intenta con la siguiente dirección IP almacenada en caché.

  • Si la conexión TCP se establece correctamente, el cliente negocia con el TLS para conectarse con el registrador principal en pool01.contoso.com.

  • Si el cliente intenta todas las entradas almacenadas en caché sin establecer una conexión correctamente, se notifica al usuario que en ese momento no hay disponible ningún servidor que ejecute Skype Empresarial Server.

noteNota:
El equilibrio de carga basado en DNS es distinto al round robin de DNS (RR de DNS), que normalmente hace referencia al equilibrio de carga usando el DNS para proporcionar un orden distinto de direcciones IP correspondientes a los servidores de un grupo de servidores. Por lo general, RR de DNS solo habilita la distribución de carga, pero no habilita la conmutación por error. Por ejemplo, si no se consigue establecer la conexión con una de las direcciones IP devueltas por la consulta A y AAAA (si está usando el direccionamiento IPv6) de DNS, la conexión será errónea. Por tanto, el round robin de DNS por sí solo es menos fiable que el equilibrio de carga basado en DNS. Puede usar el round robin de DNS junto con el equilibrio de carga de DNS.

El equilibrio de carga de DNS se usa para lo siguiente:

  • Equilibrar la carga SIP de servidor a servidor con los servidores perimetrales

  • Equilibrar la carga de aplicaciones de servicios de aplicaciones de comunicaciones unificadas (UCAS) como Operador automático de conferencia, Grupo de respuesta y Estacionamiento de llamadas

  • Impedir el establecimiento de nuevas conexiones con aplicaciones UCAS (proceso también conocido como "purga").

  • Equilibrar la carga de todo el tráfico desde el servidor al cliente entre clientes y servidores perimetrales

El equilibrio de carga de DNS no puede usarse para:

  • Tráfico web de cliente a servidor al director o a los servidores front-end

Equilibrio de carga de DNS y tráfico federado:

Si una consulta SRV de DNS devuelve varios registros de DNS, el servicio perimetral de acceso siempre selecciona el registro SRV de DNS con la prioridad numérica más baja y con el peso numérico más alto. Internet Engineering Task Force "A DNS RR for specifying the location of services (DNS SRV)" del documento RFC 2782, RR de SRV de DNS especifica que si hay varios DNS SRV registros definidos, la prioridad se utiliza en primer lugar, a continuación, peso. Por ejemplo, el registro A de SRV de DNS tiene un peso de 20 y una prioridad de 40, y el registro B de SRV de DNS tiene un peso de 10 y una prioridad de 50. Se seleccionará el registro A de SRV de DNS con una prioridad de 40. Las siguientes reglas se aplican a la selección de registros SRV de DNS:

  • La prioridad se considera primero. Un cliente TIENE QUE intentar contactar con el host de destino definido por el registro SRV de DNS con la menor prioridad numerada que pueda alcanzar. Los destinos con la misma prioridad NECESITAN intentarse siguiendo el orden definido por el campo de peso.

  • El campo de peso especifica un peso relativo para las entradas que tienen la misma prioridad. Es PRECISO que a los pesos más grandes se les otorgue una probabilidad proporcionalmente mayor para ser seleccionados. Los administradores de DNS TIENEN QUE usar el peso 0 cuando no hay ninguna selección de servidor que hacer. Cuando existen registros con pesos superiores a 0, los registros con peso 0 necesitan tener una oportunidad muy pequeña de ser elegidos.

Si se devuelven varios registros SRV de DNS con la misma prioridad y el mismo peso, el servicio perimetral de acceso seleccionará el registro SRV que se haya obtenido en primer lugar del servidor DNS.

Puede usar el equilibrio de carga de DNS para el tráfico SIP de los grupos de servidores front-end y los grupos de servidores de director. Con el equilibrio de carga de DNS implementado, seguirá necesitando usar también equilibradores de carga de hardware para esos grupos de servidores, pero solo para el tráfico HTTPS de cliente a servidor. El equilibrador de carga de hardware se usa para el tráfico HTTPS de los clientes en los puertos 443 y 80.

A pesar de que seguirá necesitando equilibradores de carga de hardware para esos grupos de servidores, su instalación y administración será fundamentalmente para el tráfico HTTPS, al que están habituados los administradores de equilibradores de carga de hardware.

El equilibrio de carga de DNS admite la conmutación automática por error solo en los servidores que ejecutan Skype Empresarial Server o Lync Server 2010 y para los clientes de Lync 2013 y Skype Empresarial. Las versiones anteriores de los clientes y Office Communications Server pueden seguir conectándose a grupos de servidores que ejecuten el equilibrio de carga de DNS pero, si no consiguen establecer una conexión con el primer servidor al que los remita el equilibrio de carga de DNS, no pueden efectuar la conmutación por error a otro servidor del grupo.

Por otra parte, si usa la mensajería unificada de Exchange, necesita utilizar como mínimo Exchange 2010 SP1 para obtener compatibilidad con el equilibrio de carga de DNS de Skype Empresarial Server. Si usa alguna versión anterior de Exchange, los usuarios no tendrán capacidades de conmutación por error para estos escenarios de la mensajería unificada de Exchange:

  • Reproducir el correo de voz de Enterprise en el teléfono

  • Transferir llamadas de un operador automático de la mensajería unificada de Exchange

Todos los demás escenarios de la mensajería unificada de Exchange funcionarán correctamente.

Para implementar el equilibrio de carga de DNS en grupos de servidores front-end y grupos de servidores de director, es necesario realizar un par de pasos adicionales con los registros de DNS y los FQDN.

  • Si un grupo de servidores usa equilibrio de carga de DNS, necesita tener dos FQDN: el FQDN normal del grupo que usa el equilibrio de carga de DNS (como, por ejemplo, pool01.contoso.com) y que se resuelve en las IP físicas de los servidores del grupo, y otro FQDN para los servicios web del grupo (como, por ejemplo, web01.contoso.com), que se resuelve como la dirección IP virtual del grupo.

    En el Generador de topologías, si desea implementar el equilibrio de carga de DNS en un grupo, para crear este FQDN adicional para los servicios web del grupo, necesita activar la casilla Reemplazar el FQDN del grupo de servicios web internos y escribir el FQDN en la página Especificar las direcciones URL de los servicios web de este grupo .

  • Para admitir el FQDN que usa el equilibrio de carga de DNS, necesita aprovisionar el DNS, de modo que resuelva el FQDN del grupo (como, por ejemplo, pool01.contoso.com) en las direcciones IP de todos los servidores del grupo (por ejemplo, 192.168.1.1, 192.168.1.2, etc.). Necesita incluir solo las direcciones IP de los servidores implementados actualmente.

    warningAdvertencia:
    Si tiene más de un Grupo de servidores front-end o Servidor front-end, el FQDN de los servicios web externos tiene que ser único. Por ejemplo, si define el FQDN de los servicios web externos de un Servidor front-end como pool01.contoso.com , no puede usar pool01.contoso.com para otro Grupo de servidores front-end o Servidor front-end. Si también está implementando Directores, el FQDN de los servicios web externos definidos para cualquier Director o Grupo de directores necesita ser diferente de cualquier otro Director o Grupo de directores, al igual que cualquier otro Grupo de servidores front-end o Servidor front-end. Si decide omitir los servicios web internos con un FQDN autodefinido, cada FQDN tiene que ser diferente de cualquier otro Grupo de servidores front-end, Director o Grupo de directores.

Puede implementar el equilibrio de carga de DNS en grupos de servidores perimetrales. Si lo hace, necesita tener en cuenta varias consideraciones.

El uso del equilibrio de carga de DNS en los servidores perimetrales provoca una pérdida en la capacidad de conmutación por error, en los siguientes escenarios:

  • Federación con organizaciones que ejecutan versiones de Skype Empresarial Server anteriores a Lync Server 2010.

  • Intercambio de mensajes instantáneos con usuarios de servicios de mensajería instantánea (MI) pública, como AOL y Yahoo!, además de servidores y proveedores basados en XMPP, como Google Talk, que actualmente es el único socio XMPP admitido.

Estos escenarios funcionarán siempre que se ejecuten correctamente todos los servidores perimetrales del grupo pero, si un servidor perimetral no está disponible, fallarán todas las solicitudes de estos escenarios que se envíen a él, en lugar de redirigirse a otro servidor perimetral.

Si usa la mensajería unificada de Exchange, necesita utilizar como mínimo Exchange 2013 para obtener compatibilidad con el equilibrio de carga de DNS de Skype Empresarial Server en los servidores perimetrales. Si usa alguna versión anterior de Exchange, los usuarios remotos no tendrán capacidades de conmutación por error para estos escenarios de mensajería unificada de Exchange:

  • Reproducir el correo de voz de Enterprise en el teléfono

  • Transferir llamadas de un operador automático de la mensajería unificada de Exchange

Todos los demás escenarios de la mensajería unificada de Exchange funcionarán correctamente.

La interfaz perimetral interna y la interfaz perimetral externa necesitan usar el mismo tipo de equilibrio de carga. No puede usar equilibrio de carga de DNS en una interfaz perimetral y equilibrio de carga de hardware en la otra interfaz perimetral.

Para implementar el equilibrio de carga de DNS en la interfaz externa del grupo de servidores perimetrales, necesita las siguientes entradas de DNS:

  • Para el servicio perimetral de acceso, necesita una entrada por cada servidor del grupo. Cada entrada necesita resolver el FQDN del servicio perimetral de acceso (por ejemplo, sip.contoso.com) en la dirección IP del servicio perimetral de acceso de uno de los servidores perimetrales del grupo.

  • Para el servicio perimetral de conferencia web, necesita una entrada por cada servidor del grupo. Cada entrada necesita resolver el FQDN del servicio perimetral de conferencia web (por ejemplo, webconf.contoso.com) en la dirección IP del servicio perimetral de conferencia web de uno de los servidores perimetrales del grupo.

  • Para el servicio perimetral de audio y vídeo, necesita una entrada por cada servidor del grupo. Cada entrada necesita resolver el FQDN del servicio perimetral de audio y vídeo (por ejemplo, av.contoso.com) en la dirección IP del servicio perimetral de audio y vídeo de uno de los servidores perimetrales del grupo.

Para implementar el equilibrio de carga de DNS en la interfaz interna del grupo de servidores perimetrales, necesita agregar un registro A de DNS que resuelva el FQDN interno del grupo de servidores perimetrales en la dirección IP de cada servidor del grupo.

Puede usar el equilibrio de carga de DNS en grupos de servidores de mediación independientes. Todo el tráfico de medios y SIP se equilibra con el equilibrio de carga de DNS.

Para implementar el equilibrio de carga de DNS en un grupo de servidores de mediación, necesita aprovisionar el DNS, de modo que resuelva el FQDN del grupo (por ejemplo, mediationpool1.contoso.com) en las direcciones IP de todos los servidores del grupo (por ejemplo, 192.168.1.1, 192.168.1.2, etc.).

Si utiliza el equilibrio de carga de DNS y necesita bloquear el tráfico a un equipo específico, no es suficiente con solo quitar las entradas de direcciones IP del grupo FQDN. También necesita quitar la entrada de DNS para el equipo.

Tenga en cuenta que para el tráfico de servidor a servidor, Skype Empresarial Server usa el equilibrio de carga preparado para la topología. Los servidores leen la topología publicada en el Almacén de administración central para obtener los FQDN de los servidores en la topología y distribuyen automáticamente el tráfico entre los servidores. Para bloquear un servidor para que no reciba tráfico de servidor a servidor, necesita quitar el servidor de la topología.

 
Mostrar: