Descripción de redundancia de instantánea

Se aplica a: Exchange Server 2010

Última modificación del tema: 2010-01-25

Las estrategias de alta disponibilidad para Exchange se han centrado en la disponibilidad y la capacidad de recuperación de los datos almacenados en las bases de datos de buzones de correo. Si se implementa una solución altamente disponible para los servidores de buzones de correo, los mensajes de correo electrónico no se perderán y se podrán recuperar fácilmente tras un error, una vez que hayan llegado a un buzón.

Sin embargo, estas estrategias no se aplican a los mensajes que están en tránsito. Por ello, si un servidor Transporte de concentradores da error al procesar los mensajes y no se recupera, pueden perderse datos. A medida que aumenta el volumen de mensajes que los servidores de transporte de concentradores procesan, crece también la preocupación de los administradores por una posible pérdida de datos.

Con Microsoft Exchange Server 2007 se incluyó la característica de contenedor de transporte para el rol de servidor Transporte de concentradores. Un servidor Transporte de concentradores de Exchange 2007 conserva una cola de los mensajes enviados recientemente a destinatarios cuyos buzones se encuentran en un servidor de buzones de correo en clúster. Al producirse una conmutación por error, el servidor de buzones de correo en clúster solicita automáticamente a cada servidor Transporte de concentradores del sitio de Active Directory que vuelva a enviar el correo desde la cola de recuperación del elemento eliminado de transporte. De esta forma se evita que se pierdan mensajes mientras el clúster conmuta por error. Si bien es cierto que esto reporta un nivel básico de redundancia del transporte, ésta solo está disponible para la entrega de mensajes en un entorno de replicación continua de clúster (CCR) y no se ocupa de la pérdida de mensajes que podría producirse cuando los mensajes transitan entre los servidores de transporte de concentradores y de transporte perimetral.

Exchange Server 2010 incorpora la característica de redundancia de instantánea para ofrecer redundancia de mensajes durante el tiempo que éstos están en tránsito. La solución implica una técnica similar a la de la recuperación del elemento eliminado de transporte. Con la redundancia de instantánea, la eliminación de un mensaje de las bases de datos de transporte se retrasa hasta que el servidor de transporte confirma que todos los saltos siguientes para ese mensaje han completado la entrega. Si alguno de estos saltos da error antes de notificar que ha completado la entrega, se le vuelve a enviar el mensaje para que lo entregue.

La redundancia de instantánea reporta las siguientes ventajas:

• Elimina la dependencia del estado de cualquier servidor Transporte de concentradores o Transporte perimetral específico, por cuanto se puede hacer uso de cualquier servidor de transporte, siempre y cuando existan rutas de mensaje redundantes en la topología de enrutamiento.
• En caso de que se produzca un error en un servidor de transporte, se puede quitar de la producción sin que sus colas se vacíen o se pierdan mensajes.
• Si desea mejorar un servidor Transporte de concentradores o un servidor Transporte perimetral, puede desconectarlo en cualquier momento sin riesgo alguno de pérdida de mensajes.
• Pone fin a la necesidad de disponer de redundancia de hardware de almacenamiento para los servidores de transporte.
• El consumo de ancho de banda es menor que si se crean copias duplicadas de mensajes en varios servidores. El único tráfico de red adicional que se genera con la redundancia de instantánea es el intercambio de estados de descarte entre servidores de transporte. El estado de descarte es la información que cada servidor de transporte conserva e indica el momento en que un mensaje puede descartarse de la base de datos de transporte.
• Proporciona resistencia y simplifica la recuperación de un error de servidor de transporte.

La redundancia de instantánea se implementa ampliando el servicio SMTP. Estas ampliaciones del servicio permiten que los hosts SMTP negocien la compatibilidad con la redundancia de instantánea e intercambien estados de descarte relativos a los mensajes de instantánea.

¿Está buscando tareas de administración relacionadas con la administración de servidores de transporte? Consulte Administración de servidores de transporte.

Contenido

Componentes de la redundancia de instantánea

Flujo de mensajes con redundancia de instantánea

Administrador de redundancia de instantánea

Procesamiento de mensajes después de una interrupción

Derechos extendidos necesarios para la redundancia de instantánea

Componentes de la redundancia de instantánea

La siguiente tabla recoge descripciones de todos los componentes de redundancia de instantánea.

Componentes de la redundancia de instantánea

Componente	Descripción
Mensaje principal	Mensaje original enviado para su entrega.
Mensaje de instantánea	Copia de un mensaje que un servidor de transporte conserva hasta que confirma que todos los saltos siguientes relativos a dicho mensaje se han llevado a cabo correctamente.
Servidor principal	Servidor de transporte que actualmente procesa un mensaje.
Servidor de instantánea	Servidor de transporte que conserva instantáneas de un mensaje tras entregar dicho mensaje al servidor principal.
Cola de instantáneas	Cola que un servidor de transporte usa para almacenar los mensajes de instantánea. Un servidor de transporte tendrá colas de instantáneas independientes para cada salto al que entregó el mensaje principal.
Estado de descarte	Información relativa a los mensajes de instantánea que un servidor de transporte conserva y que indica cuándo un mensaje se puede descartar.
Notificación de descarte	Respuesta que un servidor de instantáneas recibe de un servidor principal y que indica que un mensaje se puede descartar.
Administrador de redundancia de instantánea	Componente de transporte que administra la redundancia de instantánea.
Latido	Proceso por el cual los servidores de transporte comprueban su disponibilidad entre sí.

Volver al principio

Flujo de mensajes con redundancia de instantánea

A fin de ilustrar el flujo de correo con la redundancia de instantánea habilitada, piense en un sencillo escenario en el que un servidor Transporte de concentradores envía un mensaje a un servidor de correo de terceros a través de un servidor Transporte perimetral en la red perimetral.

Flujo de mensajes con redundancia de instantánea

En este escenario, el flujo de mensajes pasa por las siguientes fases:

1. El servidor Transporte de concentradores entrega un mensaje al servidor Transporte perimetral.
   1. El servidor Transporte de concentradores abre una sesión SMTP con el servidor Transporte perimetral
   2. El servidor Transporte perimetral anuncia la compatibilidad con la redundancia de instantánea.
   3. El servidor Transporte de concentradores notifica al servidor Transporte perimetral que debe realizar un seguimiento del estado de descarte.
   4. El servidor Transporte de concentradores envía el mensaje al servidor Transporte perimetral.
   5. El servidor Transporte perimetral acusa recibo del mensaje y registra el nombre del servidor Transporte de concentradores para enviarle información de descarte sobre el mensaje.
   6. El servidor Transporte de concentradores mueve el mensaje a la cola de instantáneas del servidor Transporte perimetral y marca este último como servidor principal. Por su parte, el servidor Transporte de concentradores se convierte en el servidor de instantánea.
2. El servidor Transporte perimetral entrega el mensaje al siguiente salto.
   1. El servidor Transporte perimetral envía el mensaje a un servidor de correo de terceros.
   2. El servidor de correo de terceros acusa recibo del mensaje.
   3. El servidor Transporte perimetral actualiza el estado de descarte del mensaje para establecerlo como envío completado.
3. El servidor Transporte de concentradores consulta el estado de descarte al servidor Transporte perimetral (proceso correcto).
   1. Al término de cada sesión SMTP con el servidor Transporte perimetral, el servidor Transporte de concentradores consulta al primero el estado de descarte de los mensajes enviados anteriormente. Si el servidor Transporte de concentradores no ha abierto ninguna sesión SMTP con el servidor Transporte perimetral tras el envío de mensaje inicial, cuando haya transcurrido un periodo de tiempo determinado abrirá una sesión SMTP con el servidor Transporte perimetral sólo para consultar el estado de descarte.
   2. El servidor Transporte perimetral comprueba el estado de descarte local, devuelve la lista de mensajes entregados y quita la información de descarte.
   3. El servidor Transporte de concentradores elimina la lista de mensajes de su cola de instantáneas.
4. El servidor Transporte de concentradores consulta el estado de descarte al servidor Transporte perimetral y vuelve a enviar el mensaje (proceso con errores).

   1. En el caso de que el servidor Transporte de concentradores no pueda ponerse en contacto con el servidor Transporte perimetral, reanuda el rol de servidor principal y vuelve a enviar los mensajes que hay en la cola de instantáneas.

   2. Los mensajes reenviados llegan a otro servidor Transporte perimetral y el flujo de trabajo se inicia desde el paso 1.

      Nota

      Si no existen rutas alternativas disponibles para un mensaje de instantánea (como el segundo servidor Transporte perimetral que se muestra en la figura anterior), dicho mensaje no se volverá a enviar pero permanecerá en la cola de instantáneas.

Para obtener más información sobre el flujo de mensajes en distintos escenarios, consulte Casos de flujo de correo con redundancia de instantáneas.

Escenario con varios saltos

Si un mensaje atraviesa varios servidores que admiten la redundancia de instantánea, los mensajes de instantánea se conservarán en un servidor sólo hasta que el siguiente servidor en la ruta del mensaje confirme la entrega. Para entender bien cómo funciona todo esto, imagínese una organización que tiene cinco sitios de Active Directory con servidores de transporte de concentradores instalados. Estos sitios se conectan entre sí tal y como se muestra en la siguiente figura: La organización tiene configurados los sitios de Nueva York y Londres como sitios de concentradores, de modo que los mensajes procedentes de Chicago o Atlanta deben pasar por los servidores de transporte de concentradores de estos dos sitios para llegar al sitio de Dublín.

Topología de ejemplo para un escenario con varios saltos

Imagine que un usuario del sitio de Chicago envía un mensaje a un usuario del sitio de Dublín. El mensaje deberá pasar por los sitios de Nueva York y Londres para llegar a Dublín. En este caso, ocurre lo siguiente:

1. El servidor Transporte de concentradores de Chicago enviará el mensaje al servidor Transporte de concentradores de Nueva York y conservará una copia de instantánea de dicho mensaje.
2. El servidor Transporte de concentradores de Nueva York enviará el mensaje al servidor Transporte de concentradores de Londres y pondrá en cola un estado de descarte para el concentrador de Chicago.
3. El concentrador de Chicago consulta el estado de descarte al concentrador de Nueva York y recibe la notificación de descarte del mensaje. En este momento podrá quitar el mensaje de instantánea de su base de datos. El hecho de que el mensaje haya viajado de Londres a Dublín no determina el momento en que el servidor de Chicago elimina el mensaje de instantánea.

Interoperabilidad

La decisión de usar o no la redundancia de instantánea se toma al establecer una nueva conexión SMTP. Si los dos servidores en una conexión SMTP admiten la redundancia de instantánea, se empleará el flujo de trabajo explicado anteriormente. Sin embargo, habrá situaciones en las que los servidores de transporte de Exchange 2010 intercambien mensajes con servidores de correo que no admiten la redundancia de instantánea (pueden ser servidores de correo de terceros, versiones anteriores de Exchange o una organización de Exchange 2010 que no tiene la redundancia de instantánea habilitada).

Cuando un servidor de transporte de Exchange 2010 que admite la redundancia de instantánea establece una conexión con un servidor que no la admite, sucede lo siguiente:

1. Exchange establece una conexión SMTP con el servidor de destino.
2. El servidor de destino no anuncia la compatibilidad con la redundancia de instantánea.
3. Dado que el servidor de destino no admite la redundancia de instantánea, Exchange realizará las siguientes acciones con cada mensaje:
   1. Entregará el mensaje al servidor de destino.
   2. El administrador de redundancia de instantánea marcará el mensaje como entregado al siguiente salto.
   3. Eliminará el mensaje una vez que se haya entregado a todos los saltos siguientes.

Cuando un servidor que no admite la redundancia de instantánea establece una conexión con un servidor de Exchange 2010, sucede lo siguiente:

1. El servidor de envío establece una conexión SMTP con Exchange.
2. Exchange anuncia la compatibilidad con la redundancia de instantánea.
3. El servidor de envío no admite la redundancia de instantánea, por lo que no la usará. Entregará los mensajes al servidor de Exchange.
4. Con cada mensaje de Exchange que reciba, realizará las siguientes acciones:
   1. Entregará el mensaje al siguiente salto o hará una copia de instantánea de éste.
   2. Enviará un acuse al servidor de envío.

Acuse retrasado

El objetivo último de la redundancia de instantánea es conservar una copia del mensaje en el salto anterior hasta que el servidor confirme que lo ha entregado correctamente al resto de saltos siguientes. Esto no es factible cuando un servidor de transporte de Exchange 2010 recibe un mensaje de un servidor de correo que no admite la redundancia de instantánea. Puede tratarse de un servidor Exchange que ejecuta una versión anterior de Exchange, un cliente SMTP estándar o un servidor de correo que no es Exchange en Internet. En tal caso, Exchange intenta obtener la redundancia de instantánea retrasando el acuse de recibo al servidor de correo hasta que comprueba que el mensaje se ha entregado correctamente al resto de pasos siguientes por vía interna. De esta forma, si se produce un error en el servidor de Exchange 2010, el servidor de correo que realiza el envío dará por hecho que el mensaje nunca llegó a Exchange y tratará de entregarlo de nuevo.

No obstante, la entrega del mensaje a los saltos siguientes puede demorarse mucho debido a la complejidad de la infraestructura de enrutamiento o a un error en uno de los saltos siguientes. En estos casos, y a fin de evitar que se agote el tiempo de espera de la sesión SMTP, el servidor de transporte de Exchange 2010 enviará un acuse de recibo al servidor de correo de envío; esto no garantiza la redundancia del correo pero es la mejor opción (best effort). Por ejemplo, un mensaje se puede perder en el siguiente escenario: un servidor de correo de Internet transmite un mensaje a un servidor Transporte perimetral. Éste no se puede comunicar con el servidor Transporte de concentradores debido a un problema de red y acusa recibo del mensaje al servidor de correo de Internet. A continuación, se produce un error en el servidor Transporte perimetral y no se puede recuperar antes de que el problema de red se resuelva. Es entonces cuando el mensaje se pierde.

Este valor de tiempo de espera de acuse retardado se controla mediante el atributo MaxAcknowledgementDelay de cada conector de recepción. El valor predeterminado es 30 segundos. Para obtener más información sobre cómo configurar este atributo, consulte Configurar redundancia de instantáneas.

Volver al principio

Administrador de redundancia de instantánea

El administrador de redundancia de instantánea es el componente central de un servidor de transporte de Exchange 2010 responsable de administrar la redundancia de instantánea.

El administrador de redundancia de instantánea se encarga de mantener los datos enumerados a continuación de todos los mensajes principales que un servidor procesa actualmente:

• El servidor de instantánea de cada mensaje principal que se está procesando.
• El estado de descarte que se va a enviar a los servidores de instantánea.

El administrador de redundancia de instantánea se ocupa de las siguientes tareas relativas a todos los mensajes de instantánea que un servidor tiene en sus colas de instantáneas:

• Mantener la lista de servidores principales de cada mensaje de instantánea.
• Comprobar la disponibilidad de cada servidor principal para el que hay un mensaje de instantánea en cola.
• Procesar las notificaciones de descarte de los servidores principales.
• Eliminar los mensajes de instantánea de la base de datos una vez que se han recibido todas las notificaciones de descarte previstas.
• Decidir el momento en el que un servidor de instantánea debe hacerse con la propiedad de los mensajes de instantánea y, de este modo, convertirse en un servidor principal.

Además, el administrador de redundancia de instantánea también se encarga de administrar los contadores de rendimiento relativos a la redundancia de instantánea.

Latido

El administrador de redundancia de instantánea usa el latido para saber cuál es la disponibilidad de los servidores para los que hay mensajes de instantánea en cola. En el transcurso de la sesión SMTP entre dos servidores que admiten la redundancia de instantánea, el servidor que inicia la conexión consulta al servidor de destino el estado de descarte de los mensajes que se han enviado previamente a dicho servidor. El servidor que inicia el proceso logra esto emitiendo un comando XQUERYDISCARD. En respuesta, el servidor de destino devuelve las notificaciones de descarte. Este intercambio entre ambos servidores sirve como latido para la redundancia de instantánea.

Existe un valor de tiempo de espera para el latido. Si, durante ese tiempo, no se establece ninguna conexión con un servidor en el que el administrador de redundancia de instantánea conserva una cola de instantáneas, el servidor tratará de establecer una conexión SMTP con el servidor principal nada más que para consultar el estado de descarte y restablecer el temporizador. Este valor de tiempo de espera se controla mediante el parámetro ShadowHeartbeatTimeoutInterval del cmdlet Set-TransportConfig, y está establecido en 300 segundos de forma predeterminada.

Si, al alcanzar el valor de tiempo de espera, el servidor no se ha podido conectar al servidor principal, se restablecerá el temporizador y se realizará otro intento. En caso de que el valor de espera se alcance tres veces consecutivas, el servidor considerará que ha habido un error en el servidor principal, asumirá la propiedad de los mensajes de instantánea y comenzará a generar la notificaciones de descarte correspondientes para enviarlas al servidor principal que ha dado error. El número de veces que un servidor puede agotar el tiempo de espera antes de decidir que existe un error en un servidor principal se controla mediante el parámetro ShadowHeartbeatRetryCount del cmdlet Set-TransportConfig.

Para obtener más información sobre cómo configurar el latido de la redundancia de instantánea, consulte Configurar redundancia de instantáneas.

Volver al principio

Procesamiento de mensajes después de una interrupción

La redundancia de instantánea reduce el riesgo de que un mensaje se pierda a causa de una interrupción del servidor. Cuando un servidor de transporte vuelve a estar operativo tras una interrupción, pueden darse dos escenarios:

• El servidor vuelve a estar operativo con una nueva base de datos de transporte   En este escenario, la base de datos de transporte no se puede recuperar debido a que los datos están dañados o a un error en el hardware. En tal caso, como el servidor de transporte tendrá un nuevo identificador de base de datos, el resto de servidores de transporte de la organización lo identificarán como una nueva ruta. Esto es igualmente aplicable a la situación en la que un servidor no se ha podido recuperar y, por lo tanto, se aprovisiona otro nuevo para sustituirlo.
• El servidor vuelve a conectarse con la misma base de datos de transporte   En este escenario, no se ha producido ningún error en el servidor de transporte específico pero éste ha estado desconectado durante un periodo de tiempo prolongado (a causa, por ejemplo, de un error en la tarjeta de red o un mantenimiento del servidor muy prolongado).

En la siguiente tabla se resume la reacción del transporte en ambos escenarios cuando la redundancia de instantánea está habilitada. Para entenderlo mejor, supongamos que el servidor que ha sufrido una interrupción se llama Hub01.

Procesamiento de mensajes en escenarios de recuperación

Escenario de recuperación	Medidas adoptadas con los mensajes que tienen rutas alternativas	Medidas adoptadas con los mensajes que no tienen rutas alternativas
Hub01 vuelve a estar conectado con una base de datos nueva.	Cuando Hub01 deja de estar disponible, todos los servidores que tienen mensajes de instantánea en cola para Hub01 asumirán la propiedad de dichos mensajes y los volverán a enviar. Gracias a ello, los mensajes llegan a sus destinos por rutas alternativas. El retraso total para mensajes es igual al producto del intervalo de tiempo de espera de latido y el número de reintentos de latido configurado en su organización.	Estos mensajes permanecen en la cola de instantáneas de aquellos servidores que tienen mensajes de instantánea en cola para Hub01. Cuando Hub01 vuelve a estar conectado con un nuevo identificador de base de datos, los servidores de instantánea detectan que hay una nueva base de datos y vuelven a enviar los mensajes que están en la cola de instantáneas para Hub01. Esto equivale a detectar de repente una ruta alternativa para estos mensajes. El retraso total para los mensajes depende de la duración de la interrupción.
Hub01 vuelve a estar conectado con la misma base de datos.	Hub01 entregará los mensajes en sus colas, lo cual provocará que se entreguen por duplicado. Los usuarios de buzón de correo de Exchange no verán los mensajes duplicados gracias a la detección de mensajes duplicados, pero es probable que los destinatarios de sistemas externos sí reciban copias duplicadas. El retraso total para mensajes es igual al producto del intervalo de tiempo de espera de latido y el número de reintentos de latido configurado en su organización.	Hub 01 entregará los mensajes en sus colas y, a continuación, enviará notificaciones de descarte a los servidores de instantánea. El retraso total para los mensajes depende de la duración de la interrupción.

Volver al principio

Derechos extendidos necesarios para la redundancia de instantánea

Exchange 2010 incluye los dos siguientes derechos extendidos, que son necesarios para la redundancia de instantánea:

• ms-Exch-SMTP-Accept-XSHADOW
• ms-Exch-SMTP-Send-XSHADOW

Cuando se establece una conexión SMTP con un servidor de transporte de Exchange 2010, éste anunciará la compatibilidad con la redundancia de instantánea si el conector de recepción que se está usando dispone del derecho extendido ms-Exch-SMTP-Accept-XSHADOW. Asimismo, el mecanismo de autenticación de dicho conector debe ser Autenticación de Exchange Server o Protegido externamente.

Cuando un servidor de transporte de Exchange 2010 establezca una conexión SMTP con otro servidor que anuncia su compatibilidad con la redundancia de instantánea, emitirá un comando XSHADOW únicamente si la sesión disfruta del derecho extendido ms-Exch-SMTP-Send-XSHADOW.

De manera predeterminada, estos derechos extendidos se otorgan al grupo de servidores de Exchange de todos los conectores de envío y recepción internos.

Nota

La redundancia de instantánea se puede habilitar o deshabilitar en toda la organización por medio del parámetro ShadowRedundancyEnabled del cmdlet Set-TransportConfig. Esta configuración reemplaza los derechos extendidos descritos en esta sección. En caso de que la redundancia de instantánea esté deshabilitada en la organización, Exchange nunca anunciará su compatibilidad con la redundancia de instantánea ni emitirá comandos XSHADOW, aun cuando la sesión SMTP cuente con los derechos extendidos pertinentes.

Volver al principio