replicación continua de clústeres

Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Última modificación del tema: 2008-03-21

La replicación continua en clúster (CCR) es una función de alta disponibilidad de Microsoft Exchange Server 2007 que combina la tecnología asincrónica de trasvase y reproducción de registros integrada en Exchange 2007 con las características de conmutación por error y administración proporcionadas por el servicio de clúster.

La CCR se ha diseñado para ofrecer una máxima disponibilidad para los servidores de buzón de Exchange 2007 al proporcionar una solución que:

• No tiene un solo error puntual.

• No tiene requisitos especiales de hardware.

• No tiene requisitos de almacenamiento compartido.

• Puede implementarse en una o dos configuraciones de centro de datos.

• Puede reducir la frecuencia de realización de copias de seguridad completas, reducir el volumen total de datos de copias de seguridad y acortar el acuerdo de nivel de servicio (SLA) para el tiempo de recuperación desde el primer error.

La CCR usa la funcionalidad de recuperación de errores de bases de datos de Exchange 2007 para permitir la actualización continua y asincrónico de una segunda copia de una base de datos con los cambios realizados en la copia activa de la base de datos. Durante la instalación del nodo pasivo en un entorno CCR, cada grupo de almacenamiento y su base de datos se copian del nodo activo al nodo pasivo. Esta operación se denomina reinicialización y ofrece una línea de base de la base de datos para la replicación. Una vez realizada la reinicialización inicial, se realiza continuamente la copia y reproducción de registros.

En un entorno CCR, las capacidades de replicación se integran con el servicio de clústeres para ofrecer una solución de alta disponibilidad. Además de ofrecer una disponibilidad de datos y servicios, la CCR ofrece también interrupciones programadas. Cuando sea necesario instalar actualizaciones o llevar a cabo servicios de mantenimiento, el administrador puede mover manualmente un servidor de buzones de correo en clúster (denominado Exchange servidor virtual en versiones anteriores de Exchange Server) a un nodo pasivo. Una vez completada la operación de movimiento, el administrador puede realizar el mantenimiento necesario.

La operación de movimiento se realiza usando el cmdlet Move-ClusteredMailboxServer del Shell de administración de Exchange. Microsoft Exchange Server 2007 Service Pack 1 (SP1) incluye también un nuevo Asistente para administrar servidores de buzones de correo en clúster en la Consola de administración de Exchange que puede usarse para mover servidores de buzones de correo en clúster. La lógica usada por estas tareas realiza el cumplimiento necesario para asegurarse de que no se pierda ningún dato del buzón durante el movimiento. Las tareas también realizan comprobaciones antes del movimiento para asegurarse de que la replicación del nodo pasivo está preparada para activarse rápidamente.

Los hechos fundamentales sobre CCR son los siguientes:

• La replicación continua es asincrónica   Los registros no se copian hasta que se cierran y no siguen utilizándose en el servidor de buzones. Esto significa que el nodo pasivo normalmente no tiene una copia de todos los archivos de registro que hay en el nodo activo. La excepción es cuando el administrador ha iniciado un corte programado del nodo activo para aplicar una actualización o realizar cualquier otra tarea de mantenimiento.

• La replicación continua apenas coloca carga de CPU y de entrada/salida (E/S) en el nodo activo durante el funcionamiento normal   CCR usa el nodo pasivo para copiar y reproducir los registros. Puede obtener acceso a los registros mediante el nodo pasivo a través de un recurso compartido de archivos seguro.

• Los cambios del nodo activo y pasivo a lo largo de la vigencia del clúster se designan automáticamente   Por ejemplo, después de una conmutación por error, la designación activa y pasiva se invierte. Esto quiere decir que la dirección de replicación se invierte. No es necesaria ninguna acción administrativa para invertir la replicación. El sistema administra automáticamente la replicación inversa.

• La conmutación por error y las interrupciones programadas son simétricas en función y rendimiento   Por ejemplo, la conmutación por error del Nodo1 al Nodo2 dura tanto como la conmutación por error del Nodo2 al Nodo1. Normalmente, tardará menos de dos minutos. En servidores grandes, las interrupciones programadas tardarán por norma general menos de cuatro minutos. La diferencia de tiempo entre una conmutación por error y las interrupciones programadas está asociada con el tiempo que tarda un apagado controlado del nodo activo en una interrupción programada. Esta diferencia de rendimiento puede reducirse en un Service Pack próximo.

• Pueden realizarse copias de seguridad del Servicio de instantáneas de volumen (VSS) en el nodo pasivo   Esto permite a los administradores descargar copias de seguridad del nodo activo y ampliar la ventana de copia de seguridad. Asimismo, los requisitos de rendimiento no necesitan grandes configuraciones para que el VSS de hardware pueda usar copias de seguridad de VSS. La carga de trabajo del nodo pasivo consiste en primer lugar en copiar y reproducir registros, donde ninguna de estas funciones está limitada en tiempo real como el servidor de buzones de correo en clúster del nodo activo. Por ejemplo, el nodo activo tiene que responder a las solicitudes de clientes de forma puntual. Puede usarse una ventana de copia de seguridad mayor, ya que el nodo pasivo no tiene limitaciones de respuesta en tiempo real, lo que permite bases de datos y buzón más grandes.

• Los datos totales del medio de copia de seguridad se reducen   La copia pasiva de CCR proporciona la primera línea de defensa frente a daños y la pérdida de datos. De ese modo, será necesario un error doble antes de que se necesiten las copias de seguridad. La recuperación del primer error puede tener un SLA relativamente corto ya que no es necesario realizar una restauración. La recuperación del segundo error puede tener un SLA mucho mayor. Como resultado, las copias de seguridad pueden realizarse en un ciclo completo semanal con una estrategia de copia de seguridad incremental diaria. Esto reduce el volumen total de datos que debe colocarse en el medio de copia de seguridad.

• CCR se puede combinar con la replicación continua en espera (SCR)   CCR se puede combinar con SCR para replicar grupos de almacenamiento de forma local en un centro de datos primario (usando CCR para alta disponibilidad) y de forma remota en un centro de datos secundario o de copia de seguridad (usando SCR para resistencia del sitio). El centro de datos secundario podría contener un nodo pasivo en un clúster de conmutación por error que hospeda los destinos para SCR. Este tipo de clúster se conoce como clúster en suspensión, porque no contiene servidores de buzones de correo en clúster, sino que se puede proveer rápidamente con un servidor de buzones de correo en clúster de sustitución en un escenario de recuperación. Si el centro de datos principal produce un error o se pierde por algún otro motivo, los destinos para SCR hospedados en este clúster en suspensión se pueden activar rápidamente en el clúster en suspensión.

Arquitectura básica de CCR

La CCR combina los siguientes elementos:

• Características de virtualización y conmutación por error proporcionadas por los clústeres de conmutación por error de Microsoft.

• Modelo de quórum de clúster de conmutación por error basado en mayorías que usa recursos compartidos de archivos como testigo de la actividad del clúster

• Características de replicación y reproducción del registro de transacciones de Exchange 2007.

• Característica de cola de mensajes del servidor de transporte de concentradores denominada contenedor de transporte

Clúster de conmutación por error de Windows

Como se muestra en la figura siguiente, en Exchange 2007 SP1, la CCR usa dos equipos (denominados nodos) unidos en un único clúster de conmutación por error que ejecuta Windows Server 2003 Service Pack 2 o Windows Server 2008. Los nodos del clúster de conmutación por error hospedan un servidor de buzones de correo en clúster único. Un nodo que ejecuta actualmente un servidor de buzón en clústeres se denomina nodo activo, mientras que un nodo que no ejecuta ningún servidor de buzón en clústeres, pero forma parte del clúster, y el destino de una replicación continua, se denomina nodo pasivo. Como resultado de los cortes programados por mantenimiento y no programados, la designación de un nodo como activo o pasivo cambiará varias veces durante la vigencia del clúster de conmutación por error.

Implementación básica de CCR

El clúster de conmutación por error se integra mediante el servicio de clúster y un tipo específico de modelo de quórum de clúster:

• En Windows Server 2008, el quórum recomendado se denomina Mayoría de recurso compartido de archivos y nodo. Para obtener información detallada sobre cómo configurar un clúster de conmutación por error para usar el modelo de quórum de nodos y recursos compartidos de archivos mayoritarios, consulte Cómo configurar el quórum Mayoría de recursos compartidos de archivo y nodo.

• En Windows Server 2003, el quórum recomendado se denomina Conjunto de nodos mayoritario (MNS) con testigo del recurso compartido de archivos. Este modelo de quórum está disponible en Windows Server 2003 Service Pack 2 (SP2). También está disponible en una revisión de Windows Server 2003 descrita en el artículo 921181 de Microsoft Knowledge Base, Está disponible una actualización que agrega una característica de testimonio compartido de archivo y una característica de latidos configurables agrupados para clústeres de servidores basados en Microsoft Windows Server 2003 Service Pack 1; sin embargo, Exchange 2007 SP1 necesita Windows Server 2003 Service Pack 2.

Testigo de recurso compartido

Ambos modelos de quórum anteriores usan un recurso compartido de archivos en un tercer equipo como testigo. En estos modelos de quórum, se usa un recurso compartido de archivos en un tercer equipo para evitar que se produzca una partición de la red dentro del clúster, lo que se conoce también como síndrome de cerebro dividido. El síndrome de cerebro dividido se produce cuando dejan de funcionar todas las redes designadas para transportar las comunicaciones internas del clúster y los nodos no pueden recibir señales de latido entre ellos. Para impedir dicho síndrome, es preciso requerir siempre que la mayor parte de los nodos y el recurso compartido de archivos estén disponibles e interactúen para que el servidor de buzones de correo en clúster esté operativo. Si éste es el caso, se dice que el clúster tiene un quórum. El recurso compartido de archivos para el testigo de recurso compartido de archivos se puede hospedar en cualquier equipo que ejecute Windows Server. No es necesario que la versión del sistema operativo Windows Server que hospeda el recurso compartido de archivos coincida con el sistema operativo del entorno de la CCR. Sin embargo, es recomendable que use un servidor de transporte de concentradores en el sitio del servicio de directorio de Active Directory que contiene el servidor de buzones de correo en clúster para hospedar el recurso compartido de archivos, porque esto permite que un administrador de mensajería mantenga el control sobre el recurso compartido de archivos.

El testigo de recurso compartido de archivos usa el recurso compartido de archivos en un equipo externo al clúster para actuar como un testigo de las actividades de los dos nodos que forman el clúster. Ambos nodos usan el testigo para realizar el seguimiento del nodo que controla el clúster. Este tablero de notas sólo es necesario cuando no existe comunicación entre los nodos. Considere un servidor de buzones de correo en clúster de dos nodos compuesto por Nodo1 y Nodo2. En este caso, Nodo1 es el nodo que puede tomar el control del tablón de notas y, por tanto, el control del clúster y mostrar el servidor de buzones de correo en clúster. Si Nodo2 está operativo, pero no puede establecer comunicación con Nodo1, el Nodo2 tomará el control del tablón de notas y del error. La incapacidad del Nodo2 para controlar el tablón de notas significa que no debe mostrar un servidor de buzones de correo en clúster.

Cuando ambos nodos pueden interactuar entre sí, ya no es necesario el tablero de notas y éste puede desactivarse. Sin embargo, el posterior error de cualquier nodo impedirá que esté en línea el servidor de buzones de correo en clúster si no está disponible el testigo de recurso compartido de archivos.

El recurso compartido de archivos no se mantiene en ningún otro estado más que en el anteriormente descrito. Por lo tanto, toda la información de configuración de clúster se intercambia entre los dos nodos. Es fundamental comprender esta cuestión ya que significa que si sólo está disponible el Nodo1, el Nodo2 no lo estará hasta que establezca comunicación con el Nodo1, incluso si puede comunicar con el testigo de recurso compartido de archivos.

El soporte de testigo de recurso compartido de archivos proporciona comprobación periódica del acceso de dicho testigo. Si no se pudo comprobar el acceso, se generará un evento. El sistema de supervisión puede recopilar, detectar e informar sobre el evento. Esto permite al personal de operaciones corregir el problema antes de que éste provoque una interrupción como consecuencia de un segundo error simultáneo.

Es posible tener acceso al recurso compartido de archivos bajo las siguientes condiciones:

• Si aparece un nodo de clúster y sólo hay uno disponible.

• Si un problema de conexión de red impide la comunicación con el clúster de un nodo al que anteriormente sí se podía tener acceso.

• Si un nodo de clúster abandona el clúster.

• Periódicamente con fines de validación. La frecuencia se puede configurar.

Por estas razones, la carga del recurso compartido de archivos es ligera. Como resultado, un único servidor puede proporcionar recursos compartidos de archivos a varios entornos de CCR. Sin embargo, cada entorno de CCR debe tener su propia carpeta y recurso compartido dedicados en este servidor.

Consideraciones sobre el testigo del recurso compartido de archivos

CCR es un entorno de dos nodos que usa un quórum de MNS con el testigo de recurso compartido de archivos o un quórum de nodos y recursos compartidos de archivos mayoritarios en lugar de un tercer nodo (o más) en el clúster. El uso del tercer nodo era obligatorio en los clústeres MNS tradicionales. Un entorno CCR geográficamente disperso es una implementación del nodo activo en el centro de datos principal y del nodo pasivo en el centro de datos secundario. De este modo, en un entorno CCR geográficamente disperso, existen dos opciones para la colocación del recurso compartido de archivos: en el centro de datos principal o en un tercer centro de datos.

La primera opción es configurar el recurso compartido de archivos en un servidor de transporte de concentradores del centro de datos principal. Se recomienda un servidor de transporte de concentradores, ya que permite al administrador de mensajería administrar y supervisar interrupciones del recurso compartido de archivos. Nuestra experiencia y los comentarios de los clientes indican que los tipos de interrupciones de servicio de red más comunes ocurren en topologías de red de área extensa (WAN). La colocación del recurso compartido de archivos en el centro de datos principal resulta útil, ya que evita las interrupciones del servicio debidas a errores de red entre los dos centros de datos. Si se usa esta configuración, no se producirá la conmutación por error automática en caso de una interrupción del centro de datos principal. No obstante, garantiza que la mayoría del clúster de conmutación por error no se verá afectada por un error de red entre el centro de datos principal y el secundario.

La segunda opción es configurar el recurso compartido de archivos en una función de servidor administrado de un tercer sitio físico. Una función de servidor administrado es un servidor compatible que se mantiene en un grado similar al de otros servidores que son vitales para la entrega del servicio de mensajería. Un ejemplo de función de servidor administrado es un servidor de transporte de concentradores en el centro de datos principal. Este tercer sitio físico puede ser una sucursal o un tercer centro de datos. Un requisito de esta configuración es la infraestructura de red que debe tener el tercer sitio para los centros de datos principal y secundario, con baja latencia y alta fiabilidad.

Reproducción y replicación de registros de transacciones

Se usa para copiar los datos modificados y actualizar la base de datos de la copia pasiva. La replicación se sirve del historial de cambios que crea el Motor extensible de almacenamiento (ESE). El historial de cambios se representa como una secuencia de archivos de registro de 1 MB. La funcionalidad de replicación copia los archivos de registro al nodo pasivo a medida que se genera cada uno de ellos. El mecanismo de replicación es asincrónico en la base de datos en línea. Cuando los registros llegan al nodo pasivo, se comprueba su estado y se reproducen en la copia de la base de datos almacenada en dicho nodo. Este proceso de reproducción realiza los cambios descritos en el registro de cambios de la base de datos del nodo pasivo, que hace que esta base de datos se ajuste con la base de datos de producción con un pequeño retraso.

Dado que los datos se replican entre los nodos, el servidor de buzones de correo en clúster puede funcionar en cualquiera de los nodos del clúster. Esta capacidad proporciona mayor disponibilidad, ya que los cortes programados o los errores de un nodo no provocan un corte ampliado del servidor de buzones de correo en clúster. Además, las interrupciones de servicio del almacenamiento en un nodo no afectarán a la disponibilidad del otro nodo y del servidor de buzones de correo en clúster. Suponiendo que el recurso compartido de archivos aún esté disponible y pueda comunicarse con el nodo pasivo, una interrupción de los nodos activos tendrá como consecuencia el desplazamiento del servidor de buzones de correo en clúster a un nodo restante y su funcionamiento.

En un entorno CCR, la carpeta de archivo de registro de transacciones en el nodo activo se comparte usando un recurso compartido de archivos Windows estándar. El identificador único global (GUID) de objeto para el grupo de almacenamiento se usa para el nombre del recurso compartido y se agrega un signo de dólar ($) al final. El Servicio de replicación de Microsoft Exchange del nodo pasivo se conecta al recurso compartido en el nodo activo y copia o extrae los archivos de registro usando el protocolo Bloque de mensajes de servidor (SMB). El nodo pasivo comprueba entonces el archivo de registro y lo reproduce en la copia de la base de datos del nodo.

Replicación continua en redes de clústeres redundantes

En la versión RTM de Microsoft Exchange Server 2007, la copia y reinicialización de todos los archivos de registro de transacciones en un entorno CCR tienen lugar en la red pública. Esta configuración presenta los siguientes límites:

• Si el nodo pasivo no está disponible durante varias horas, se puede crear un número significativo de registros que deben transferirse. La transferencia de estos registros debe ser lo más rápida posible cuando el nodo pasivo esté disponible. Al copiar los registros a la red pública, la transferencia de los registros competirá con el tráfico de cliente. Esto afecta al tráfico de cliente y ralentiza la resincronización.

• Si la red pública presenta error, la conmutación por error tendrá pérdidas, aunque los datos de registro estén disponibles.

• El uso de una red aislada para la comunicación de registros permite ofrecer seguridad para los datos de mensajería sin necesidad de usar cifrado y su penalización de rendimiento asociada.

• En algunos casos, pueden producirse tormentas de registros. En tales casos, el sistema experimenta una carga de elevada replicación poco habitual. Esto puede provocar escasez de clientes si los datos de registros deben comunicarse a través de la misma red usada para la comunicación con clientes.

No todos estos problemas ocurrirán con la misma frecuencia. No obstante, se garantiza que el primer problema ocurrirá regularmente debido a que los nodos pasivos se desconectan para la ejecución del mantenimiento regular.

Exchange 2007 SP1 minimiza los efectos de los problemas anteriores permitiendo al administrador crear una o varias redes mixtas en el clúster (una red mixta es una red de clústeres que admite tráfico de latidos de clústeres internos y tráfico de cliente) para el transporte de registros. Exchange 2007 SP1 permite también a un administrador indicar una red mixta específica para la inicialización.

La compatibilidad con la copia de archivos de registro en una red mixta se configura mediante un nuevo cmdlet denominado Enable-ContinuousReplicationHostName. Del mismo modo, la desactivación de esta función se realiza mediante el cmdlet Disable-ContinuousReplicationHostName.

Una vez que exista un servidor de buzones de correo en clúster en un entorno CCR, un administrador podrá ejecutar Enable-ContinuousReplicationHostName en ambos nodos del clúster y especificar las direcciones IP y nombres de host adicionales, que se crearán en los grupos de clústeres dedicados asociados con cada nodo. Tras esta tarea, el servicio de replicación de Microsoft Exchange usará la red recién creada para copiar registros poco después de la configuración y la confirmación del correcto funcionamiento de la nueva red. Si se crean varias redes, el servicio de replicación de Microsoft Exchange seleccionará aleatoriamente una de ellas. Si la red especificada deja de estar disponible, el servicio de replicación de Microsoft Exchange usará automáticamente otras redes de replicación o, si no hay ninguna disponible, usará la red pública para el trasvase de registros en cinco minutos. (La detección de la red del servicio de replicación de Microsoft Exchange se realiza cada cinco minutos.) Cuando la red de replicación preferida se encuentre de nuevo disponible, el servicio de replicación de Microsoft Exchange volverá a usarla automáticamente para el trasvase de registros.

Para obtener más información sobre estos cmdlets, consulte Enable-ContinuousReplicationHostName y Disable-ContinuousReplicationHostName.

La compatibilidad con la inicialización en una red de clústeres redundantes se configura mediante el cmdlet Update-StorageGroupCopy, que se ha actualizado en Exchange 2007 SP1 para incluir un parámetro nuevo denominado DataHostNames. Este parámetro se usa para especificar la red de clústeres que debe usarse para la inicialización. Para obtener más información acerca de los cambios realizados en el cmdlet Update-StorageGroupCopy de Exchange 2007 SP1, consulte Update-StorageGroupCopy.

Una vez creada una red de clústeres para la replicación continua, puede usar el cmdlet Get-ClusteredMailboxServerStatus para ver información actualizada sobre las redes de clústeres que se han habilitado para la actividad de replicación continua. Entre los nuevos detalles del resultado se incluyen:

• OperationalReplicationHostNames:{Host1,Host2,Host3}

• FailedReplicationHostNames:{Host4}

• InUseReplicationHostNames:{Host1,Host2}

Para obtener más información acerca de los cambios realizados en el cmdlet Get-ClusteredMailboxServerStatus de Exchange 2007 SP1, consulte Get-ClusteredMailboxServerStatus.

Contenedor de transporte

El grueso de los datos perdidos durante una recuperación automática se recupera automáticamente mediante una característica del servidor de transporte de concentradores denominada contenedor de transporte. El contenedor de transporte de una base de datos específica podría estar ubicado en todos los servidores de transporte de concentradores del sitio de Active Directory que contiene el servidor de buzones de correo en clúster. Cuando un mensaje pasa por los servidores de transporte de concentradores hacia un servidor de buzones de correo en clúster en un entorno CCR, se guarda una copia del mensaje en la cola de transporte (mail.que) hasta que pasa la ventana de replicación. El contenedor de transporte es un componente necesario para implementaciones CCR. Aprovecha la redundancia en el entorno para reclamar algunos datos afectados por la conmutación por error. En concreto, los servidores de transporte de concentradores mantienen una cola del correo recién entregado. Esta cola está vinculada al tiempo que se guarda el correo y al espacio total usado. Al producirse una conmutación por error sin pérdidas, la CCR del servidor de buzones de correo en clúster solicita automáticamente a cada servidor de transporte de concentradores del sitio Active Directory el reenvío de correo de la cola del contenedor de transporte. El almacén de información elimina automáticamente los duplicados y envía de nuevo el correo perdido.

El contenedor de transporte está habilitado para CCR y, en Exchange 2007 SP1, también para replicación continua local (LCR). El contenedor de transporte no está habilitado para SCR ni para clústeres de copia única (SCC). Para CCR, la condición necesaria para conservar un mensaje de correo electrónico en el contenedor de transporte es que tenga al menos un destinatario cuyo buzón esté en un servidor de buzones de correo en clúster de un entorno CCR o, en SP1, en una base de datos de buzones habilitada para LCR.

El contenedor de transporte está diseñado para proteger frente a pérdidas de datos ofreciendo a un administrador la opción de configurar la CCR de manera que el servidor de buzones de correo en clúster esté disponible automáticamente en otro nodo, con una cantidad limitada de datos perdidos. Si esto ocurre, el sistema envía automáticamente todos los mensajes de correo electrónico recientes enviados a los usuarios de este servidor aprovechando el contenedor de transporte donde aún están almacenados estos mensajes. Esto ayuda a evitar la pérdida de datos en la mayoría de las situaciones. En un entorno CCR, la solicitud para volver a entregar desde el contenedor de transporte de todos los servidores de transporte de concentradores del sitio se realiza de forma automática. En Exchange 2007 RTM, el intervalo de reintento está codificado en siete días. En Exchange 2007 SP1, el intervalo de reintento es igual al valor establecido para MaxDumpsterTime. En un entorno LCR, la solicitud para volver a entregar desde todos los servidores de transporte de concentradores del sitio ocurre como parte de la tarea Restore-StorageGroupCopy.

Entre las situaciones en las que el contenedor de transporte no mitiga la pérdida de datos se incluyen:

• Carpeta Borrador de cualquier cliente Microsoft Outlook en modo en línea.

• Citas, actualizaciones de contactos, actualizaciones de propiedad, tareas y actualizaciones de tarea.

• Correo saliente en tránsito desde el cliente al servidor de transporte de concentradores. Existe un período de tiempo durante el cual el mensaje de correo electrónico está en el servidor de correo del remitente.

Implementación de la replicación continua en clúster

La implementación de la CCR es similar a la implementación de un servidor Exchange independiente y a la implementación de una SCC. Para obtener más información acerca de las SCC, consulte Clústeres de copia única. Sin embargo, existen algunas diferencias significativas que deben tenerse en cuenta al implementar la CCR. Se recomienda revisar los siguientes temas antes de diseñar e implementar la CCR en su entorno:

• Diseño de la replicación continua de clústeres

• Recursos de clúster de Exchange para los servidores de buzón en clústeres

• Comportamiento de la recuperación de la replicación continua en clústeres

• Cortes programados y no programados

• Migración de clústeres que ejecutan versiones anteriores de Exchange

Cuando esté listo para implementar la CCR, puede comenzar el proceso realizando los pasos de cada fase de la instalación descritos en uno de los siguientes temas:

• Instalación de la replicación continua en clúster en Windows Server 2008

• Instalación de replicación continua en clústeres

Mejoras de CCR en Exchange 2007 SP1

Exchange 2007 SP1 incluye varias mejoras para la CCR, incluidos los elementos de interfaz de usuario adicionales de la Consola de administración de Exchange y mejoras del estado, la supervisión y el rendimiento.

Mejoras de la Consola de administración de Exchange

Se han agregado varios elementos nuevos de la interfaz de usuario en Exchange 2007 SP1 que mejoran la administración de características de alta disponibilidad, incluida la CCR. Estas mejoras incluyen:

• Interfaz de usuario del contenedor de transporte   Se ha agregado una nueva ficha Configuración global al nodo de transporte de concentradores en el área de trabajo Configuración de la organización. Esta ficha incluye una página Propiedades de configuración del transporte que se puede usar para configurar el contenedor de transporte en la organización:

  • Tamaño máximo por grupo de almacenamiento (MB)   Especifica el tamaño máximo de la cola del contenedor de transporte para cada grupo de almacenamiento.

  • Tiempo máximo de retención (días)   Especifica cuánto tiempo tendrá que permanecer un mensaje de correo electrónico en la cola del contenedor de transporte.

• Replicación continua   Se han agregado más controles de la interfaz de usuario a la Consola de administración de Exchange que permiten que un administrador suspenda, reanude, actualice y restaure la replicación continua. Estos controles equivalen a usar los siguientes cmdlets de la Consola de administración de Exchange:

  • Suspend-StorageGroupCopy

  • Resume-StorageGroupCopy

  • Update-StorageGroupCopy

  • Restore-StoreGroupCopy

  Puede usar estos cmdlets y las tareas correspondientes de la Consola de administración de Exchange para administrar la replicación continua, tanto en un entorno LCR como CCR.

Mejoras de la supervisión y el estado

Exchange 2007 SP1 introduce también varios cambios diseñados para mejorar la capacidad de administración de Exchange 2007. Se mejoran las características de elaboración de informes del clúster en Exchange 2007 RTM y se incluye la funcionalidad adicional diseñada para la supervisión proactiva de entornos de replicación continua. Específicamente, los cambios y las mejoras corrigen deficiencias conocidas con el cmdlet Get-StorageGroupCopyStatus, introducen un nuevo cmdlet denominado Test-ReplicationHealth y ofrecen una mayor visibilidad en la ventana de pérdidas cubierta por el contenedor de transporte.

Mejoras en el cmdlet Get-StorageGroupCopyStatus

En Exchange 2007 RTM, hay varias condiciones en las que el estado indicado por Get-StorageGroupCopyStatus y los contadores de rendimiento de la replicación continua es inexacto o puede malinterpretarse:

• Un grupo de almacenamiento no activo (por ejemplo, que no cambia) puede mostrar su estado como correcto, aunque no lo sea. Esta situación se produce porque no se puede detectar su estado correcto hasta la reproducción de un registro.

• Durante la inicialización de la replicación, se está reevaluando el estado de replicación y es posible que no sea preciso. Cuando se complete la inicialización, se actualizará el estado.

• El valor del campo LastLogGenerated puede ser incorrecto cuando se desmonta la base de datos del grupo de almacenamiento.

• Cuando faltan uno o varios registros en medio de una secuencia de registros, la copia pasiva continúa intentando recuperarlos. Esto hace que el estado de replicación cambie entre los estados erróneo y correcto. Cuando esto ocurre, las colas de copia y reproducción siguen creciendo.

• En raras ocasiones, puede que se compruebe un registro correctamente, pero que no se pueda reproducir. En esta situación, el sistema alternará entre los estados erróneo y correcto mientras intenta recuperarlo. Cuando esto ocurre, las colas de copia y reproducción siguen creciendo.

El cmdlet Get-StorageGroupCopyStatus se ha mejorado también con la adición de nueva información del estado para entornos CCR:

• El cmdlet Get-StorageGroupCopyStatus notifica un SummaryCopyStatus (Resumen del estado de la copia) de ServiceDown (Servicio desconectado) cuando el servicio de replicación de Microsoft Exchange en el equipo de destino no está accesible a través de la red.

• El cmdlet Get-StorageGroupCopyStatus notifica un SummaryCopyStatus de Initializing (Inicialización) cuando el servicio de replicación de Microsoft Exchange en el equipo de destino no ha completado sus comprobaciones iniciales. También se ha creado un nuevo contador de rendimiento para representar este estado como booleano.

• El cmdlet Get-StorageGroupCopyStatus notifica Synchronizing como SummaryCopyStatus cuando no ha completado una reinicialización incremental.

Los nuevos estados para el valor de SummaryCopyStatus son visibles únicamente cuando se usa la versión Exchange 2007 SP1 de las herramientas de administración de Exchange. Si usa la versión Exchange 2007 RTM de las herramientas de administración de Exchange, cualquiera de los estados anteriores se notificará como Error.

Cmdlet Test-ReplicationHealth

Exchange 2007 SP1 introduce un nuevo cmdlet denominado Test-ReplicationHealth. Este cmdlet se ha diseñado para la supervisión proactiva de la replicación continua y de la canalización de replicación continua. El cmdlet Test-ReplicationHealth comprueba todos los aspectos de la replicación, los servicios de clúster y el estado de la replicación y reproducción del grupo de almacenamiento, con el fin de proporcionar una descripción completa del sistema de replicación. De manera específica, cuando se ejecuta en un nodo del clúster, el cmdlet Test-ReplicationHealth realiza las pruebas descritas en la tabla siguiente.

Pruebas realizadas por el cmdlet Test-ReplicationHealth

Mejoras del rendimiento

Se han realizado mejoras de rendimiento en Exchange 2007 SP1 que benefician a las implementaciones de alta disponibilidad. Estas mejoras incluyen:

• Reducciones de E/S en los discos que contienen copias pasivas de grupos de almacenamiento en entornos de replicación continua   En Exchange 2007 SP1, el diseño de la arquitectura de replicación continua se ha modificado de forma que la memoria caché de la base de datos se conserve en el nodo pasivo, entre los lotes de actividad de reproducción de registros. La persistencia de la memoria caché de la base de datos entre lotes de actividad de reproducción de registros permite al servicio de replicación de Microsoft Exchange aprovechar las características de almacenamiento en caché de la base de datos del ESE, que a su vez, reduce la E/S de los discos que tiene lugar en los números de unidad lógica (LUN) de la copia pasiva. Por el contrario, en Exchange 2007 RTM, se crea una nueva caché de base de datos para cada lote de actividad de reproducción de registros, que en algunos casos hace que la actividad de E/S del disco en el nodo pasivo sea el doble o el triple que la del nodo activo.

• Desplazamiento más rápido de servidores de buzones de correo en clúster entre nodos en un entorno CCR   Estas mejoras permiten a los servidores de buzones de correo en clúster desplazarse entre nodos en dos minutos o menos. Esto incluye los desplazamientos realizados por un administrador (usando el cmdlet Move-ClusteredMailboxServer) y las conmutaciones por error administradas por el servicio de clúster. Para conseguir desplazamientos rápidos en un entorno CCR, las bases de datos se desconectan sin necesidad de vaciar la memoria caché de la base de datos. Este comportamiento reduce el tiempo de inactividad que se produce al mover el servidor de buzones de correo en clúster a otro nodo.

Uso de replicación continua en espera con CCR

SCR es una característica nueva de Exchange 2007 SP1. SCR amplía las características de replicación continua existentes y permite nuevos escenarios de disponibilidad de datos para servidores de buzones de Exchange 2007. SCR usa la misma tecnología de trasvase y reproducción de registros que la LCR y la CCR para proporcionar opciones y configuraciones de implementación adicionales.

SCR permite usar replicación continua para los datos de servidor de buzones de correo desde un servidor de buzones de correo independiente (con o sin LCR) o en clúster en un entorno SCC o CCR.

El proceso de activación de copias de datos de servidor de buzones de correo que SCR ha creado y mantenido es manual y se ha diseñado para casos de error grave (y no para simples interrupciones del servidor que se pueden solucionar mediante el reinicio u otro método rápido). Puede activar un destino de SCR usando la portabilidad de bases de datos, la opción de recuperación del servidor (Setup /m:RecoverServer) o, si se trata de un servidor de buzones de correo en clúster, la opción de recuperación correspondiente (Setup /RecoverCMS). La opción que elija se basará en su configuración y en el tipo de error que se produzca.

Para obtener más información acerca de SCR, consulte Replicación continua en espera.

Para obtener más información

Las siguientes áreas temáticas explican cuándo y cómo usar la replicación continua en clúster como parte de un plan de alta disponibilidad y de recuperación de sitios:

• Diseño de la replicación continua de clústeres

• Diseño de la lista de comprobación de la replicación continua agrupada

• Ventajas de la replicación continua en clústeres sobre la copia única de los clústeres

• Recursos de clúster de Exchange para los servidores de buzón en clústeres

• Comportamiento de la recuperación de la replicación continua en clústeres

• Cortes programados y no programados

• Migración de clústeres que ejecutan versiones anteriores de Exchange

• Instalación de replicación continua en clústeres

• Instalación de la replicación continua en clúster en Windows Server 2008

• Administración de la replicación continua agrupada

• Solucionar problemas de replicación continua agrupada