Equilibrio de carga en Exchange Server

El equilibrio de carga en Exchange 2016 y versiones posteriores se basa en la plataforma de alta disponibilidad y resistencia de red de Microsoft que se entrega en Exchange 2013. Cuando esto se combina con la disponibilidad de soluciones de equilibrio de carga de terceros (hardware y software), hay varias opciones para implementar el equilibrio de carga en la organización de Exchange.

Los cambios de arquitectura de Exchange introducidos en Exchange 2013 dieron lugar a los roles de servidor de buzón de correo y servidor de acceso de cliente. Compárelo con Exchange 2010, donde el acceso de cliente, el buzón, el transporte del concentrador y los mensajes unificados se ejecutaron en servidores independientes.

Con roles de servidor mínimos, Exchange 2016 y 2019 ofrece lo siguiente:

• Implementación simplificada con el servidor de buzones que ejecuta servicios de acceso de cliente y roles de servidor de transporte perimetral.

• Flujo de correo administrado en la canalización de transporte, que es la colección de servicios, conexiones, colas y componentes que enrutan los mensajes al categorizador del servicio de transporte en el servidor de buzones.

• Alta disponibilidad mediante la implementación de equilibradores de carga para distribuir el tráfico de cliente.

El estándar de protocolo HTTP introducido con Exchange 2013 significa que la afinidad de sesión ya no es necesaria en Exchange 2016 y Exchange 2019. La afinidad de sesión permite una conexión persistente para servicios habilitados para mensajería para que un usuario no tenga que volver a escribir su nombre de usuario y contraseña varias veces.

Anteriormente, Exchange 2007 y Exchange 2010 admitía RPC a través de HTTP para Outlook en cualquier lugar. Exchange 2013 introdujo MAPI a través de HTTP, aunque no estaba habilitado de forma predeterminada. Ahora está habilitado de forma predeterminada en Exchange 2016 y Exchange 2019.

Con el protocolo HTTP en uso, todos los clientes nativos se conectan mediante HTTP y HTTP en Exchange Server. Este protocolo estándar elimina la necesidad de afinidad, que anteriormente era necesaria para evitar una nueva solicitud de credenciales de usuario cada vez que el equilibrio de carga redirijaba la conexión a otro servidor.

Roles de servidor en Exchange Server

El número reducido de roles de servidor para Exchange 2016 y Exchange 2019 simplifica los requisitos de hardware y implementación de Exchange. El número de roles de servidor en Exchange 2016 y 2019 se reduce de siete a dos: el servidor de buzones y el servidor de transporte perimetral. El rol de servidor Buzón incluye servicios de acceso de cliente, mientras que el servidor de transporte perimetral proporciona un flujo de correo seguro en Exchange 2016 y Exchange 2019, igual que en versiones anteriores de Exchange.

En Exchange 2013, el rol de servidor de acceso de cliente se aseguró de que, cuando un usuario intentara acceder a su buzón, el servidor devolvía la solicitud al servidor de buzón de correo que atiende activamente el buzón del usuario. Esto significaba que servicios como Outlook en la Web (anteriormente conocidos como Outlook Web App) se representaban para el usuario en el propio buzón de correo, lo que eliminaba cualquier necesidad de afinidad.

La misma funcionalidad permanece en Exchange 2016 y Exchange 2019. Si dos servidores de buzones de correo hospedan buzones diferentes, pueden proxy del tráfico entre sí cuando sea necesario. El servidor de buzón de correo que hospeda la copia activa del buzón sirve al usuario que accede a él, incluso si el usuario se conecta a otro servidor de buzones.

Obtenga más información sobre los cambios de rol de servidor en Exchange Server en el artículo, Exchange Server arquitectura.

Aunque no es necesario, el servidor de transporte perimetral se encuentra en la red perimetral, como en versiones anteriores de Exchange, para proporcionar un flujo de correo entrante y saliente seguro para su organización de Exchange.

Obtenga más información sobre el servicio de transporte en el artículo Descripción del servicio de transporte en servidores de transporte perimetral.

Protocolos en Exchange Server

A partir de Exchange 2016, todos los clientes nativos de Exchange usan el protocolo HTTP para conectarse a un servicio designado, con cookies HTTP proporcionadas al usuario al iniciar sesión que se cifran mediante el certificado SSL de servicios de acceso de cliente. Un usuario que ha iniciado sesión puede reanudar la sesión en un servidor de buzón de correo diferente que ejecuta servicios de acceso de cliente sin volver a autenticarse. Los servidores que usan el mismo certificado SSL pueden descifrar la cookie de autenticación de cliente.

HTTP hace posible el uso de comprobaciones de estado de servicio o de aplicación en la red de Exchange. En función de la solución del equilibrador de carga, puede implementar sondeos de estado para comprobar los distintos componentes del sistema.

El efecto del acceso solo HTTP para los clientes es que el equilibrio de carga también es más sencillo. Si lo desea, podría usar DNS para equilibrar la carga del tráfico de Exchange. Proporcionaría al cliente la dirección IP de cada servidor de buzones de correo y el cliente HTTP controlaría las tareas. Si se produce un error en un servidor exchange, el protocolo intenta conectarse a otro servidor. Sin embargo, hay inconvenientes en el equilibrio de carga con DNS, que se describen en la siguiente sección Opciones de equilibrio de carga en Exchange Server.

Obtenga más información sobre HTTP y Exchange Server en el artículo MAPI sobre HTTP en Exchange Server.

Opciones de equilibrio de carga en Exchange Server

En el ejemplo que se muestra aquí, varios servidores configurados en un grupo de disponibilidad de base de datos (DAG) hospedan los servidores de buzones que ejecutan servicios de acceso de cliente. Esto proporciona alta disponibilidad con una pequeña superficie de servidor de Exchange. El cliente se conecta al equilibrador de carga en lugar de directamente a los servidores de Exchange. No hay ningún requisito para los pares de equilibrador de carga, pero se recomienda implementar en clústeres para mejorar la resistencia de la red.

Tenga en cuenta que los DAG usan Microsoft Clustering Services. Estos servicios no se pueden habilitar en el mismo servidor que el equilibrio de carga de red (NLB) de Windows. En consecuencia, Windows NLB no es una opción al usar DAG. En este caso, hay soluciones de software y aplicación virtual de terceros.

El uso de DNS es la opción más sencilla para equilibrar la carga del tráfico de Exchange. Con el equilibrio de carga de DNS, solo tiene que proporcionar a los clientes la dirección IP de cada servidor de buzones de correo. Después de eso, el round robin de DNS distribuye ese tráfico a los servidores de buzones de correo. El cliente HTTP es lo suficientemente inteligente como para conectarse a otro servidor en caso de que un servidor de Exchange produzca un error completo.

La simplicidad tiene un precio; sin embargo, en este caso, el round robin de DNS no equilibra realmente la carga del tráfico, ya que no hay una manera mediante programación de asegurarse de que cada servidor obtiene una parte justa del tráfico. Además, no hay supervisión de nivel de servicio para que, cuando se produce un error en un único servicio, los clientes no se redirijan automáticamente a un servicio disponible. Por ejemplo, si Outlook en la Web está en modo de error, los clientes verán una página de error.

El equilibrio de carga de DNS requiere más direcciones IP externas al publicar externamente. Esto significa que cada servidor exchange individual de su organización requeriría una dirección IP externa.

Hay soluciones más elegantes para equilibrar la carga del tráfico, como el hardware que usa la capa de transporte 4 o la capa de aplicación 7 para ayudar a distribuir el tráfico del cliente. Los equilibradores de carga supervisan cada servicio orientado al cliente de Exchange y, si se produce un error de servicio, los equilibradores de carga pueden dirigir el tráfico a otro servidor y desconectar el servidor problemático. Además, algún nivel de distribución de carga garantiza que ningún servidor de buzón de correo esté proxy de la mayoría del acceso de cliente.

Los servicios de equilibrio de carga pueden usar la capa 4 o la capa 7, o una combinación, para administrar el tráfico. Cada solución tiene ventajas e inconvenientes.

• Los equilibradores de carga de nivel 4 funcionan en la capa de transporte para dirigir el tráfico sin examinar el contenido.

  Dado que no examinan el contenido del tráfico, los equilibradores de carga de nivel 4 ahorran tiempo en tránsito. Sin embargo, esto viene con inconvenientes. Los equilibradores de carga de nivel 4 solo conocen la dirección IP, el protocolo y el puerto TCP. Sabiendo solo una sola dirección IP, el equilibrador de carga solo puede supervisar un único servicio.

  Las ventajas del equilibrio de carga de nivel 4 incluyen:

  • Requiere menos recursos (sin examen de contenido).

  • Distribuye el tráfico en la capa de transporte.

    El riesgo con una solución de nivel 4 es que si se produce un error en un servicio pero el servidor sigue estando disponible, los clientes pueden conectarse al servicio con errores. Esto significa que una implementación resistente de nivel 4 requiere varias direcciones IP configuradas con espacios de nombres HTTP independientes por servicio, por ejemplo, owa.contoso.com, eas.contoso.com, mapi.contoso.com, lo que permite la supervisión de nivel de servicio.

• Los equilibradores de carga de nivel 7 funcionan en el nivel de aplicación y pueden inspeccionar el contenido del tráfico y dirigirlo en consecuencia.

  Los equilibradores de carga de nivel 7 renuncian a las ventajas de rendimiento sin procesar del equilibrio de carga de nivel 4 por la simplicidad de un solo espacio de nombres, por ejemplo, mail.contoso.com y supervisión por servicio. Los equilibradores de carga de nivel 7 comprenden la ruta de acceso HTTP, como /owa o /Microsoft-Server-ActiveSync, o /mapi, y pueden dirigir el tráfico a los servidores de trabajo en función de los datos de supervisión.

  Entre las ventajas del equilibrio de carga de nivel 7 se incluyen:

  • Solo necesita una sola dirección IP.

  • Inspecciona el contenido y puede dirigir el tráfico.

  • Proporciona una notificación del servicio con errores que se puede desconectar.

  • Controla la terminación SSL del equilibrador de carga.

  • Distribuye el tráfico en la capa de aplicación y comprende la dirección URL de destino.

SSL debe finalizar en el equilibrador de carga, ya que ofrece un lugar centralizado para corregir ataques SSL.

Los puertos que deben tener equilibrio de carga incluyen algunos, como los de IMAP4 o POP3, que ni siquiera se pueden usar en la organización de Exchange.

Escenarios de implementación de equilibrio de carga en Exchange Server

Exchange 2016 introdujo una flexibilidad significativa para el espacio de nombres y la arquitectura de equilibrio de carga. Con muchas opciones para implementar el equilibrio de carga en su organización de Exchange, desde dns simple hasta sofisticadas soluciones de nivel 4 y 7 de terceros, se recomienda revisarlas todas teniendo en cuenta las necesidades de su organización.

Los siguientes escenarios incluyen ventajas y limitaciones, y comprender cada uno de ellos es clave para implementar la solución que mejor se adapte a su organización de Exchange:

• Escenario A Espacio de nombres único, sin afinidad de sesión: capa 4 o capa 7

• Escenario B Espacio de nombres único, sin afinidad de sesión: capa 7

• Escenario C Espacio de nombres único con afinidad de sesión, capa 7

• Escenario D Varios espacios de nombres y sin afinidad de sesión, capa 4

Escenario A Espacio de nombres único, sin afinidad de sesión: capa 4 o capa 7

En este escenario de nivel 4, se implementa un único espacio de nombres, mail.contoso.com, para los clientes de protocolo HTTP. El equilibrador de carga no mantiene la afinidad de sesión. Dado que se trata de una solución de nivel 4, el equilibrador de carga está configurado para comprobar el estado de un solo directorio virtual, ya que no puede distinguir Outlook en la Web solicitudes de solicitudes RPC.

Desde la perspectiva del equilibrador de carga de este ejemplo, el estado es por servidor y no por protocolo para el espacio de nombres designado. Los administradores tendrán que elegir el directorio virtual al que quieren dirigirse para el sondeo de estado; se recomienda elegir un directorio virtual muy utilizado. Por ejemplo, si la mayoría de los usuarios usan Outlook en la Web, elija el directorio virtual Outlook en la Web en el sondeo de estado.

Siempre que la respuesta del sondeo de estado de Outlook en la Web sea correcta, el equilibrador de carga mantiene el servidor de buzones de correo de destino en el grupo de equilibrio de carga. Sin embargo, si se produce un error en el sondeo de estado de Outlook en la Web por cualquier motivo, el equilibrador de carga quita el servidor de buzones de correo de destino del grupo de equilibrio de carga para todas las solicitudes asociadas a ese espacio de nombres. Esto significa que si se produce un error en el sondeo de estado, todas las solicitudes de cliente para ese espacio de nombres se dirigen a otro servidor, independientemente del protocolo.

Escenario B Espacio de nombres único, sin afinidad de sesión: capa 7

En este escenario de nivel 7, se implementa un único espacio de nombres, mail.contoso.com, para todos los clientes de protocolo HTTP. El equilibrador de carga no mantiene la afinidad de sesión. Puesto que el equilibrador de carga está configurado para la capa 7, hay terminación SSL y el equilibrador de carga conoce la dirección URL de destino.

Se recomienda esta configuración para Exchange 2016 y Exchange 2019. El equilibrador de carga está configurado para comprobar el estado de los servidores de buzones de correo de destino en el grupo de equilibrio de carga y se configura un sondeo de estado en cada directorio virtual.

Por ejemplo, siempre que la respuesta del sondeo de estado de Outlook en la Web sea correcta, el equilibrador de carga mantendrá el servidor de buzones de correo de destino en el grupo de equilibrio de carga de Outlook en la Web. Sin embargo, si se produce un error en el sondeo de estado de Outlook en la Web por algún motivo, el equilibrador de carga quita el servidor de buzones de correo de destino del grupo de equilibrio de carga para Outlook en la Web solicitudes. En este ejemplo, el estado es por protocolo, lo que significa que, si se produce un error en el sondeo de estado, solo se dirige el protocolo de cliente afectado a otro servidor.

Escenario C Espacio de nombres único con afinidad de sesión, capa 7

En este escenario de nivel 7, se implementa un único espacio de nombres, mail.contoso.com, para todos los clientes de protocolo HTTP. Dado que el equilibrador de carga está configurado para la capa 7, hay terminación SSL y el equilibrador de carga conoce la dirección URL de destino. El equilibrador de carga también está configurado para comprobar el estado de los servidores de buzones de correo de destino en el grupo de equilibrio de carga. El sondeo de estado se configura en cada directorio virtual.

Sin embargo, la habilitación de la afinidad de sesión reduce la capacidad y el uso. Esto se debe a que las opciones de afinidad más implicadas, el equilibrio de carga basado en cookies o el identificador de sesión de capa de sockets seguros (SSL) requieren más procesamiento y recursos. Se recomienda consultar con el proveedor cómo afecta la afinidad de sesión a la escalabilidad del equilibrio de carga.

Como en el escenario anterior, siempre y cuando la respuesta del sondeo de estado de Outlook en la Web sea correcta, el equilibrador de carga mantiene el servidor de buzones de correo de destino en el grupo de equilibrio de carga Outlook en la Web. Sin embargo, si se produce un error en el sondeo de estado de Outlook en la Web por algún motivo, el equilibrador de carga quita el servidor de buzones de correo de destino del grupo de equilibrio de carga para Outlook en la Web solicitudes. Aquí, el estado es por protocolo, lo que significa que, si se produce un error en el sondeo de estado, solo se dirige el protocolo de cliente afectado a otro servidor.

Escenario D Varios espacios de nombres y sin afinidad de sesión

Este último escenario con varios espacios de nombres y sin afinidad de sesión ofrece comprobaciones de estado por protocolo y potencia de nivel 4. Se implementa un espacio de nombres único para cada cliente de protocolo HTTP. Por ejemplo, configuraría los clientes de protocolo HTTP como mail.contoso.com, mapi.contoso.com y eas.contoso.com.

Este escenario proporciona la comprobación de estado por protocolo sin necesidad de una lógica compleja de equilibrio de carga. El equilibrador de carga usa la capa 4 y no está configurado para mantener la afinidad de sesión. La configuración del equilibrador de carga comprueba el estado de los servidores de buzón de destino en el grupo de equilibrio de carga. En esta configuración, los sondeos de estado están configurados para tener como destino el estado de cada directorio virtual, ya que cada directorio virtual tiene un espacio de nombres único. Dado que está configurado para la capa 4, el equilibrador de carga no sabe que se está accediendo a la dirección URL, pero el resultado es como si lo supiera. Dado que el estado es por protocolo, si se produce un error en el sondeo de estado, solo se dirige el protocolo de cliente afectado a otro servidor.

Equilibrio de carga y disponibilidad administrada en Exchange Server

La supervisión de los servidores y servicios disponibles es clave para las redes de alta disponibilidad. Dado que algunas soluciones de equilibrio de carga no tienen conocimiento de la dirección URL de destino ni del contenido de la solicitud, esto puede introducir complejidades para los sondeos de estado de Exchange.

Exchange 2016 y Exchange 2019 incluyen una solución de supervisión integrada, conocida como Disponibilidad administrada. La disponibilidad administrada, también conocida como Supervisión activa o Supervisión activa local, es la integración de acciones integradas de supervisión y recuperación con la plataforma de alta disponibilidad de Exchange.

Disponibilidad administrada incluye un respondedor sin conexión. Cuando se invoca el respondedor sin conexión, el protocolo (o servidor) afectado se quita del servicio.

Para asegurarse de que los equilibradores de carga no enrutan el tráfico a un servidor de buzón de correo que la disponibilidad administrada ha marcado como sin conexión, los sondeos de estado del equilibrador de carga deben configurarse para comprobar <virtualdirectory>/healthcheck.htm, por ejemplo, <https://mail.contoso.com/owa/healthcheck.htm>.

Obtenga más información sobre la disponibilidad administrada en Disponibilidad administrada.