Nuevas funciones de alta disponibilidad y resistencia de sitios

Se aplica a: Exchange Server 2010

Última modificación del tema: 2009-12-08

Microsoft Exchange Server 2010 reduce el costo y la complejidad de implementar una solución de correo electrónico que proporciona los niveles más altos de disponibilidad del servidor y resistencia de sitios. Basada en las capacidades de replicación nativa presentadas en Exchange Server 2007, la nueva arquitectura de alta disponibilidad en Exchange 2010 proporciona un marco simplificado y unificado para una alta disponibilidad y recuperación ante desastres. Exchange 2010 integra la alta disponibilidad en la arquitectura principal de Exchange, lo que permite a clientes de todos los tamaños y en todos los segmentos tener la posibilidad económica de implementar un servicio de mensajería continua.

Lecciones aprendidas de Exchange Server 2007

Exchange 2007 redujo los costos de la alta disponibilidad e hizo que la resistencia de sitio fuera más económica al presentar nuevas tecnologías, como replicación continua local (LCR), replicación continua en clúster (CCR) y replicación continua en espera (SCR). Aún así, quedaban algunos desafíos:

  • Algunos administradores se sentían intimidados por la complejidad del clúster de conmutación por error de Windows.
  • Lograr un alto nivel de tiempo de disponibilidad puede requerir mucha intervención del administrador.
  • Cada tipo de replicación continua estaba administrado de forma diferente y por separado.
  • La recuperación de una falla de una sola base de datos en un servidor de buzones podía resultar en una interrupción temporal del servicio a todos los usuarios del servidor de buzones.
  • Las soluciones de resistencia de sitio no eran simples.
  • La característica de contenedor de transporte de un servidor de transporte de concentradores solamente podía proteger mensajes destinados a buzones de un entorno LCR o CCR. Si un servidor de transporte de concentradores fallaba durante el procesamiento de mensajes y no se podía recuperar, podía producirse la pérdida de los datos.

Exchange 2010 incluye modificaciones principales significativas que integran la alta disponibilidad en la arquitectura, lo que hace que sea más económico y fácil de implementar y mantener que Exchange 2007 para todos los clientes. Las organizaciones ahora pueden implementar una organización Exchange totalmente redundante con sólo dos servidores y beneficiarse de las conmutaciones por error en el nivel de la base de datos. Los clientes obtienen ventajas de las capacidades automáticas de conmutación por error en el nivel de la base de datos sin tener que ser expertos en el clúster de conmutación de Windows. Además, puede agregar, con menor complejidad, resistencia de sitio a sus implementaciones de alta disponibilidad existentes.

Exchange 2007 presentó muchas modificaciones de arquitectura diseñadas para que la implementación de las soluciones de alta disponibilidad y resistencia de sitio para Exchange sea más rápida y simple. Estas mejoras incluyen una experiencia de instalación integrada, opciones de configuración inicial optimizadas y la posibilidad de administrar la mayoría de los aspectos de la solución de alta disponibilidad mediante herramientas de administración nativas de Exchange.

Aún así, la administración de una solución de alta disponibilidad de Exchange 2007 requería que los administradores dominaran algunos conceptos de clúster, como el concepto de mover identidades de red y administrar recursos de clúster. Además, al solucionar problemas relacionados con un servidor de buzones en clúster, el administrador tenía que usar herramientas de Exchange y herramientas de clúster para revisar y correlacionar registros y eventos de dos fuentes diferentes: Exchange y el clúster.

También se volvieron a evaluar y diseñar otros dos aspectos limitantes de la arquitectura de Exchange 2007, según los comentarios de los clientes:

  • Los servidores en clúster de Exchange 2007 requieren hardware dedicado. Sólo se puede instalar el rol de servidor Buzón de correo en un nodo, en el clúster. Esto significa que se necesitaba un mínimo de cuatro servidores Exchange para lograr total redundancia de los componentes primarios de una implementación, es decir, los roles de servidor principales (Buzón de correo, Transporte de concentradores y Acceso de clientes).
  • En Exchange 2007, se produce la conmutación por error de un servidor de buzones en clústeres en el nivel de servidor. Como resultado, si se producía una sola falla en la base de datos, el administrador tenía que conmutar todo el servidor de buzones en clústeres a otro nodo del clúster (lo que resultaba en un breve período de inactividad para todos los usuarios del servidor y no solamente para aquellos usuarios con un buzón en la base de datos afectada), o dejar sin conexión a los usuarios de la base de datos con fallas (tal vez por horas) mientras se restauraba la base de datos desde la copia de seguridad.

Resistencia del buzón

Exchange 2010 se volvió a diseñar en torno al concepto de resistencia del buzón, se cambió la arquitectura de manera que la protección de la conmutación automática por errores ahora se proporciona en el nivel de la base de datos de buzones de correo individual en lugar de ser en el nivel del servidor. En Exchange 2010, esto se conoce como movilidad de base de datos. Como resultado de esto y otras modificaciones en la caché de la base de datos de arquitectura, las acciones de conmutación ahora se completan más rápido que en las versiones previas de Exchange. Por ejemplo, la conmutación de un servidor de buzones en clústeres de un entorno CCR que ejecuta Exchange 2007 con Service Pack 2 (SP2) se completa en alrededor de dos minutos. En comparación, la conmutación de una base de datos de buzones de correo en un entorno Exchange 2010 se completa en 30 segundos o menos (desde el momento en que se detecta la falla hasta que se monta la copia de la base de datos, con la presunción de que hay una copia disponible que está en buen estado y actualizada con la reproducción de registros). La combinación de la conmutación por errores en el nivel de la base de datos y los tiempos de conmutación significativamente más rápidos mejora en forma importante el tiempo de producción general de una organización.

La arquitectura de resistencia del buzón incorporada en Exchange 2010 ofrece nuevos beneficios para las organizaciones y sus administradores de mensajería:

  • Varios roles de servidor pueden coexistir en los servidores que proporcionan alta disponibilidad. Esto permite a las pequeñas organizaciones implementar una configuración de dos servidores que proporciona redundancia de datos de buzón y servicio, mientras que también ofrece servicios de acceso de cliente y de transporte de concentradores.
  • Un administrador ya no necesita construir un clúster de conmutación por error para lograr alta disponibilidad. Los clústeres de conmutación por error ahora se crean en Exchange 2010 de manera visible para el administrador. A diferencia de las versiones anteriores de los clústeres de Exchange que usaban una D‎LL de recurso de clúster de Exchange llamada ExRes.dll, Exchange 2010 ya no necesita o no usa una DLL de recurso de clúster. Exchange 2010 no es una aplicación de clústeres no es una aplicación agrupada y usa solamente una pequeña porción de los componentes de clúster de conmutación por error, en particular, funciones de latido y base de datos de clúster, para ofrecer movilidad de base de datos.
  • Los administradores pueden agregar alta disponibilidad a su entorno Exchange 2010 después de haber implementado Exchange, sin tener que desinstalar Exchange y volver a implementar la configuración de alta disponibilidad.
  • Exchange 2010 ofrece una vista de la secuencia de eventos que fusiona y combina los eventos del sistema operativo con eventos de Exchange.
  • Debido a que ya no existen los objetos del grupo de almacenamiento en Exchange 2010 y a que las bases de datos de buzones de correo se pueden transportar a través de todos los servidores de buzones de Exchange 2010, mover bases de datos cuando es necesario resulta fácil.

Para obtener más información, consulte Alta disponibilidad y resistencia de sitios.

Protección flexible de buzón

Exchange 2010 incluye varias nuevas funciones y cambios principales que, cuando se implementan y configuran de manera correcta, pueden ofrecer protección flexible de buzón que elimina la necesidad de realizar copias de seguridad tradicionales de sus datos. Con las funciones de alta disponibilidad incorporadas en Exchange 2010 para minimizar el tiempo de inactividad y la pérdida de datos en caso de un desastre, también se puede reducir el costo total de propiedad del sistema de mensajería. Al combinar esas características con otras características integradas, como Retención legal, las organizaciones pueden reducir o eliminar la dependencia en copias de seguridad tradicionales hasta un momento dado y darse cuenta de lo que ahorran con eso.

Además de determinar si Exchange 2010 le permite cambiar las copias de seguridad tradicionales hasta un momento dado, también le recomendamos que evalúe el costo de la infraestructura actual de copias de seguridad. Considere el costo del tiempo de inactividad de los usuarios finales y la pérdida de datos al intentar recuperarse de un desastre con la infraestructura de copia de seguridad actual. Además, incluya costos de hardware, instalación y licencia, y los costos de administración asociados con la recuperación de datos y el mantenimiento de las copias de seguridad. Según los requisitos de la organización, es posible que un entorno Exchange 2010 puro con al menos tres copias de bases de datos de buzones de correo ofrezca un menor costo total de propiedad que uno con copias de seguridad.

Para obtener más información acerca de la protección flexible de buzón, consulte Descripción de la copia de seguridad, restauración y recuperación ante desastres.

Cambios en la alta disponibilidad de versiones anteriores de Exchange

Exchange 2010 incluye numerosos cambios en su arquitectura principal. Exchange 2010 combina las características de disponibilidad y resistencia claves de CCR y SCR en una sola solución de alta disponibilidad que maneja la replicación de datos en el sitio y fuera del sitio. Los servidores de buzones pueden definirse como parte del grupo de disponibilidad de base de datos (DAG) para proporcionar recuperación automática en el nivel de la base de datos de buzones de correo individual en lugar de ser en el nivel del servidor. Cada base de datos de buzones de correo puede tener hasta 16 copias. En Exchange 2010 se presentan nuevos conceptos de alta disponibilidad, como movilidad de base de datos e implementación incremental. Los conceptos de una organización sin copias de seguridad y RAID también se presentan en Exchange 2010.

Para resumir, los aspectos principales para la disponibilidad de los datos y los servicios del rol de servidor Buzón de correo y las bases de datos de buzones de correo son las siguientes:

  • Exchange 2010 usa una versión mejorada de la misma tecnología de replicación continua presentada en Exchange 2007. Para obtener más información, consulte Cambios en la replicación continua de Exchange Server 2007 que aparece más adelante en este tema.
  • Los grupos de almacenamiento ya no existen en Exchange 2010. En su lugar, simplemente hay bases de datos de buzones de correo, copias de bases de datos de buzones y bases de datos de carpetas públicas. Las interfaces de administración primara para bases de datos de Exchange se movieron dentro de la Consola de administración de Exchange desde el nodo Buzón de correo de Configuración de servidores al nodo Buzón de correo de Configuración de la organización.
  • La tecnología de clúster de conmutación por error de Windows se usa en Exchange 2010, pero ahora Exchange la administra totalmente. Los administradores no tienen que instalar, crear o configurar ningún aspecto del clúster de conmutación por error al implementar servidores de buzones disponibles de alta disponibilidad.
  • Cada servidor de buzones puede alojar hasta 100 bases de datos y cada base de datos puede tener hasta 16 bases de datos.
  • Se ha agregado a la característica del contenedor de transporte, una nueva característica de servidor de transporte de concentradores llamada redundancia de instantáneas. La redundancia de instantáneas proporciona redundancia para mensajes en todo el tiempo en que están en tránsito. La solución implica una técnica similar para el contenedor de transporte. Con la redundancia de instantáneas, la eliminación de un mensaje de la base de datos de transporte se retrasa hasta que el servidor de transporte verifica que todos los saltos siguientes de ese mensaje tengan entrega completa. Si alguno de los próximos saltos falla antes de informar el éxito de la entrega, el mensaje se reenvía para entregar en el próximo salto. Para obtener más información acerca de la redundancia de instantáneas, consulte Descripción de redundancia de instantánea.

Implementación incremental

En las versiones anteriores de Exchange, la disponibilidad de los roles de servidor Buzón de correo se lograba mediante la implementación de Exchange en un clúster de conmutación por error de Windows. Para implementar Exchange en un clúster, primero tiene que crear un clúster de conmutación por error y luego instalar los archivos de programa de Exchange. Este proceso crea un servidor de buzones especial llamado servidor de buzones en clústeres (o Servidor virtual de Exchange en versiones anteriores de Exchange). Si ya instaló los archivos de programa de Exchange en un servidor no clúster y decidió que quiere un servidor de buzones en clústeres, debe crear un clúster con nuevo hardware o eliminar Exchange del servidor existente, instalar un clúster de conmutación por error y volver a instalar Exchange.

Exchange 2010 presenta el concepto de implementación incremental, lo que le permite implementar disponibilidad de servicio y de datos para bases de datos y servidores de buzones una vez que Exchange está instalado. La redundancia de servicios y datos se logra mediante nuevas características de Exchange 2010, como DAG y copias de bases de datos.

Grupos de disponibilidad de base de datos

Un DAG es un conjunto de hasta 16 servidores de buzones que proporciona recuperación automática en el nivel de la base de datos de fallas que afectan bases de datos individuales. Cualquier servidor en un DAG puede alojar una copia de una base de datos de buzones de correo de cualquier otro servidor en el DAG. Cuando se agrega un servidor a un DAG, funciona con otros servidores en el DAG para proporcionar recuperación automática de fallas que afectan las bases de datos de buzones de correo, como una falla en el disco o en el servidor.

Para obtener más información acerca de los DAG, consulte Descripción de grupos de disponibilidad de base de datos.

Copias de bases de datos de buzones de correo

Las características de alta disponibilidad y resistencia de sitio presentadas por primera vez en Exchange 2007 se usan en Exchange 2010 para crear y mantener copias de bases de datos, lo que le permite lograr sus metas de disponibilidad en Exchange 2010. Exchange 2010 también presenta el nuevo concepto de movilidad de base de datos, que es la conmutación por error en el nivel de la base de datos administrada por Exchange.

La movilidad de base de datos desconecta a las bases de datos de los servidores, agrega soporte para hasta 16 copias de una sola base de datos y ofrece una experiencia nativa para agregar copias de bases de datos a una base de datos. En Exchange 2007, una característica llamada portabilidad de base de datos también le permite mover una base de datos de buzones de correo entre servidores. Sin embargo, una distinción clave entre la portabilidad de base de datos y la movilidad de base de datos es que con la última todas las copias de una base de datos tienen el mismo GUID.

Otras características claves de la movilidad de base de datos son las siguientes:

  • Debido a que los grupos de almacenamiento se eliminaron de Exchange 2010, la replicación continua ahora funciona en el nivel de la base de datos. En Exchange 2010, los registros de transacciones se replican a uno o más servidores de buzones y se reproducen en una copia de una base de datos de buzones de correo que está almacenada en esos servidores.
  • Una conmutación por error es un proceso de activación automático que puede ocurrir en el nivel de las bases de datos o de los servidores. Un cambio es un proceso de activación manual que puede realizar en el nivel de la base de datos, del servidor o del centro de cliente (sitio).
  • Los nombres de las base de datos para Exchange 2010 deben ser únicos dentro de la organización de Exchange.
  • Cuando una base de datos de buzones de correo se configuró con una o más copias de base de datos, la ruta completa para todas las copias de bases de datos debe ser idéntica en todos los servidores de buzones que alojan una copia.
  • Se puede realizar una copia de seguridad de cualquier copia de base de datos de buzones de correo (la copia activa o cualquier copia pasiva) mediante una aplicación de copia de seguridad de Servicio de instantáneas de volumen (VSS) de la cual Exchange tiene conocimiento.

Para obtener más información acerca de las copias de bases de datos de buzones de correo, consulte Descripción de copias de bases de datos de buzones de correo.

Cambios en la replicación continua de Exchange Server 2007

La tecnología de replicación continua subyacente que estaba en CCR y SCR continúa en Exchange 2010 y evolucionó para dar soporte a las nuevas características de alta disponibilidad, como copias de bases de datos, movilidad de base de datos y DAG. Algunos de estos nuevos cambios de arquitectura se describen brevemente a continuación:

  • Debido a que los grupos de almacenamiento se eliminaron de Exchange 2010, la replicación continua ahora funciona en el nivel de la base de datos. Exchange 2010 todavía usa una base de datos de motor de almacenamiento extensible (ESE) que produce registros de transacciones que se replican a una o más ubicaciones y se reproducen en una o más copias de base de datos de buzones de correo.
  • Debido a que la funcionalidad de reproducción de registros que realizaba el servicio de replicación de Microsoft Exchange en Exchange 2007 se movió a la versión de Exchange 2010 del servicio Almacén de información de Microsoft Exchange (store.exe), la disminución del rendimiento asociada con conmutaciones por error y cambios de conexión (porque la caché de la base de datos se ponía en uso) ya no existe. Cuando se produce una conmutación por error o un cambio, la base de datos activada tiene una caché en caliente lista para usar.
  • El trasvase de registros y la propagación ya no usan el bloque de mensajes del servidor (SMB) para la transferencia de datos. La replicación continua de Exchange 2010 usa un solo puerto TCP definido por el administrador para la transferencia de datos. Además, Exchange 2010 incluye opciones integradas para el cifrado y la compresión de la red para la secuencia de datos.
  • El trasvase de registros ya no usa un modelo de extracción, donde la copia pasiva extrae de la copia activa los archivos de registro cerrados. En su lugar, la copia activa expulsa los archivos de registro a cada copia pasiva configurada.
  • La propagación ya no está restringida al uso de la copia activa de la base de datos. Las copias pasivas de bases de datos de buzones de correo ahora pueden especificarse como fuentes para la propagación y repropagación de copias de bases de datos.
  • Las copias de bases de datos sólo se ofrecen para bases de datos de buzones de correo. Para la redundancia y la alta disponibilidad de las bases de datos de carpetas públicas, recomendamos usar la replicación de carpetas públicas. A diferencia de CCR, donde no podía haber varias copias de una base de datos de carpeta pública en el mismo clúster, puede usar la replicación de carpeta pública para replicar bases de datos de carpeta pública entre servidores en un DAG.

Varios conceptos usados en la replicación continua de Exchange 2007 también están presentes en Exchange 2010. Entre ellos se incluyen los conceptos de administración de conmutación por error, divergencia, el luso de Marcado de montaje de base de datos automático y el uso de redes públicas y privadas.

Cambios en el comportamiento de enrutamiento al ubicar Transportador de concentradores y Buzón de correo en un DAG

Cuando el servidor de transporte de concentradores se ubica junto con un servidor de buzones que es miembro de un DAG, se producen cambios en el comportamiento del enrutamiento para asegurar que las características de resistencia en los dos roles de servidor proporcionarán la protección necesaria para los mensajes enviados y recibidos por usuarios de ese servidor. El rol del servidor Transporte de concentradores se modificó de manera que ahora intenta volver a enrutar un mensaje para el servidor de buzones local a otro servidor de transporte de concentradores en el mismo sitio, si el servidor de transporte de concentradores también es miembro del DAG y tiene una copia de la base de datos de buzones de correo montada localmente. Este salto adicional se agregó para colocar el mensaje en el contenedor de transporte de un servidor de transporte de concentradores diferente.

Por ejemplo, EX1 aloja los roles de servidor Transporte de concentradores y Buzón de correo, y es miembro de un DAG. Cuando llega un mensaje en transporte para EX1 que es para un destinatario cuyo buzón también está en EX1, el transporte vuelve a enrutar el mensaje a otro servidor de transporte de concentradores en el sitio (por ejemplo, EX2), y ese servidor entregará el mensaje al buzón de EX1.

Hay un segundo cambio de comportamiento similar con respecto al Servicio de entrega de correo de Microsoft Exchange. Este servicio se modificó para que prefiera no enviar mensajes a la función de transporte de concentradores local cuando el servidor de buzones y de transporte de concentradores es miembro de un DAG. En este escenario, el comportamiento del transporte es equilibrar la carga de solicitudes de entrega entre otros servidores de transporte de concentradores del mismo sitio de Active Directory y revertirlas al servidor de transporte de concentradores si no hay otros servidores de transporte de concentradores disponibles al mismo tiempo.

Disponibilidad de un extremo a otro

Exchange 2010 también incluye muchas características diseñadas para aumentar la disponibilidad de un extremo a otro del sistema. Entre estas características se incluyen:

  • Resistencia de transporte
  • Movimiento del buzón en línea
  • Protección nativa de datos de Exchange
  • Resincronización incremental
  • API de replicación de terceros

Resistencia de transporte

Exchange 2007 introdujo la característica de contenedor de transporte del servidor de transporte de concentradores. El contenedor de transporte mantiene una cola de mensajes que se entregaron a destinatarios cuyos buzones estaban en un entorno CCR (y en Exchange 2007 SP1, en un LCR). Esta característica se diseñó para ayudar con la protección contra la pérdida de datos al proporcionar al administrador la opción de poner en línea de manera automática un servidor de buzones en clústeres en otro nodo con una cantidad de pérdida de datos limitada. Esto se llama conmutación por error con pérdidas. Cuando se producía una conmutación por error con pérdidas, el sistema volvía a enviar de manera automática los mensajes de correo recientemente enviados a los usuarios del servidor de buzones en clúster con fallas, mediante el contenedor de transporte donde los mensajes de correo todavía estaban almacenados. Si bien esta solución ayudaba a minimizar la cantidad de pérdida de datos en una conmutación por error con pérdidas, la solución solamente protegía a los datos dentro del sitio y no a los mensajes en tránsito.

Exchange 2010 presenta los principales cambios de arquitectura que solucionan ambos problemas. Debido a que los DAG pueden estirarse a través de los sitios de Active Directory, una base de datos de buzones de correo puede moverse entre sitios de Active Directory. Gracias a este cambio de diseño, la solicitud de reenvío del contenedor de transporte sobre una conmutación por error con pérdidas de base de datos ahora se envía a servidores de transporte de concentradores en el sitio de Active Directory original de la base de datos y el nuevo.

Otro cambio importante del contenedor de transporte es que ahora recibe comentarios del proceso de replicación. Los mensajes se eliminan del contenedor de transporte una vez que se replicaron a todas las copias de base de datos de buzones de correo. Esto garantiza que sólo los datos no replicados se mantengan en el contenedor de transporte.

Se ha agregado a la característica del contenedor de transporte, una nueva característica de servidor de transporte de concentradores llamada redundancia de instantáneas. La redundancia de instantáneas proporciona redundancia para mensajes en todo el tiempo en que están en tránsito. La solución implica una técnica similar para el contenedor de transporte. Con la redundancia de instantáneas, la eliminación de un mensaje de la base de datos de transporte se retrasa hasta que el servidor de transporte verifica que todos los saltos siguientes de ese mensaje tengan entrega completa. Si alguno de los próximos saltos falla antes de informar el éxito de la entrega, el mensaje se reenvía para entregar en el próximo salto. Para obtener más información acerca de la redundancia de instantáneas, consulte Descripción de redundancia de instantánea.

Movimiento del buzón en línea

Exchange 2010 incluye una nueva característica que le permite mover los buzones de forma asincrónica. En Exchange 2007, cuando usaba el cmdlet Move-Mailbox para mover un buzón, el cmdlet se registraba en la base de datos de origen y en la de destino y movía el contenido de un buzón a otro. Había varias desventajas al hacer que los cmdlets realicen la operación de movimiento:

  • Los movimientos de los buzones tardaban horas en completarse y, mientras tanto, los usuarios no podían obtener acceso a sus buzones.
  • Si la ventana de comando usada para ejecutar el cmdlet Move-Mailbox se cerraba, se finalizaba el movimiento y debía volver a iniciarse desde el principio.
  • El equipo usado para realizar el movimiento participaba en el traslado de datos. Si un administrador ejecutaba cmdlets desde su estación de trabajo, los datos del buzón fluían desde el servidor de origen a la estación de trabajo del administrador y, después, al servidor de destino.

Los nuevos cmdlets de solicitud de movimiento de Exchange 2010 pueden usarse para realizar movimientos asincrónicos. A diferencia de Exchange 2007, los cmdlets no realizan el traslado real. El movimiento lo realiza el Servicio de replicación de buzones de Microsoft Exchange, un nuevo servicio que se ejecuta en el servidor de acceso de cliente. El cmdlet New-MoveRequest envía solicitudes al servicio de replicación de buzones. Para obtener más información acerca del movimiento de buzón en línea, consulte Descripción de solicitudes de movimiento.

Protección nativa de datos de Exchange

Hay varias modificaciones en la arquitectura principal de Exchange 2010 que producen un efecto directo en la manera de proteger las bases de datos de buzones de correo y los buzones de correo que contienen.

Un cambio significativo es la eliminación de grupos de almacenamiento. En Exchange 2010, cada base de datos está asociada con una secuencia de registro, representada por una serie de archivos de registro de 1 MB. Cada servidor puede alojar un máximo de 100 bases de datos.

Otro cambio significativo para Exchange 2010 es que las bases de datos ya no están estrechamente vinculadas con un servidor de buzones específicos. La movilidad de la base de datos expande el uso continuo del sistema de la replicación, al replicar una base de datos a varios servidores diferentes. Esto proporciona una mejor protección de la base de datos y una mayor disponibilidad. En caso de que se produzcan fallas, los otros servidores que tienen copias de la base de datos pueden montar la base de datos.

La posibilidad de tener varias copias de una base de datos alojada en múltiples servidores, significa que si tiene una cantidad suficiente de copias de bases de datos, puede usarlas como copias de seguridad. Para obtener más información acerca de esta estrategia, consulte Descripción de la copia de seguridad, restauración y recuperación ante desastres.

Resincronización incremental

Exchange 2007 introdujo los conceptos de resistencia del registro perdido (LLR) y reinicialización incremental. LLR es un componente interno de ESE que le permite recuperar bases de datos de buzones de correo de Exchange incluso si se perdió o se dañó uno o más archivos de registro generados recientemente. LLR permite que una base de datos de buzones de correo se monte incluso si los archivos de registro generados recientemente no están disponibles. LLR funciona retrasando las escrituras en la base de datos hasta que se haya creado el número especificado de generaciones de registro. LLR retrasa las actualizaciones recientes de la base de datos durante un breve período. El tiempo que se retrasan las escrituras depende de la velocidad a la que se generen los registros.

Nota

LLR está codificado de forma rígida para todas las bases de datos de buzones de correo de Exchange 2010.

La reinicialización incremental proporcionaba la posibilidad de corregir divergencias en la secuencia de registros de transacciones entre un grupo de almacenamiento de origen y uno de destino, al depender de las funciones de respuesta con retraso de LLR. La reinicialización incremental no proporcionaba un medio para corregir divergencias en la copia pasiva de una base de datos después de que se respondidos los registros de divergencia, lo que obligaba a realizar una reinicialización completa.

En Exchange 2010, resincronización incremental es el nuevo nombre para la característica que corrige divergencias de manera automática en copias de bases de datos, en las siguientes condiciones:

  • Después de una conmutación por error automática de todas las bases de datos configuradas.
  • Cuando se habilita una nueva copia y ya existen algunas bases de datos y archivos de registro en la ubicación de la copia.
  • Cuando se reanuda una replicación después de una suspensión o reinicio del Servicio de replicación de Microsoft Exchange.

Cuando se detecta una divergencia entre una base de datos activa y una copia de esa base de datos, la resincronización incremental realiza las siguientes tareas:

  • Busca el historial en la secuencia de archivos de registro para ubicar el punto de divergencia.
  • Ubica las páginas de bases de datos cambiadas en la copia divergente.
  • Lee las páginas cambiadas de la copia activa y copia los archivos de registro necesarios de la copia activa.
  • Aplica los cambios de la página de la base de datos a la copia divergente.
  • Ejecuta una recuperación en la copia divergente y vuelve a reproducir los archivos de registro necesarios en la copia de la base de datos.

API de replicación de terceros

Exchange 2010 también incluye una nueva API de replicación de terceros que permite a las organizaciones usar soluciones de replicación sincrónica de terceros en lugar de la característica integrada de replicación continua. Para obtener información sobre productos de asociados para Exchange 2010, consulte Asociados de Exchange 2010. Si usted es un asociado y busca información sobre la API de replicación de terceros, contáctese con su representante de Microsoft.

Características eliminadas de Exchange Server 2007

Las siguientes características de Exchange 2007 y Exchange 2007 SP1 ya no existen en Exchange 2010. Sus reemplazos se indican en la tabla.

Característica

Reemplazo

Replicación continua en clúster (CCR)

Grupos de disponibilidad de bases de datos y copias de bases de datos de buzones de correo

Replicación continua en espera (SCR)

Grupos de disponibilidad de bases de datos y copias de bases de datos de buzones de correo

Replicación continua local (LCR)

Grupos de disponibilidad de bases de datos y copias de bases de datos de buzones de correo

Clústeres de copia única (SCC)

Grupos de disponibilidad de bases de datos y copias de bases de datos de buzones de correo; API sincrónica de terceros integrada disponible para sustituir la replicación de datos de terceros usada con SCC.

Servidor de buzones en clústeres

Grupos de disponibilidad de bases de datos y copias de bases de datos de buzones de correo

Grupos de almacenamiento

Bases de datos

Grupo de almacenamiento de recuperación

Base de datos de recuperación