Redundancia de instantáneas en Exchange Server

SE APLICA A:2016 2019 Edición de suscripción

La redundancia de instantáneas se introdujo en Exchange 2010 para proporcionar copias redundantes de los mensajes antes de que se entreguen a los buzones. En Exchange 2010, la redundancia de instantáneas retrasaba la eliminación de un mensaje de la base de datos de colas en un servidor de transporte de concentradores hasta que el servidor verificaba que el siguiente salto en la ruta de entrega de mensajes había completado la entrega. Si se produjo un error en el próximo salto antes de informar de la entrega correcta al servidor de transporte de concentradores, el servidor vuelve a enviar el mensaje a ese próximo salto. Los servidores de transporte concentradores de Exchange 2010 usaban el verbo XSHADOW para anunciar su compatibilidad con la redundancia de instantáneas. Si un servidor de mensajería de origen no admite la redundancia de instantáneas, Exchange 2010 usa la confirmación retrasada en función de un intervalo de tiempo configurado en el conector de recepción para realizar una copia redundante del mensaje.

Exchange 2016 y Exchange 2019 tienen las mismas mejoras que se realizaron en la redundancia de instantáneas en Exchange 2013: el servicio de transporte de un servidor de buzones de correo ahora realiza una copia redundante de cualquier mensaje que reciba antes de confirmar la recepción del mensaje en el servidor de envío. Mantener copias redundantes de los mensajes en tránsito es más que un mejor esfuerzo que puede funcionar o no, porque ahora la redundancia de instantáneas no depende de las características admitidas por el servidor de envío (el soporte o la falta de soporte para la redundancia de instantáneas no importa). Esto ayuda a garantizar que todos los mensajes de la canalización de transporte se hagan redundantes mientras están en tránsito. Si Exchange determina que el mensaje original se perdió por el camino, la copia redundante del mensaje se vuelve a entregar.

Para obtener más información acerca de las características de alta disponibilidad de transporte en Exchange Server, consulte Alta disponibilidad de transporte en Exchange Server. Para obtener más información acerca de la redundancia de mensajes después de que un mensaje se haya entregado correctamente, consulte Red de seguridad en Exchange Server.

Componentes de la redundancia de instantánea

En esta tabla se describen los componentes de la redundancia de instantáneas en el servicio de transporte en los servidores de buzones de correo. A lo largo de este tema se emplean los términos que se describen a continuación.

Requisitos para la redundancia de instantánea

Aunque parezca obvio, la redundancia de instantáneas requiere varios servidores de buzones de correo:

• Si el servidor del buzón de correo no es miembro de un DAG, los demás servidores de buzón de correo deben encontrarse en el sitio de Active Directory.

• Si el servidor del buzón de correo es miembro de un DAG, los demás servidores del buzón de correo deben pertenecer al mismo DAG. Los demás miembros del DAG pueden estar en el sitio de Active Directory local o en un sitio remoto. De forma predeterminada, si el DAG abarca varios sitios de Active Directory, la redundancia de instantáneas prefiere crear una copia redundante del mensaje en un sitio remoto para la resistencia del sitio.

Estas son las situaciones donde la redundancia de la instantánea no puede proteger mensajes en tránsito:

• En entornos de servidor de Exchange solo.

• En DAG infra aprovisionados.

• Durante el error simultáneo de dos o más servidores de buzones implicados en la redundancia de instantáneas de un mensaje.

Redundancia de instantánea está activado por defecto

De forma predeterminada, la redundancia de instantáneas está habilitada globalmente en el servicio de transporte en todos los servidores de buzones de correo. En esta tabla se describen los parámetros que habilitan la redundancia de instantáneas.

¿Cómo se crean mensajes de instantánea?

El objetivo principal de la redundancia de instantánea es disponer siempre de dos copias de un mensaje en el límite de alta disponibilidad de transporte mientras el mensaje se encuentra en tránsito. El lugar y el momento en que se crea la copia redundante del mensaje dependen de dónde procede el mensaje y adónde se dirige. Hay tres factores determinantes para crear mensajes de sombra:

• Mensajes recibidos desde fuera de un límite de alta disponibilidad de transporte (el DAG o un sitio de Active Directory en entornos que no son DAG).

• Mensajes enviados fuera de un límite de alta disponibilidad de transporte.

• Mensajes recibidos desde el servicio de envío de transporte de buzón de correo desde un servidor de correo en el límite de alta disponibilidad de transporte.

Redundancia de instantánea nunca rastrea mensajes de instantánea a través de un límite de alta disponibilidad de transporte. Cuando un mensaje cruza el límite de alta disponibilidad de transporte, la redundancia de instantánea comienza o se reinicia. Esto reduce el tráfico de mantenimiento de instantáneas y evita que se vuelvan a enviar instantáneas a través del límite de alta disponibilidad de transporte. Los servidores de transporte de concentradores de Exchange 2010 son un caso especial del que se hablará más adelante en este mismo tema.

Mensajes recibidos desde fuera de un límite de alta disponibilidad de transporte

Cuando el servicio de transporte de un servidor de buzones de correo recibe un mensaje de fuera del límite de alta disponibilidad de transporte, el servidor de buzones de correo no se preocupa por la compatibilidad o la falta de compatibilidad con la redundancia de instantáneas por parte del servidor de envío. En la medida en que se habilite la redundancia de instantánea, el servidor de buzón de correo que recibe el mensaje realiza una instantánea del mensaje en otro servidor de buzón de correo en el límite de alta disponibilidad de tráfico antes de acusar recibo del mensaje al servidor emisor. Este es un ejemplo de cómo funciona el proceso:

1. Un servidor de mensajería transmite un mensaje al servicio de transporte en un servidor de buzones de correo. El servidor del buzón de correo es el servidor principal y el mensaje es el mensaje principal.

2. Mientras la sesión SMTP original con el servidor de mensajería sigue activa, el servicio de transporte en el servidor principal abre una nueva sesión SMTP simultánea con el servicio de transporte en otro servidor de buzones de correo de la organización para crear una copia redundante del mensaje.

   • Si el servidor principal es miembro de un DAG, este se conecta con un servidor de buzón de correo diferente en el mismo DAG. Si el DAG abarca varios sitios de Active Directory, de forma predeterminada es preferible un servidor de buzones de correo en un sitio de Active Directory diferente (el valor predeterminado del parámetro ShadowMessagePreferenceSetting en el cmdlet Set-TransportConfig es PreferRemote, pero puede cambiarlo a RemoteOnly o LocalOnly).

   • Si el servidor principal no es miembro de un DAG, el servidor principal se conecta a un servidor de buzones diferente en el mismo sitio de Active Directory (independientemente del valor del parámetro ShadowMessagePreferenceSetting ).

3. El servidor principal transmite una copia del mensaje al servicio de transporte en otro servidor de buzones de correo, y el servicio de transporte del otro servidor de buzones reconoce que la copia del mensaje se creó correctamente. La copia del mensaje es un mensaje de instantánea, y el servidor del buzón de correo que contiene el mensaje es el servidor de instantánea del servidor principal. El mensaje existe en una cola de instantánea en el servidor de instantánea.

4. Una vez que el servidor principal recibe la confirmación del servidor de instantáneas, este reconoce la recepción del mensaje principal al servidor de mensajería original en la sesión SMTP original y se cierra la sesión SMTP.

Mensajes enviados fuera de un límite de alta disponibilidad de transporte

Cuando un servidor de buzones transmite un mensaje fuera del límite de alta disponibilidad de transporte, y el servidor de mensajería del otro lado reconoce que el mensaje se ha recibido correctamente y el servidor de buzones lo mueve a la red de seguridad. No puede volver a enviarse el mensajes desde la red de seguridad una vez que el mensaje principal ha sido transmitido satisfactoriamente a través del límite de alta disponibilidad de transporte. Para obtener más información acerca de la red de seguridad, consulte Red de seguridad en Exchange Server.

Mensajes transmitidos dentro de un límite de alta disponibilidad de transporte

El enrutamiento de mensajes está optimizado para que, cuando el destino final esté en un DAG o en un sitio de Active Directory, normalmente no se requieran varios saltos entre servidores dentro del DAG o sitio de destino. Una vez que el servicio de transporte acepta el mensaje en un servidor de buzones del DAG de destino o Active Directory, el siguiente salto del mensaje suele ser el destino final (por ejemplo, el servidor de buzones que contiene la copia activa del buzón de destino). El objetivo de la redundancia de instantáneas de mantener dos copias de un mensaje en tránsito se cumple cuando existe una instantánea del mensaje en cualquier lugar dentro del sitio de DAG o Active Directory. Normalmente, solo los escenarios de conmutación por error de un DAG que requieren el cmdlet Redirect-Message para purgar las colas de mensajes activas en un servidor de buzones de correo requerirían varios saltos dentro del mismo límite de alta disponibilidad de transporte.

Redundancia de instantáneas con concentradores de Exchange 2010 Servidores de transporte en el mismo sitio de Active Directory en organizaciones con Exchange 2016

Cuando un servidor de transporte de concentradores de Exchange 2010 transmite un mensaje a un servidor de buzones de Exchange 2016 en el mismo sitio de Active Directory, el servidor de transporte de concentradores de Exchange 2010 anuncia la compatibilidad con redundancia de instantáneas mediante el comando XSHADOW, pero el servidor de buzones de correo no anuncia compatibilidad con redundancia de instantáneas. Esto impide que el servidor de transporte de concentradores de Exchange 2010 cree una instantánea del mensaje en un servidor de buzones de Exchange 2016.

Cuando el servicio de transporte de un servidor de buzones de Exchange 2016 transmite un mensaje a un servicio de transporte de concentradores de Exchange 2010 en el mismo sitio de Active Directory, el servidor de buzones de Exchange 2016 vigila el mensaje para el servidor de transporte de concentradores de Exchange 2010. Después de que el servidor de buzones de Exchange 2016 reciba el acuse de recibo del servidor de transporte concentradores de Exchange 2010 de que el mensaje se recibió correctamente, el servidor de buzones de Exchange 2016 moverá el mensaje procesado correctamente a la red de seguridad. Sin embargo, los mensajes procesados correctamente almacenados en la red de seguridad por el buzón de Exchange 2016 nunca se vuelven a enviar a los servidores de transporte concentradores de Exchange 2010.

Tiempos de espera de SMTP

Durante el intento de realizar una copia redundante del mensaje, se podría agotar el tiempo de espera de la conexión SMTP entre los servidores (el servidor emisor y el servidor principal, o el servidor principal y el servidor invertido). Los conectores de recepción y envío tienen un parámetro ConnectionInactivityTimeOut para cuando los datos se transmiten realmente en el conector. Los conectores de recepción también tienen un parámetro ConnectionTimeOut absoluto.

Si alguna de las sesiones SMTP agota el tiempo de espera antes de que la instantánea del mensaje se cree y se reconozca correctamente, el resultado se controla mediante el parámetro RejectMessageOnShadowFailure en el cmdlet Set-TransportConfig . De forma predeterminada, el valor de este parámetro es $false, lo que significa que se acepta el mensaje principal sin crear una instantánea. Si el valor de este parámetro es $true el mensaje principal se rechaza con el error 451 4.4.0transitorio .

Si la instantánea de un mensaje se crea correctamente, pero se agota el tiempo de espera de la sesión SMTP entre el servidor emisor y el servidor principal, el servidor principal acepta y procesa el mensaje principal. El servidor emisor volverá a entregar el mensaje no confirmado, pero la detección de mensajes duplicados impedirá que los usuarios del buzón de Exchange vean los mensajes duplicados. Cuando el servidor emisor vuelva a enviar el mensaje, creará otra instantánea del mensaje. No hay ninguna relación entre los mensajes instantáneos creados durante los reenvíos de mensajes por el servidor de envío.

La siguiente tabla describe los parámetros que controlan la creación de instantáneas

¿Cómo se mantienen los mensajes de instantánea?

Una vez creado un mensaje de instantánea, el trabajo de la redundancia de instantánea no ha hecho más que empezar. El servidor principal y el servidor de instantánea necesitan estar en contacto entre sí para rastrear el progreso del mensaje.

Cuando el servidor principal transmite con éxito el mensaje al siguiente salto, y este acusa recibo del mensaje, el servidor principal actualiza el estado de descarte del mensaje como entrega completa. El estado de descarte consiste básicamente en un mensaje que contiene una lista de mensajes que se están supervisando. Los mensajes que se envían con éxito no necesitan mantenerse en una cola de instantánea, de manera que cuando el servidor de instantánea sabe que el servidor principal ha transmitido con éxito el mensaje al siguiente salto, el servidor de instantánea mueve el mensaje de la cola de instantánea a la red de seguridad.

El servidor de instantánea decide el estado de descarte de los mensajes de instantánea en las colas de instantáneas consultando al servidor principal. Si el servidor de instantáneas abre una sesión SMTP con el servidor principal por cualquier motivo (incluida la transmisión de otros mensajes no relacionados), el servidor de instantáneas emite el comando XQDISCARD para determinar el estado de descarte de los mensajes principales. De lo contrario, el servidor de instantáneas abrirá automáticamente una sesión SMTP con el servidor principal después de un intervalo de tiempo preconfigurado (el parámetro ShadowHeartbeatFrequency en el cmdlet Set-TransportConfig ; el valor predeterminado es 2 minutos).

Una vez que el servidor de instantánea abre una sesión SMTP con el servidor principal, este responde con las notificaciones de descarte para los mensajes se aplican al servidor de instantánea que realiza la consulta. Las notificaciones de descarte se almacenan en el disco (no en la memoria), por lo que, si el servicio de transporte de Microsoft Exchange se reinicia, las notificaciones de descarte persisten. Una vez iniciado el servicio, el servidor principal sigue conocimiento los mensajes que ha procesado satisfactoriamente, y la información está disponible para el servidor de instantánea.

La comunicación SMTP entre el servidor de instantánea y el servidor principal se emplea como ellatido que determina la disponibilidad de los servidores. Si el servidor de instantáneas no puede abrir una sesión SMTP con el servidor principal después de un intervalo de tiempo preconfigurado (el parámetro ShadowResubmitTimeSpan en el cmdlet Set-TransportConfig ; el valor predeterminado es 3 horas), el servidor de instantáneas se promueve a sí mismo como el servidor principal, promueve los mensajes de sombra como mensajes principales y transmite los mensajes al siguiente salto. Sin embargo, siempre que el servidor inverso detecta que el identificador de la base de datos de colas del servidor primario ha cambiado, el servidor inverso también se promociona a sí mismo como el servidor primario, promueve los mensajes instantáneos como mensajes primarios y transmite los mensajes al salto siguiente. Esto puede ocurrir mucho antes de que pase el valor del parámetro ShadowResubmitTimeSpan .

El Administrador de redundancia de instantáneas es el componente principal de un servidor de buzones de correo responsable de administrar la redundancia de instantáneas. 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áneas 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áneas es responsable de las siguientes acciones para todos los mensajes de instantáneas que un servidor de instantáneas tiene en sus colas de instantáneas:

• Mantener la lista de servidores principales de cada mensaje de instantánea.

• Comparar el Id. original y el Id. actual de la base de datos de la base de datos de cola en el que se almacena la copia principal del mensaje.

• 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 las colas de instantánea 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.

• Seguimiento de bifurcaciones de mensajes y otros mensajes con efectos secundarios, como notificaciones de estado de entrega (también conocidas como DSN, informes de no entrega, NDR o mensajes de devolución) e informes de diario para comprobar que la copia redundante del mensaje no se libera hasta que todas las bifurcaciones del mensaje se hayan procesado completamente.

En esta tabla se describen los parámetros que controlan cómo se mantienen los mensajes de instantánea.

Procesamiento de mensajes después de una interrupción

En esta tabla se resume cómo la redundancia de instantáneas minimiza la pérdida de mensajes debida a interrupciones del servidor. Para mayor claridad, el servidor que tuvo una interrupción se llama Mailbox01.