Preguntas y respuestas sobre ExchangeEquilibrio de carga, transporte perimetral y mucho más

Henrik Walther

P Tenemos implementados varios servidores que ejecutan Microsoft® Office SharePoint® en nuestro entorno de producción corporativo. Cada uno de estos servidores necesita retransmitir los mensajes salientes a través de los servidores Transporte de concentradores (HT) en nuestra infraestructura Exchange Server 2007 recientemente implementada. Puesto que un servidor de SharePoint sólo nos permite especificar el nombre de dominio completo (FQDN) de un solo servidor SMTP (Exchange) en la página Administración Central | Operaciones | Configuración del correo electrónico saliente, tal como se muestra en la Figura 1, me preguntaba cómo podemos eliminar este único punto de posibles errores.

Figura 1 Configuración del correo electrónico saliente en la página Administración central de SharePoint (haga clic en la imagen para ampliarla)

R Es una buena pregunta, ya que muchas organizaciones están centradas en la alta disponibilidad y, por tanto, no aceptan ni un solo punto de error en sus entornos de producción corporativos. Esto es particularmente cierto en lo que se refiere a los servicios de mensajería y colaboración.

Los servidores HT de Exchange 2007 son resistentes de forma predeterminada. Esto es, si tiene más de un servidor HT implementado en un sitio de Active Directory® y algún servidor HT de este sitio de Active Directory no está disponible, el servidor HT de origen que trata de entregar el mensaje pasará al siguiente servidor HT disponible en el sitio de Active Directory. Esto tiene lugar al usar mecanismos DNS por turnos (si el primer servidor HT de la lista no responde, probemos el siguiente).

Así que, en lo que respecta a la comunicación HT a HT y servidor Buzón de correo a HT (esto es, dentro de la organización), no necesitamos preocuparnos de la alta disponibilidad (ni del equilibrio de carga, por tanto), puesto que es una funcionalidad nativa de Exchange 2007. Tenga en cuenta, no obstante, que si instala la función servidor HT en un equipo que también tiene instalada la función del servidor Buzón de correo, la función del servidor Buzón de correo siempre preferirá el servidor HT local por encima de cualquier otro servidor HT en un sitio de Active Directory (incluso si el servidor HT instalado no está disponible) cuando el servicio de entrega de correo de Microsoft Exchange envía los mensajes.

La información anterior no es realmente útil en relación con los servidores de SharePoint, pero es importante saber esto antes de seguir adelante. Puesto que un servidor HT es resistente de forma predeterminada, no se admite el equilibrio de carga de la comunicación dentro de la organización entre servidores HT en Exchange 2007 mediante equilibradores de carga de hardware o mediante la funcionalidad Windows® Network Load Balancing (WNLB).

De hecho, no existía la compatibilidad con el tráfico SMTP entrante de equilibrio de carga a los servidores HT basados en la versión RTM de Exchange 2007. Pero Exchange 2007 SP1 supone un cambio en este sentido. Con SP1, todavía no es posible equilibrar la carga de la comunicación dentro de la organización mediante equilibradores de carga de hardware o mediante la funcionalidad WNLB (y, de todos modos, ¿por qué iba a hacerlo?). No obstante, es posible equilibrar la carga del tráfico SMTP entrante desde orígenes ajenos a Exchange (como servidores de SharePoint) y clientes de Exchange como, por ejemplo, clientes IMAP o POP que envían mensajes salientes a la organización de Exchange 2007 a través del conector de recepción de cliente predeterminado en el servidor HT.

Así que, para configurar un servidor SharePoint con el fin de retransmitir los mensajes a través de una organización de Exchange 2007 SP1, puede crear simplemente un registro DNS en su DNS de Active Directory y dirigirlo a un equilibrador de carga de hardware que pueda, a continuación, distribuirlo entre varios servidores HT, o usar la funcionalidad WNLB. Para usar el último método, configure el clúster WNLB con una dirección IP virtual y un nombre de dominio completo (por ejemplo, mail.contoso.com), y agregue los puertos 25 (tráfico SMTP entrante desde servidores ajenos a Exchange) y 587 (SMTP entrante de clientes de Exchange como IMAP y POP) en la ficha Reglas de puerto. La Figura 2 muestra cómo debería quedar su ficha Reglas de puerto con esta configuración. También querrá asegurarse de que asigna la dirección IP virtual específica de clúster NLB a ambas reglas, en lugar de seleccionar todas las direcciones IP.

Figura 2 Reglas de puerto definidas (haga clic en la imagen para ampliarla)

Una vez que se ha configurado el clúster NLB, necesitará crear un nuevo conector de recepción que deberá estar configurado para escuchar el puerto 25 y admitir solamente los servidores que lo requieran para retransmitir los mensajes con este conector. Además, asegúrese de que este conector use la dirección IP virtual del clúster NLB creada antes.

P Nuestra infraestructura de mensajería está basada en Exchange Server 2007. Para hacer redundantes nuestros servidores de correo de Exchange 2007 en los niveles de hardware y almacenamiento, todos son servidores Buzón de correo en clúster basados en la tecnología de replicación continua en clúster (CCR). Tanto el nodo activo como el pasivo de cada clúster CCR están ubicados en el mismo centro de datos físico. Ahora que hemos actualizado nuestros servidores de Exchange 2007 a SP1, deseamos sacar el máximo partido de la disponibilidad del servicio y los datos mediante la replicación de las bases de datos Buzón de correo a servidores Buzón de correo en una segunda ubicación con la nueva tecnología de replicación continua en espera (SCR) incluida en Exchange 2007 SP1.

Somos conscientes de que los orígenes SCR pueden ser servidores Buzón de correo independientes de Exchange 2007 SP1 o servidores Buzón de correo en clúster (CMS) basados en tecnología CCR o de clúster de copia única (SCC). Pero, ¿y los servidores de destino de SCR?

R Los servidores de destino de SCR (también conocidos como extremos de SCR) deben ser servidores Buzón de correo independientes sin replicación continua local (LCR) habilitados para cualquier grupo de almacenamiento o un nodo pasivo en un clúster de conmutación por error de Windows (anteriormente conocido como Microsoft Cluster Server) con la función de servidor Buzón de correo instalada. Esto significa que puede formar su clúster de conmutación por error y, a continuación, instalar la función de servidor Buzón de correo en un nodo pasivo del clúster de conmutación por error, pero no puede usar un servidor Buzón de correo en clúster como destino de SCR.

P Nuestra organización usa Exchange 2007 como plataforma de mensajería. Incluso hemos decidido reemplazar nuestra antigua solución contra correo electrónico no deseado y antivirus en la red perimetral por una solución basada en servidores Transporte perimetral de Exchange 2007 con Forefront™ Security para Exchange, de forma que podamos beneficiarnos de las varias capas de protección y seguridad para los mensajes. Nuestro plan es implementar al menos dos servidores Transporte perimetral adicionales en un futuro próximo.

Esto lleva a mi pregunta. ¿Cómo podemos equilibrar la carga de las conexiones SMTP entrantes en nuestra solución de limpieza de mensajes basada en transporte perimetral de Exchange 2007 y, por tanto, distribuir la carga y hacerla totalmente redundante?

R Si los servidores Transporte perimetral de su red perimetral son los servidores SMTP dirigidos a Internet, puede usar un enfoque semejante al usado en el grupo Microsoft Information Technology (Microsoft TI). Microsoft TI ha implementado seis servidores Transporte perimetral (tres en Redmond y tres en Silicon Valley) que controlan más de 16 millones mensajes entrantes al día (y más de 13 millones de mensajes se filtran como correo no deseado).

Microsoft TI tiene un total de tres registros de Mail Exchange (MX) para el dominio Microsoft.com. Son los siguientes: maila.microsoft.com, mailb.microsoft.com y mailc.microsoft.com (consulte la Figura 3). Cada registro MX se ha configurado con una preferencia de 10 para que se seleccione de forma aleatoria por medio de una técnica de DNS por turnos. Además, se asocian dos direcciones IP (host de correo) a cada registro de MX.

Figura 3 Registros MX y host de correo de Internet para Microsoft.com (haga clic en la imagen para ampliarla)

¿Por qué dos direcciones IP por cada registro MX? Porque algunos agentes de transferencia de mensajes (MTA) siempre seleccionarán el mismo registro MX, sin importar cuántos registros MX haya configurado para un dominio. Con respecto a Exchange Server, esto no ha sido un problema desde hace muchos años (no desde Exchange 2000) pero, desafortunadamente, aún hay MTA que tienen este error de diseño. Por lo tanto, no importa qué MTA trate de proporcionar un mensaje a una dirección Microsoft.com; todas las conexiones SMTP se distribuyen con una combinación de DNS por turnos y equilibrio de carga.

P Nuestro dominio de Active Directory está basado en controladores de dominio (DC) Windows Server® 2003. Nos encontramos actualmente en la fase de planeación de la transición de nuestros controladores de dominio de Windows Server 2003 a Windows Server 2008 y de nuestro entorno de mensajería Exchange 2003 a Exchange Server 2007. ¿Podemos llevar a cabo la transición de nuestro dominio de Active Directory a Windows Server 2008 actualizando todos los servidores que ejecutan Windows Server 2003 a Windows Server 2008 antes de transferir el entorno de mensajería de Exchange Server 2003 a Exchange 2007?

R Sí, Exchange Server 2003 SP2 es totalmente compatible con un dominio de Active Directory formado totalmente por controladores de dominio de Windows Server 2008, así que puede seguir con su plan. Tenga en cuenta que si planea usar controladores de dominio de sólo lectura (RODC) de Windows Server 2008, no debe configurar el servicio de actualización de destinatarios de Exchange (RUS) para usar un RODC.

Henrik Walther es Microsoft Certified Architect especializado en mensajería. Además, es MVP de Exchange y cuenta con más de 14 años de experiencia en el sector de TI. Trabaja como arquitecto de tecnología para Interprise Consulting y como escritor técnico para Biblioso Corp.

© 2008 Microsoft Corporation y CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.