Descripción de redundancia de instantánea

 

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2015-03-09

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, esta 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 Transporte de concentradores y Transporte perimetral.

Exchange Server 2010 incorpora la característica de redundancia de instantánea para ofrecer redundancia de mensajes durante el tiempo que los mensajes 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 verifica que todos los saltos que debe ir superando el mensaje han completado la entrega. Si alguno de los próximos saltos falla antes de informar de la entrega correcta, el mensaje se reenvía para entregar en el próximo salto.

La redundancia de instantánea reporta las siguientes ventajas:

• Prescinde de la dependencia del estado de cualquier servidor Transporte de concentradores o Transporte perimetral. Se puede hacer uso de cualquier servidor 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. 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.

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 la identidad 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 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.

Protección de redundancia de instantánea cuando los roles de servidor Transporte de concentradores y Buzón de correo coexisten con los DAG

Al utilizar los DAG o grupos de disponibilidad de base de datos, los mensajes que ya se han confirmado en bases de datos de buzones se protegen con la arquitectura del DAG. En cualquier mensaje que se entregue a una base de datos de buzón que sea parte de un DAG, la copia de instantánea de ese mensaje se mantiene en el contenedor de transporte hasta que dicho mensaje se replica en todos los miembros del DAG. Asimismo, cualquier mensaje que se envía a servidores Transporte de concentradores desde un DAG tiene dos copias: una en la cola del servidor Transporte de concentradores a la espera de entregarse, y una copia de instantánea en la carpeta Elementos enviados del remitente. Este planteamiento es fundamental en la redundancia de instantáneas.

No obstante, si los roles de servidor Transporte de concentradores y Buzón de correo coexisten en el mismo servidor, y tiene bases de datos de buzones que forman parte de un DAG, los servidores Transporte de concentradores podrían tener que enrutar un mensaje a través de un salto adicional para evitar que el mensaje principal y el de la instantánea estén en el mismo hardware de servidor. En concreto, el rol de servidor Transporte de concentradores procura evitar las dos situaciones hipotéticas siguientes porque un error en un solo servidor podría acarrear la pérdida del mensaje principal y el de la instantánea:

• Durante la entrega de mensajes, si la base de datos de buzones activa del destinatario del mensaje y el contenedor de transporte donde se hospeda la copia de la instantánea están en el mismo servidor Para evitar esta situación hipotética, el servidor Transporte de concentradores enruta el mensaje a través de otro servidor Transporte de concentradores del sitio para asegurarse de que el mensaje de la instantánea vaya a parar a otro hardware de servidor. Ahora bien, si no hay disponible ningún otro servidor Transporte de concentradores, entrega el mensaje directamente.

• Durante el envío de mensajes, si la cola de transporte que hospeda el mensaje principal y el de instantánea en la carpeta Elementos enviados del remitente están en el mismo servidor   Para evitar esta situación hipotética, el controlador del almacén prefiere otros servidores Transporte de concentradores del sitio para enviar mensajes. No obstante, si en el sitio no hay disponible ningún otro servidor Transporte de concentradores, envía el mensaje al servidor Transporte de concentradores local.

Para obtener más información sobre la coexistencia de los roles de servidor Transporte de concentradores y Buzón de correos al utilizar los DAG, consulte Transporte de concentrador y coexistencia de los roles del servidor de buzones cuando se utiliza DAG.

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 que los mensajes de intercambio de servidores de transporte de Exchange 2010 no permiten la redundancia de instantáneas. Podría ser el caso de servidores de otros fabricantes, versiones anteriores de Exchange o una organización de Exchange 2010 que no tenga habilitada la redundancia de instantánea.

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 de Exchange que ejecuta una versión anterior de Exchange, un cliente SMTP estándar o un servidor de correo que no es de 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 haya entregado correctamente al resto de saltos 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 este caso, y para prevenir 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. 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.

Omisión de acuse con retraso

Hay casos en que es poco probable que se entregue un mensaje antes de que agote el tiempo de espera del acuse con retraso. En estos casos, el servidor de transporte aplica uno de los métodos siguientes para ocuparse de los mensajes:

• Omisión del acuse con retraso De forma predeterminada, el servidor de transporte hace caso omiso del acuse con retraso para mantener el rendimiento de recepción SMTP. Básicamente, el servidor de transporte envía un acuse de recibo antes de que finalice el tiempo de espera.

• Promoción de redundancia de instantáneas En Microsoft Exchange Server 2010 Service Pack 1 (SP1), en lugar de omitir el acuse con retraso, se puede configurar el servidor de transporte para que retransmita el mensaje a cualquier otro servidor de transporte del sitio. De este modo, el mensaje se inserta en el canal de redundancia de instantáneas y el mensaje queda protegido. Este proceso se denomina promoción de redundancia de instantáneas. Este método minimiza la cantidad de mensajes desprotegidos de la organización si se compara con el método de omisión del acuse con retraso. Esta característica se encuentra deshabilitada de forma predeterminada. Para habilitar la promoción de redundancia de instantáneas, un administrador debe editar el archivo Edgetransport.exe.config, cambiar la clave shadowredundancypromotionenabled a true, guardar los cambios en el archivo y, a continuación, reiniciar el servicio de transporte de Microsoft Exchange (MSExchangeTransport.exe). Para obtener más información acerca de cómo hacer esto, consulte la sección "Habilitar la promoción de redundancia de instantánea" en el tema Configurar redundancia de instantáneas.

En la tabla siguiente figuran escenarios hipotéticos en los que un servidor de transporte omite la confirmación con retraso y describe el comportamiento de un servidor de Exchange 2010 en cada caso.

Situación	Comportamiento predeterminado de Exchange 2010 (omisión del acuse con retraso)	Exchange 2010 SP1 con promoción de redundancia de instantáneas habilitada
La cola de destino del mensaje está en estado de reintento o de suspensión.	El servidor de transporte de recepción omite el acuse con retraso.	El servidor de transporte de recepción usa inmediatamente la promoción de redundancia de instantáneas.
La cola de destino pasa al estado de reintento después de habérsele agregado el mensaje.	El servidor de transporte de recepción omite el acuse con retraso en los mensajes subsiguientes hasta que la cola de destino vuelta al estado de listo.	El servidor de transporte de recepción usa la promoción de redundancia de instantáneas en los mensajes subsiguientes hasta que la cola de destino vuelva al estado de listo.
Un administrador suspende la cola de destino o el mensaje.	Si el administrador suspende la cola de destino, el servidor de transporte de recepción omite el acuse con retraso hasta que la cola de destino vuelva al estado de listo. Si el administrador suspende el mensaje, el servidor de transporte de recepción se ocupa de los mensajes subsiguientes de manera normal.	Si el administrador suspende la cola de destino, el servidor de transporte de recepción usa la promoción de redundancia de instantáneas hasta que la cola de destino vuelva al estado de listo. Si el administrador suspende el mensaje, el servidor de transporte de recepción se ocupa de los mensajes subsiguientes de manera normal.
La cola de destino del mensaje tiene más de 100 mensajes.	El servidor de transporte de recepción omite el acuse con retraso hasta que el tamaño de la cola es inferior a 100.	Si hay mensajes en la cola de destino, el servidor de transporte de recepción usa la promoción de redundancia de instantáneas en los mensajes subsiguientes hasta que la cola de destino quede vacía.

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. El parámetro ShadowHeartbeatTimeoutInterval del cmdlet Set-TransportConfig controla el valor del tiempo de espera. La versión enviada a fabricación de Exchange 2010 tiene un valor predeterminado de 300 segundos; en el caso de Exchange 2010 SP1, el valor predeterminado es 900 segundos.

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. Si el valor del tiempo de espera se alcanza doce veces en una fila (tres veces en una fila de Exchange 2010 enviado a fabricación), 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 las 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 esta situación hipotética, no se ha producido ningún error en el servidor de transporte específico pero éste ha estado desconectado durante un periodo de tiempo largo. Por ejemplo, a causa 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. 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, es posible que los destinatarios de sistemas externos 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 dispone 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

 © 2010 Microsoft Corporation. Reservados todos los derechos.