Redundancia de instantánea

Se aplica a: Exchange Server 2013

La redundancia de la instantánea fue introducida en Microsoft Exchange Server 2010 para proporcionar copias redundantes de mensajes antes de que se entreguen a los buzones de correo. En Exchange 2010, la redundancia de la instantánea retrasaba la eliminación de un mensaje desde la base de datos de transporte de un servidor de transporte hasta que el servidor había comprobado si el siguiente salto de la ruta de entrega del mensaje había completado la entrega. Si el salto siguiente dada error antes de notificar al servidor de transporte que había realizado satisfactoriamente la entrega, este reenviaba el mensaje al siguiente salto. Los servidores Exchange 2010 usaban el verbo XSHADOW para anunciar su soporte de redundancia de la instantánea. Si un servidor SMTP no admitía la redundancia de la instantánea, Exchange 2010 usaba el reconocimiento retrasado basándose en un intervalo de tiempo configurado en el conector de recepción para realizar una copia redundante del mensaje.

La principal mejora en la redundancia de la instantánea en Microsoft Exchange Server 2013 es que el servidor de transporte ahora realiza una copia redundante de cualquier mensaje que recibe antes de notificar la recepción satisfactoria del mismo al servidor de envío. No tiene transcendencia si el servidor de envío admite o no la redundancia de la instantánea. Esto ayuda a garantizar que todos los mensajes de la canalización de transporte de Exchange 2013 son redundantes mientras se encuentran en tránsito. Si Exchange 2013 establece que el mensaje original se ha perdido en tránsito, se entrega la copia redundante del mensaje.

Componentes de la redundancia de instantánea

La tabla siguiente describe los componentes de redundancia de la instantánea. 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 pueda parecer obvio, la redundancia de la instantánea requiere múltiples servidores de buzón de correo en Exchange 2013. El servidor de buzón de correo puede ser un servidor independiente, o servidores de buzón de correo y de acceso de clientes instalados en el mismo equipo.

• 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. El resto de servidores de buzón de correo que pertenecen al DAG pueden estar en el sitio local de Active Directory o en un sitio remoto de Active Directory. Si el DAG se extiende en varios sitios de Active Directory, la redundancia de la instantánea prefiere crear una copia redundante del mensaje en un sitio remoto de Active Directory 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 transporte que participan en la redundancia de la instantánea de un mensaje.

Redundancia de instantánea está activado por defecto

Por defecto, redundancia de instantánea está activado de manera global en el servicio de transporte de todos los buzones de correo usando el parámetro ShadowRedundancyEnabled en el cmdlet Set-TransportConfig. Por defecto, si el servicio de transporte de un servidor de buzón de correo no puede crear una copia redundante de un mensaje, el mensaje no se rechaza. Sin embargo, puede configurar Exchange 2013 para rechazar un mensaje si no se crea una copia redundante del mensaje mediante el parámetro RejectMessageOnShadowFailure en el cmdlet Set-TransportConfig . El mensaje se rechaza con un error transitorio, pero el servidor de envío puede volver a transmitir el mensaje. El código de respuesta SMTP es 451 4.4.0 Message failed to be made redundant. Debe configurar Exchange 2013 para rechazar los mensajes que no se pueden hacer redundantes solo cuando su organización tiene varios servidores de buzones de Exchange 2013 disponibles.

La tabla siguiente describe los parámetros que permiten redundancia de instantánea.

Parámetros que permiten redundancia de instantánea

¿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. Cuándo y dónde se crea la copia redundante del mensaje depende de la procedencia y el destino del mensaje. Hay tres factores determinantes principales:

• Mensajes recibidos desde fuera de un límite de alta disponibilidad de transporte.
• 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.

El límite de alta disponibilidad de transporte es uno de los siguientes:

• Un DAG, para servidores de correo que son miembros de un DAG. Esto incluye un DAG que abarca múltiples sitios de Active Directory.
• Un sitio de Active Directory, para servidores de buzón de correo que no pertenecen a un DAG.

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 mensajes de instantánea y evitar que se reenvíen mensajes de instantánea en los límites de alta disponibilidad de tráfico. 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 buzón de correo de Exchange 2013 recibe un mensaje externo al límite de alta disponibilidad de transporte, al servidor de buzón de correo no le interesa la compatibilidad o falta de compatibilidad de redundancia de instantánea en el servidor emisor. 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 SMTP transmite un mensaje al servicio de transporte de un servidor de buzón de correo. El servidor del buzón de correo es el servidor principal y el mensaje es el mensaje principal.

2. Aunque la sesión SMTP original con el servidor SMTP sigue estando activa, el servicio de transporte del servidor principal abre una nueva sesión SMTP simultánea con el servicio de transporte en un servidor de buzón de correo diferente de la organización para crear la 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 se expande en varios sitios de Active Directory, se prefiere un servidor de buzón de correo en un sitio de Active Directory de manera predeterminada. Esta configuración se controla mediante el parámetro ShadowMessagePreference en el cmdlet Set-TransportService . El valor predeterminado 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 otro servidor de buzón en el mismo sitio de Active Directory, independientemente del valor del parámetro ShadowMessagePreference .

3. El servidor principal transmite una copia del mensaje al servicio de transporte del servidor de buzón de correo, y el servicio de transporte del otro servidor de buzón de correo notifica que la copia del mensaje se ha creado satisfactoriamente. 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. Cuando el servidor principal recibe una notificación del servidor de instantánea, el servidor principal acusa recibo del mensaje principal al servidor SMTP original en la sesión SMTP original, y la sesión SMTP se cierra.

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

Cuando un servidor de transporte Exchange 2013 transmite un mensaje fuera del límite de alta disponibilidad de tráfico y el servidor SMTP en el otro lado acusa recibo del mensaje, el servidor de transporte mueve el mensaje 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.

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

El enrutado de mensajes está optimizado en Exchange 2013 de manera que cuando el destino último es un sitio DAG o de Active Directory, no suelen ser necesarios múltiples saltos entre el servicio de transporte en servidores de buzón de correo en dicho sitio DAG o Active Directory. Una vez que el mensaje es aceptado por el servicio de transporte en un servidor de buzón de correo en el sitio DAG o Active Directory que mantiene el último destino del mensaje, el siguiente salto del mensaje suele ser el propio destino último. El objetivo de la redundancia de instantánea de mantener dos copias de un mensaje en tránsito se cumple cuando una instantánea del mensaje existe en cualquier lugar de un sitio DAG o Active Directory. Normalmente, solo las situaciones de fallo en un DAG que exija que el cmdlet Redirect-Message purgue las colas activas en un servidor de buzón de correo requieren múltiples saltos en el mismo límite de alta disponibilidad de tráfico.

La redundancia de instantánea con servidores de transporte de concentradores Exchange 2010 en el mismo sitio de Active Directory

Cuando un servidor de transporte de concentradores de Exchange 2010 transmite un mensaje a un servidor de buzón de correo Exchange 2013 en el mismo sitio de Active Directory, el servidor de transporte de concentradores de Exchange 2010 anuncia la compatibilidad de la redundancia de instantánea usando el comando XSHADOW, pero el servidor de buzón de correo no anuncia la compatibilidad de la redundancia de instantánea. Esto impide que el servidor de transporte de concentradores de Exchange 2010 cree una instantánea del mensaje en un servidor de buzón de correo de Exchange 2013.

Cuando un servicio de transporte en un servidor de buzón de correo Exchange 2013 transmite un mensaje a un transporte de concentradores Exchange 2010 del mismo sitio de Active Directory, el servidor de buzón de correo Exchange 2013 crea una instantánea del mensaje para el servidor de transporte de concentradores Exchange 2010. Una vez que el servidor de buzón de correo Exchange 2013 recibe notificación del servidor de transporte de concentradores Exchange 2010 de que el mensaje ha sido recibido satisfactoriamente, el servidor de buzón de correo Exchange 2013 mueve el mensaje procesado satisfactoriamente en la red de seguridad. Sin embargo, el mensaje procesado satisfactoriamente y almacenado en la red de seguridad por el buzón de correo Exchange 2013 no se vuelve a reenviar a los servidores de transporte de concentradores de Exchange 2010.

Tiempos de espera de SMTP

Durante el intento de realizar una copia redundante del mensaje, la conexión SMTP entre el servidor SMTP de envío y el servidor principal, o la sesión SMTP entre el servidor principal y el servidor de instantánea podría agotar el tiempo de espera. Los conectores de recepción y los conectores de 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 confirme 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 el mensaje principal se acepta 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 satisfactoriamente, pero la sesión SMTP entre el servidor SMTP de envío y el servidor principal agota el tiempo de espera, el servidor principal acepta y procesa el mensaje principal. El servidor SMTP de envío reenviará el mensaje no confirmado, pero la detección de mensajes duplicados evitará que los usuarios de Exchange vean mensajes duplicados. Cuando el servidor SMTP de envío reenvía el mensaje, el servidor principal creará otra instantánea del mensaje. No existe relación entre las instantáneas creadas durante el reenvío de mensajes por parte del servidor SMTP de envío.

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

Parámetros de creación del mensaje de instantánea

¿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ánea abre una sesión SMTP con el servidor principal por cualquier motivo, incluida la transmisión de otros mensajes sin relación, el servidor de instantánea emite el comando XQDISCARD para decidir el estado de descarte de los mensajes principales. Si el servidor de instantánea no ha abierto una sesión SMTP con el servidor principal después de un intervalo de tiempo preconfigurado, el servidor de instantánea abrirá una sesión SMTP con el servidor principal y emitirá el comando XQDISCARD. El intervalo de tiempo se controla mediante el parámetro ShadowHeartbeatFrequency en el cmdlet Set-TransportConfig . El valor predeterminado es de 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. En Exchange 2013, las notificaciones de descarte se almacenan en el disco, no en la memoria. Por lo tanto, 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ánea no puede abrir una sesión SMTP con el servidor principal después de un intervalo de tiempo preconfigurado, o si la base de datos de transporte del servidor principal tiene un Id. distinto de base de datos, el servidor de instantánea se promueve como el servidor principal, promueve los mensajes de instantánea como mensajes principales y los transmite al siguiente salto. El intervalo de tiempo lo controla el parámetro ShadowResubmitTimeSpan del cmdlet Set-TransportConfig. El valor predeterminado es 3 horas.

Shadow Redundancy Manager es el componente principal de un servidor de transporte de Exchange 2013 responsable de administrar la redundancia 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 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.
• Rastrear las bifurcaciones de mensajes y otros efectos secundarios de mensajes como notificaciones de estado de entrega (DSN) e informes de diario para comprobar que la copia redundante del mensaje no se lanza hasta que se han procesado íntegramente todas las bifurcaciones del mensaje.

En la siguiente tabla se describen los parámetros que controlan cómo se mantiene un mensaje.

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 en línea con una nueva base de datos de transporte: en este escenario, la base de datos de transporte no se puede recuperar debido a daños en los datos o errores de 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 estar en línea con la misma base de datos de transporte: en este escenario, no se produjo un error en el servidor de transporte determinado, pero estaba sin conexión el tiempo suficiente para que el servidor de instantáneas asumiera la propiedad de los mensajes y los volviera a enviar. Por ejemplo, a causa de un error en la tarjeta de red o un mantenimiento del servidor muy prolongado.

La siguiente tabla resume cómo redundancia de instantánea reacciona a estas dos situaciones. Para entenderlo mejor, supongamos que el servidor que ha sufrido una interrupción se llama Mailbox01.

Procesamiento de mensajes en situaciones de recuperación