Descripción del equilibrio de carga y la conmutación por error de SMTP en el transporte

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2016-11-28

Cuando existen varios servidores de transporte de concentradores en su organización, Exchange automáticamente distribuye el tráfico de correo entre todos los servidores de transporte de concentradores de ésta. La carga se logra distribuir de modo parejo cuando todos los servidores están disponibles. No obstante, cuando uno o varios servidores no están disponibles, la distribución de la carga entre los servidores restantes puede resultar despareja, en especial si la organización está distribuida entre varios sitios de Active Directory.

En Microsoft Exchange Server 2010 Service Pack 1 (SP1), se han realizado varias mejoras al mecanismo de toma de decisiones para la distribución de la carga entre servidores Transporte de concentradores.

¿Está buscando tareas de administración relacionadas con el enrutamiento de mensajes? Consulte Administración de enrutamiento de mensajes.

Contenido

Comportamiento de Exchange Server 2010 RTM

Mejoras en Exchange 2010 SP1

Equilibrio de carga de red de Windows o Soluciones de equilibrio de carga de terceros con servidores de Transporte

Comportamiento de Exchange Server 2010 RTM

En la versión RTM (de lanzamiento) de Exchange 2010, cuando un servidor de transporte de concentradores necesita redirigir varios mensajes al mismo destino, en primer lugar el servidor determina el siguiente salto para esos mensajes. Si existen varios servidores de destino para ese salto, equilibra la carga de la conexión utilizada para entregar mensajes de manera pareja entre todos los servidores de destino, mediante el modo round robin que proporciona el Sistema de nombres de dominio (DNS) mejorado. Por ejemplo, considere una topología en la que tiene dos sitios de Active Directory con tres servidores de transporte de concentradores en cada uno (tal como lo indica la siguiente imagen). Cuando un servidor de transporte de concentradores del sitio A, como el Hub02, necesita enviar mensajes al sitio B, el siguiente salto para dicho mensaje es el sitio B. Existen tres destinos posibles en el siguiente salto: Hub04, Hub05 y Hub06. El servidor distribuirá la cantidad de conexiones de manera pareja entre los tres destinos, tal como se muestra en la siguiente figura. Esta acción provoca una distribución pareja de los mensajes entre las conexiones con el paso del tiempo.

Equilibrio de cargas en Exchange Server 2010 RTM

De manera similar, los servidores de transporte de concentradores del sitio B distribuirán la cantidad de mensajes enviados a los destinatarios del sitio A de manera pareja entre Hub01, Hub02 y Hub03. Además, dado que Edge01 está suscripto al sitio A, los destinos del siguiente salto para los mensajes enviados a Internet son Hub01, Hub02 y Hub03.

Se produce un problema si al menos uno de los servidores no está disponible en el siguiente salto. Por ejemplo, supongamos que Hub04 del sitio B no está disponible debido a tareas de mantenimiento programadas. Los servidores del sitio A no mantienen el estado de disponibilidad de cada servidor del sitio B. Los servidores del sitio A distribuirán la carga destinada al sitio B entre los tres servidores de transporte de concentradores de ese sitio. No obstante, aproximadamente un tercio de esas conexiones se enviarían a Hub04 y no serían correctas. Estas conexiones realizarán la conmutación por error al siguiente servidor disponible y uno de los servidores de transporte de concentradores del sitio B procesará mucho más carga que el otro servidor, tal como lo muestra la siguiente figura.

Desequilibrio en la carga

Este comportamiento no deseable puede tener lugar siempre que haya un servidor no disponible en el siguiente salto que normalmente tiene más de dos destinos. El siguiente salto podría ser otro sitio de Active Directory, como se muestra en el ejemplo anterior, o un conector que tenga varios servidores de transporte de concentradores en la lista de servidores de origen (por ejemplo, el conector de envío al servidor de transporte perimetral suscripto, dentro de la topología indicada en las figuras anteriores).

Esto no es un problema para la entrega de correo desde los servidores de buzones. El servicio de entrega de correo detectará los servidores de transporte de concentradores que no estén disponibles en un sitio y no intentará realizar entregas a dichos servidores. En el ejemplo indicado anteriormente, si bien uno de los servidores de transporte de concentradores del sito B puede tener una mayor carga de tráfico entre sitios, la carga generada por los servidores de buzones del sitio B se distribuirá de forma pareja entre Hub05 y Hub06.

Comportamiento de Exchange Server 2010 RTM

Mejoras en Exchange 2010 SP1

Para atender al problema descripto en la sección anterior, en Exchange 2010 SP1 se agregó un nuevo componente, llamado Selector de servidores en buen estado. El Selector de servidores en buen estado mantiene una lista de los servidores que no están disponibles. DNS mejorado utiliza esta lista para filtrar todos los servidores que no estén disponibles al aplicar la lógica round robin para el equilibrio de carga. Para demostrar de qué manera el Selector de servidores en buen estado le ayuda en el equilibrio de la carga, analice la condición problemática ilustrada en la figura anterior. En Exchange 2010 SP1, DNS mejorado compilará, en primer lugar, la lista de destinos potenciales en el siguiente salto, el sitio B. A continuación, solicitará al Selector de servidores en buen estado que filtre la lista. El Selector de servidores en buen estado informará que el servidor Hub04 del siguiente salto del sitio B no está en buen estado. DNS mejorado quitará a Hub04 de la lista de destinos potenciales para el siguiente salto del sitio B y usará el equilibrio de carga round robin únicamente entre Hub05 y Hub06, como lo ilustra la siguiente figura.

Equilibrio de carga con el Selector de servidores en buen estado

Selector de servidores en buen estado

En su forma más sencilla, el Selector de servidores en buen estado monitorea los servidores considerados en mal estado, para que no se incluyan en el equilibrio de carga round robin. Desde la perspectiva del Selector de servidores en buen estado, un servidor en mal estado se define como aquel que, ante un intento de conexión, devuelve cualquier código de error de Windows socket (Winsock).

Para cada servidor en mal estado, el Selector de servidores en buen estado mantiene la siguiente información:

• Dirección IP del servidor

• Número de reintentos

• Hora del último reintento

Comportamiento de reintentos

Cuando un servidor se marca como en mal estado, el Selector de servidores en buen estado se asegura de que se vuelva a intentar establecer las conexiones con ese servidor específico, para detectar cuando se conecta. El Selector de servidores en buen estado usa la siguiente configuración para determinar con cuánta frecuencia se volverá a intentar establecer las conexiones con un servidor en mal estado:

• QueueGlitchRetryInterval y QueueGlitchRetryCount   Estas opciones determinan cuántas veces y con qué intervalo el Selector de servidores en buen estado vuelve a intentar establecer la conexión con un servidor específico, cuando éste está marcado como en mal estado. Estas opciones se configuran en el archivo EdgeTransport.exe.config. Los valores predeterminados para ellas son 1 minuto y 4 reintentos. Estos valores indican que, en una configuración predeterminada, se volverá a intentar establecer conexión con un servidor en mal estado una vez por minuto, en cuatro oportunidades.

• TransientFailureRetryInterval y TransientFailureRetryCount   Si el servidor en mal estado no está disponible, el Selector de servidores en buen estado usa estas opciones para determinar la frecuencia del siguiente grupo de reintentos. Estas opciones se configuran para cada servidor de transporte. Los valores predeterminados son 5 minutos (10 minutos en un servidor de transporte perimetral) y 6 reintentos. Estos valores indican que, en una configuración predeterminada, se volverá a intentar establecer conexión con un servidor en mal estado cada cinco minutos, en seis oportunidades, después de transcurridos los primeros cuatro minutos.

• OutboundConnectionFailureRetryInterval   Si el servidor en mal estado no está disponible, el Selector de servidores en buen estado continuará intentando volver a establecer la conexión, con la frecuencia que indique este parámetro. Esta opción se configura para cada servidor de transporte. El valor predeterminado es de 10 minutos (30 minutos para un servidor de transporte perimetral). Esto indica que, en una configuración predeterminada, se volverá a intentar establecer conexión con un servidor en mal estado cada diez minutos, después de transcurridos los primeros 34 minutos.

Para obtener instrucciones detalladas acerca de cómo configurar estas opciones, consulte Configurar los intervalos de reintento, reenvío y expiración de mensajes.

Cuando sea momento de volver a intentar establecer una conexión, el Selector de servidores en buen estado sólo permitirá un intento de conexión con el servidor en mal estado. Si esa conexión se establece correctamente, el componente saliente de SMTP notificará al Selector de servidores en buen estado que la conexión es correcta. En este punto, el Selector de servidores en buen estado quitará el servidor de la lista de servidores en mal estado.

Selector de servidores en buen estado y redundancia de instantáneas

El componente de la redundancia de instantáneas de transporte incluye una característica de latidos. El latido es una conexión SMTP simple, que se utiliza para consultar el estado de los mensajes que se han enviado previamente al servidor de destino. El Selector de servidores en buen estado no evitará que el administrador de redundancia de instantáneas emita intentos de conexión de latido. Si un servidor tiene mensajes de instantánea que se enviaron a un servidor en mal estado, intentará establecer conexiones de latido con este último. Si se establece una conexión de latido correcta con un servidor en mal estado, el Selector de servidores en buen estado quitará inmediatamente ese servidor de destino de la lista de servidores en mal estado.

Para obtener más información sobre la redundancia de instantáneas y el latido, consulte Descripción de redundancia de instantánea.

Información de diagnóstico

En Exchange 2010 SP1, los registros de conectividad incluyen información de diagnóstico para el Selector de servidores en buen estado y las características de equilibrio de carga mejorado. Cuando el Selector de servidores en buen estado agrega un servidor a la lista de servidores en mal estado, el evento se incluye en el registro de conectividad. Para ubicar este evento, busque la frase MarkedUnhealthy en el registro de conectividad. En la línea que contiene esta frase, puede encontrar la siguiente información:

• Dirección IP del host de destino

• Nombre de dominio completo (FQDN) del host de destino

• Error de Winsock recibido

• Estado: MarkedUnhealthy

• Conteo actual de errores

• Hora del siguiente reintento

En esta entrada, puede identificar la razón del error evaluando el código de error de Winsock. Para obtener una lista completa de los códigos de error de Winsock y sus definiciones, consulte Códigos de error de Windows Sockets.

También puede determinar cuántos intentos de conexión resultaron erróneos y el próximo reintento programado para el servidor de destino, analizando los campos Current Failure Count y Next Retry Time.

Para poder ver esta información de diagnóstico, debe tener habilitado el registro de conectividad de sus servidores de transporte. El registro de conectividad está deshabilitad de forma predeterminada en servidores de transporte de concentradores y servidores de transporte perimetral. Para obtener más información acerca de la configuración del registro de conectividad, consulte Configurar el registro de conectividad.

Comportamiento de Exchange Server 2010 RTM

Equilibrio de carga de red de Windows o Soluciones de equilibrio de carga de terceros con servidores de Transporte

Como se mencionó anteriormente en este tema, Exchange 2010 realiza el equilibrio de carga automáticamente en todo el tráfico de mensajes interno a la organización entre los servidores Transporte perimetral, de transporte de concentradores y Buzón mediante DNS mejorado. No obstante, esta función no cubre el equilibrio de carga de mensajes recibidos de orígenes que no son de Exchange, como servidores de correo externos, soluciones antispam o antivirus de terceros, todo servidor de correo interno fuera de su organización de Exchange, aplicaciones de línea de negocios (LOB) y clientes de correo basados en POP o IMAP.

Si tiene uno o más de estos orígenes de correo, es posible que elija realizar un equilibrio de carga de tráfico SMTP de entrada con un espacio de nombre SMTP unificado (como smtp.contoso.com) que distribuye mensajes de correo electrónico externos en todos los servidores de transporte dentro de la organización. Se admite el equilibrio de carga de red (NLB) de Windows o una solución de equilibrio de carga basado en hardware de otro proveedor. Para obtener una lista de equilibradores de carga comprobados por el proveedor, revisados por Microsoft y que cumplen con los requisitos de Exchange 2010, consulte Implementación de equilibradores de carga de las comunicaciones unificadas de Microsoft.

Equilibrio de carga de mensajes de entrada de Internet entre servidores Transporte perimetral

La situación más común es administrar los mensajes entrantes de Internet. No es necesario implementar una solución de equilibrio de carga para distribuir la carga entre los servidores Transporte perimetral. Puede lograr esto si usa DNS por turnos y registros de intercambio de correo (registros MX) que tengan el mismo valor de preferencia, como se muestra en la siguiente figura.

Equilibrio de carga de mensajes de Internet con DNS por turnos y registros MX

Si elige usar Windows NLB o una solución de equilibrio de cargo de hardware para distribuir mensajes entrantes de Internet, necesita publicar un registro MX único que apunta a su solución de equilibrio de carga. El equilibrador de carga distribuirá los mensajes entrantes a todos los servidores Transporte perimetral enumerados en la configuración, como se muestra en la siguiente figura.

Distribución de mensajes de Internet con una solución de equilibrio de carga

Equilibrio de carga de mensajes que no son de Exchange entre servidores de transporte de concentradores

Exchange 2010 usa conectores de recepción para aceptar mensajes entrantes. De manera predeterminada, cuando un servidor de transporte de concentradores de Exchange 2010 recibe un mensaje de correo electrónico mediante SMTP por el puerto TCP 25, es procesado por el conector de recepción denominado conector de recepción predeterminado.

Cuando un cliente de POP o IMAP envía un mensaje de correo electrónico a un servidor de transporte de concentradores de Exchange 2010, el mensaje se envía mediante el puerto TCP 587 de forma predeterminada. Esto significa que los mensajes de correo electrónico enviados desde clientes POP o IMAP están procesados por un conector de recepción separado denominado conector de recepción de cliente predeterminado.

Si planea colocar una solución de equilibrio de carga frente a sus Servidores de transporte de concentradores, debe crear un conector de recepción para tal fin y asegurarse de que sólo el tráfico procesado por ese conector específico esté sujeto al equilibrio de carga. Esto se puede lograr si se agrega una dirección IP adicional al servidor de transporte de concentradores y se asocia esta dirección IP con el nuevo conector de recepción. Además, la opción Autenticación de Exchange Server debe estar deshabilitada en el conector de recepción para asegurar que el tráfico de Exchange no se enrute por ahí. La siguiente figura muestra una configuración en la que un equilibrador de carga se usa para distribuir mensajes recibidos desde clientes POP3 o IMAP4 y servidores SMTP que no son de Exchange entre dos servidores de transporte de concentradores.

Equilibrio de carga de mensajes que no son de Exchange entre servidores de transporte de concentradores

Equilibrio de carga de red de Windows

Windows NLB es el equilibrador de carga de software más común usado para servidores de Exchange. Existen algunas limitaciones asociadas con la implementación de Windows NLB con los servidores de transporte de concentradores de Exchange 2010:

• Windows NLB no se puede usar en los servidores de Exchange en los que los roles de servidores de transporte de concentradores y de buzón de correo coexisten y el servidor también participa en un grupo de disponibilidad de la base de datos (DAG).

  Esto sucede porque la característica Windows NLB no es compatible con el clúster de conmutación por error Windows. Si se usa un DAG de Exchange 2010 y desea usar Windows NLB, debe ejecutar el rol de servidor de transporte de concentradores y el rol de servidor de buzón de correo en equipos diferentes. Además, Windows NLB afecta el enrutamiento de mensajes cuando el miembro de DAG y el rol de servidor de transporte de concentradores coexisten en el mismo servidor. Para obtener más información, consulte Transporte de concentrador y coexistencia de los roles del servidor de buzones cuando se utiliza DAG.

• No se recomienda poner más de ocho servidores de transporte de concentradores en un arreglo que tiene equilibrio de carga de Windows NLB. Si necesita realizar el equilibrio de carga en más de ocho servidores de transporte de concentradores, debe implementar una solución basada en hardware.

• Windows NLB no detecta las interrupciones de servicio.

  Solamente detecta las interrupciones del servidor por su dirección IP. Si se produce un error en el servicio de transporte de Exchange pero el servidor aún funciona, Windows NLB no detectará el error y seguirá con el enrutamiento de mensajes de correo electrónico entrantes hacia el servidor de transporte de concentradores. Se requiere intervención manual para quitar el servidor de transporte de concentradores que está experimentando la interrupción desde el conjunto de equilibrios de carga.

• La configuración de Windows NLB puede provocar saturación de puerto, que puede saturar las redes.

  Eso sucede porque Windows NLB ha sido diseñado de tal manera que entrega todos los paquetes de cliente entrantes de manera simultánea a todos los puertos de conmutador. Aunque este comportamiento permite que Windows NLB entregue un rendimiento muy alto, puede causar alta ocupación de conmutación.

Para ver los pasos detallados acerca de la configuración de Windows NLB, consulte Configurar el equilibrio de carga de red de Windows para servidores de transporte de concentradores.

Equilibrio de carga de hardware

Si tiene más de ocho servidores de transporte de concentradores para los cuales desea realizar el equilibrio de carga del tráfico de mensajes que no son de Exchange, necesita una solución de equilibrio de carga más escalable. Si bien existen soluciones sólidas de equilibrio de carga de software, una solución de equilibrio de carga de hardware proporciona la máxima capacidad.

A diferencia de Windows NLB, que solamente detecta interrupciones en el servidor por la dirección de IP, un equilibrador de carga de hardware se puede configurar para detectar el error del servicio de transporte de Exchange y puede enrutar los mensajes de correo electrónico entrantes a otros servidores de transporte de concentradores sin ninguna intervención manual.

Para obtener pasos detallados acerca de la configuración de una solución de equilibrio de carga de hardware, consulte Configurar el equilibrio de carga de hardware para servidores de transporte de concentradores.

 © 2010 Microsoft Corporation. Reservados todos los derechos.