Redundancia de sombra en Exchange Server
La redundancia de instantáneas se introdujo en Exchange 2010 para proporcionar copias redundantes de los mensajes antes de entregarlos a los buzones. En Exchange 2010, la redundancia de sombra retrasó la eliminación de un mensaje de la base de datos de cola en un servidor de transporte de concentrador hasta que el servidor comprobó que el próximo salto en la ruta de entrega del mensaje había completado la entrega. Si se produjo un error en el próximo salto antes de notificar la entrega correcta al servidor de transporte del concentrador, el servidor volvió a enviar el mensaje a ese próximo salto. Los servidores de transporte del centro de Exchange 2010 usaron el verbo XSHADOW para anunciar su compatibilidad con la redundancia de sombra. Si un servidor de mensajería de origen no admite redundancia de sombra, Exchange 2010 usó la confirmación diferida 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 sombra en Exchange 2013: el servicio de transporte en un servidor de buzones 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 mensajes en tránsito es más que un mejor esfuerzo que puede o no funcionar, ya que ahora la redundancia instantánea no depende de las características admitidas del servidor de envío (no importa la compatibilidad o la falta de compatibilidad con la redundancia instantánea). 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ó en tránsito, se vuelve a entregar la copia redundante del mensaje.
Para obtener más información sobre 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 sobre la redundancia de mensajes después de que un mensaje se haya entregado correctamente, vea Safety Net in Exchange Server(Red de seguridad en Exchange Server).
Componentes de la redundancia de instantánea
En esta tabla se describen los componentes de la redundancia de sombra en el servicio de transporte en servidores de buzones de correo. A lo largo de este tema se emplean los términos que se describen a continuación.
| Término | Descripción |
|---|---|
| Límite de alta disponibilidad de transporte | Grupo de disponibilidad de bases de datos (DAG) en entornos DAG, o un sitio de Active Directory en entornos que no sean parte de un DAG. En el caso de los DAG que abarcan varios sitios de Active Directory, el propio DAG sigue siendo el límite (no el sitio). Cuando un mensaje llega a un servidor de buzones en el límite de alta disponibilidad de transporte, Exchange intenta mantener dos copias redundantes del mensaje en servidores de buzones dentro del límite. Cuando un mensaje abandona el límite de alta disponibilidad de transporte, Exchange deja de conservar copias del mensaje. |
| Mensaje principal | El mensaje enviado en la canalización de transporte para la entrega. |
| Mensaje de instantánea | La copia redundante del mensaje que el servidor de instantáneas conserva hasta que confirma que el mensaje principal ha sido procesado con éxito por el servidor principal. |
| Servidor principal | El servidor de buzón de correo que está procesando actualmente el mensaje principal. |
| Servidor de instantánea | El servidor de buzón de correo que contiene el mensaje de sombra para el servidor principal. Un servidor de buzón de correo puede ser el servidor principal para algunos mensajes y el servidor de instantáneas para otros mensajes simultáneamente. |
| Cola de instantáneas | La cola de entrega donde el servidor de instantánea almacena mensajes de instantánea. En mensajes con múltiples destinatarios, cada salto del mensaje principal necesita colas de instantáneas independientes. |
| Estado de descarte | La información que el servidor de buzones de correo mantiene para que los mensajes alternativos indiquen que el mensaje principal se ha procesado correctamente. |
| Notificación de descarte | Respuesta que un servidor de instantáneas recibe de un servidor principal y que indica que un mensaje de instantánea se puede descartar. |
| Red de seguridad | La versión mejorada del contenedor de transporte en Exchange 2013 o posterior. Los mensajes que se procesan o se entregan satisfactoriamente a un destinatario de buzón de correo por parte del servicio de transporte en un servidor de buzón de correo se mueven a la red de seguridad. Para obtener más información, vea Red de seguridad en Exchange Server. |
| Administrador de redundancia de instantánea | Componente de transporte que administra la redundancia de instantánea. |
| Latido | Proceso por el cual los servidores principales y los servidores de instantáneas comprueban su disponibilidad entre sí. |
Requisitos para la redundancia de instantánea
Aunque puede parecer obvio, la redundancia instantánea 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 sombra 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 sombra de un mensaje.
Redundancia de instantánea está activado por defecto
De forma predeterminada, la redundancia de instantáneas se habilita 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 sombra.
| Parámetro | Valor predeterminado | Descripción |
|---|---|---|
| ShadowRedundancyEnabled en Set-TransportConfig | $true |
$true: la redundancia de sombra está habilitada en todos los servidores de buzones de la organización. |
| RejectMessageOnShadowFailure en Set-TransportConfig | $false |
$false: cuando no se puede crear una instantánea del mensaje, los servidores de buzones de correo de la organización aceptan el mensaje principal de todos modos. Estos mensajes no se conservan redundantemente mientras están en tránsito. Nota: Use Este parámetro solo es significativo cuando ShadowRedundancyEnabled es |
¿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. Dónde y cuándo se crea la copia redundante del mensaje depende de dónde procede el mensaje y de dónde va el mensaje. Hay tres factores determinantes para crear mensajes alternativos:
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 de 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 mensajes alternativos e impide que se vuelvan a enviar mensajes alternativos 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 recibe un mensaje fuera del límite de alta disponibilidad de transporte, el servidor de buzones no está preocupado por la compatibilidad o la falta de compatibilidad con la redundancia de sombras 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:
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.
Aunque 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 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, se prefiere de forma predeterminada un servidor de buzones de un sitio de Active Directory diferente (el valor predeterminado del parámetro ShadowMessagePreferenceSetting en el cmdlet Set-TransportConfig es
PreferRemote, pero puede cambiarlo aRemoteOnlyoLocalOnly).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 ShadowMessagePreferenceSetting ).
El servidor principal transmite una copia del mensaje al servicio de transporte en otro servidor de buzones de correo y el servicio de transporte en el otro servidor de buzones de correo confirma 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.
Una vez que el servidor principal recibe la confirmación del servidor de instantáneas, el servidor principal confirma 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 confirma que el mensaje se ha recibido correctamente y el servidor de buzones mueve el mensaje a Safety Net. 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 sobre Safety Net, consulte Safety Net 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 sitio dag o active directory, no se requieran normalmente varios saltos entre servidores dentro del DAG o el sitio de destino. Después de que el servicio de transporte acepte el mensaje en un servidor de buzón en el DAG de destino o Active Directory, el próximo salto del mensaje suele ser el destino final (por ejemplo, el servidor de buzón de correo que contiene la copia activa del buzón de destino). El objetivo de la redundancia de sombra de mantener dos copias de un mensaje en tránsito se cumple cuando existe una instantánea del mensaje en cualquier lugar dentro del dag o del sitio de Active Directory. Normalmente, solo los escenarios de conmutación por error en 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 sombra con servidores de transporte del centro de Exchange 2010 en el mismo sitio de Active Directory en organizaciones de Exchange 2016
Cuando un servidor de transporte del centro 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 del centro de Exchange 2010 anuncia la compatibilidad con la redundancia instantánea mediante el comando XSHADOW, pero el servidor de buzones no anuncia compatibilidad con la redundancia instantánea. Esto impide que el servidor de transporte del centro 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 transporte de centro de Exchange 2010 en el mismo sitio de Active Directory, el servidor de buzones de Exchange 2016 oculta el mensaje para el servidor de transporte del centro de Exchange 2010. Después de que el servidor de buzones de Exchange 2016 reciba la confirmación del servidor de transporte del centro de Exchange 2010 de que el mensaje se recibió correctamente, el servidor de buzones de Exchange 2016 mueve el mensaje procesado correctamente a Safety Net. Sin embargo, los mensajes procesados correctamente almacenados en Safety Net por buzón de Exchange 2016 nunca se vuelven a enviar a los servidores de transporte del centro de Exchange 2010.
Tiempos de espera de SMTP
Durante el intento de realizar una copia redundante del mensaje, podría agotarse el tiempo de espera de la conexión SMTP entre los servidores (el servidor de envío y el servidor principal, o el servidor principal y el servidor alternativo). 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 ha creado correctamente, pero la sesión SMTP entre el servidor de envío y el servidor principal agota el tiempo de espera, el servidor principal acepta y procesa el mensaje principal. El servidor de envío volverá a entregar el mensaje no reconocido, pero la detección de mensajes duplicados impedirá que los usuarios del buzón de Exchange vean los mensajes duplicados. Cuando el servidor remitente vuelve a enviar el mensaje, el servidor principal creará otra instantánea del mensaje. No hay ninguna relación entre los mensajes alternativos creados durante las reenviaciones de mensajes por parte del servidor remitente.
La siguiente tabla describe los parámetros que controlan la creación de instantáneas
| Origen | Valor predeterminado | Descripción |
|---|---|---|
| ShadowMessagePreferenceSetting en Set-TransportConfig | PreferRemote |
Este parámetro solo se usa cuando el servidor principal que intenta realizar una instantánea del mensaje es miembro de un DAG que abarca varios sitios de Active Directory.
|
| MaxRetriesForRemoteSiteShadow en Set-TransportConfig | 4 | Este parámetro especifica el número máximo de intentos de crear una instantánea del mensaje en otro servidor del DAG cuando el valor del parámetro ShadowMessagePreferenceSetting es PreferRemote (el valor predeterminado) o RemoteOnly. Este parámetro solo se usa cuando el servidor de buzones es miembro de un DAG que abarca varios sitios de Active Directory. Si una instantánea del mensaje no se crea correctamente después del número especificado de intentos, el resultado depende del valor del parámetro RejectMessageOnShadowFailure :
|
| MaxRetriesForLocalSiteShadow en Set-TransportConfig | 2 | Este parámetro especifica el número máximo de intentos de crear una instantánea del mensaje en otro servidor de buzones en el sitio local de Active Directory cuando:
Si una instantánea del mensaje no se crea correctamente después del número especificado de intentos, el resultado depende del valor del parámetro RejectMessageOnShadowFailure :
|
| ConnectionInactivityTimeout en Set-ReceiveConnector | 5 minutos para los conectores de recepción en el servicio de transporte en servidores de buzones | Este parámetro especifica el tiempo máximo que una conexión SMTP abierta con el servidor de mensajería de origen puede permanecer inactiva antes de que se cierre la conexión. El valor de este parámetro debe ser mayor que el valor del parámetro ConnectionTimeout . |
| ConnectionTimeout en Set-ReceiveConnector | 10 minutos para los conectores de recepción en el servicio de transporte en servidores de buzones | Este parámetro especifica el tiempo máximo que puede permanecer abierta una conexión SMTP con el servidor de mensajería de origen, incluso si el servidor transmite datos. El valor de este parámetro debe ser mayor que el valor del parámetro ConnectionInactivityTimeout . |
| ConnectionInactivityTimeOut en Set-SendConnector | 10 minutos | Este parámetro especifica el tiempo máximo que puede permanecer inactiva una conexión SMTP con un servidor de mensajería de destino antes de que se cierre la conexión. |
¿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 memoria), por lo que, si se reinicia el servicio de transporte de Microsoft Exchange, 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 como servidor principal, promueve los mensajes de sombra como mensajes principales y transmite los mensajes al próximo salto. Sin embargo, cada vez que el servidor de instantáneas detecta que el identificador de base de datos de cola del servidor principal ha cambiado, el servidor de instantáneas también se promueve como servidor principal, promueve los mensajes alternativos como mensajes principales y transmite los mensajes al próximo salto. Esto podría ocurrir antes de que haya pasado el valor del parámetro ShadowResubmitTimeSpan .
Shadow Redundancy Manager es el componente principal de un servidor de buzón de correo que es responsable de administrar la redundancia de sombra. 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 para cada mensaje principal que se está procesando.
El estado de descarte que se va a enviar a los servidores de instantánea.
Shadow Redundancy Manager es responsable de las siguientes acciones para todos los mensajes de sombra que un servidor de instantáneas tiene en sus colas de sombras:
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 de efecto secundario, 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 publica hasta que todas las bifurcaciones del mensaje se procesan completamente.
En esta tabla se describen los parámetros que controlan cómo se mantienen los mensajes de sombra.
| Parámetro | Valor predeterminado | Descripción |
|---|---|---|
| ShadowHeartbeatFrequency en Set-TransportConfig | 2 minutos | La cantidad máxima de tiempo que espera un servidor de instantáneas antes de abrir una conexión SMTP en el servidor principal para comprobar el estado de descarte de los mensajes. |
| ShadowResubmitTimeSpan en Set-TransportConfig | 3 horas | El tiempo de espera de un servidor antes de decidir que un servidor principal falla y asume la propiedad de las instantáneas de mensajes en la cola de instantáneas para el servidor principal que es inalcanzable. Tenga en cuenta que un servidor de instantáneas también puede promoverse como servidor principal antes del valor de este parámetro cuando se detecta que la base de datos de cola del servidor principal tiene un identificador de base de datos diferente. |
| ShadowMessageAutoDiscardInterval en Set-TransportConfig | 2 días | Intervalo de tiempo en que un servidor conserva eventos de descarte para mensajes entregados correctamente. Las colas de un servidor principal descartan eventos hasta que el servidor de instantáneas lo consulta. Ahora bien, si el servidor de seguridad no consulta al servidor de seguridad respecto a la duración que se especifica en este parámetro, el servidor principal elimina los elementos descartados que están en cola. |
| SafetyNetHoldTime en Set-TransportConfig | 2 días | Cuánto tiempo se conservan los mensajes procesados correctamente en la red de seguridad. Los mensajes alternativos no reconocidos finalmente expiran de Safety Net después de la suma de los valores de los parámetros SafetyNetHoldTime y MessageExpirationTimeout en el cmdlet Set-TransportService . |
| MessageExpirationTimeout en Set-TransportService | 2 días | Tiempo que un mensaje puede permanecer en una cola antes de que caduque. |
Procesamiento de mensajes después de una interrupción
En esta tabla se resume cómo la redundancia instantánea minimiza la pérdida de mensajes debido a interrupciones del servidor. Para mayor claridad, el servidor que tuvo una interrupción se denomina Mailbox01.
| Escenario de recuperación | Acciones realizadas |
|---|---|
| Mailbox01 vuelve a estar en línea con una nueva base de datos de cola antes de que pase el valor del parámetro ShadowResubmitTimeSpan (de forma predeterminada, 3 horas). Este escenario puede producirse cuando la base de datos de cola no se puede recuperar debido a daños en los datos o errores de hardware. |
Cuando se detecta el nuevo identificador de base de datos de cola en Mailbox01, cada servidor que tenga mensajes alternativos en cola para Mailbox01 asumirá la propiedad de esos mensajes y los volverá a enviar. A continuación, los mensajes se entregan a sus destinos. El retraso máximo para el envío de mensajes después de que se detecte la nueva base de datos de cola es el valor del parámetro ShadowHeartbeatFrequency (de forma predeterminada, 2 minutos). |
| Mailbox01 vuelve a estar en línea con la misma base de datos después de que haya pasado el valor del parámetro ShadowResubmitTimeSpan (de forma predeterminada, 3 horas). Este escenario puede producirse después de un error de tarjeta de red o de un mantenimiento prolongado en el servidor. |
Cuando Mailbox01 vuelve a estar en línea, entregará los mensajes en sus colas, que ya habrán sido entregadas por los servidores que mantienen instantáneas de los mensajes para Mailbox01. Como consecuencia, lo mensajes se entregarán por duplicado. Los usuarios del buzón de Exchange no verán mensajes duplicados gracias a la detección de mensajes duplicados. Sin embargo, los destinatarios de otros sistemas de mensajería podrían ver copias duplicadas de mensajes. El retraso máximo para el envío de mensajes es el valor del parámetro ShadowResubmitTimeSpan . |