Replicación continua en espera

 

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

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

La replicación continua en espera (SCR) es una nueva característica introducida en Microsoft Exchange Server 2007 Service Pack 1 (SP1). Como su propio nombre indica, la SCR se ha diseñado para escenarios en los que se use o se habilite el uso de servidores de recuperación en espera. La SCR amplía las características de replicación continua que ya existían en la versión sólo para fabricantes (RTM) de Exchange Server 2007 y habilita nuevos escenarios de disponibilidad de datos para servidores de buzones de correo en los que se ejecute SP1. SCR usa la misma tecnología para el envío y la reproducción de registros que se utiliza para la replicación continua local (LCR) y la replicación continua en clúster (CCR) con el fin de proporcionar configuraciones y opciones adicionales de implementación.

SCR habilita una separación de gran disponibilidad (incluye disponibilidad de datos y servicios) y resiliencia del sitio. Por ejemplo, SCR se puede combinar con CCR para replicar grupos de almacenamiento localmente en un centro de datos principal (con CCR para una alta disponibilidad) y remotamente en un centro de datos de copia de seguridad o secundario (con SCR para resiliencia 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 espera, 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 espera se pueden activar rápidamente en el clúster en espera.

Orígenes y destinos

Al igual que ocurre con la LCR y la CCR, la SCR usa el concepto de copias activas y pasivas de un grupo de almacenamiento, pero en cambio aquí se llaman orígenes y destinos. Además, igual que la CCR, la SCR requiere que las rutas de archivo de registro y base de datos coincidan en el origen y el destino.

El punto de partida para la SCR se conoce como origen, y puede ser cualquier grupo de almacenamiento en:

  • Servidor de buzones independiente

  • Servidor de buzones de correo en clúster en un clúster de copia única (SCC)

  • Servidor de buzones de correo en clúster en un entorno CCR

    Nota

    Los grupos de almacenamiento de recuperación no pueden estar habilitados para SCR.

Al igual que ocurre con LCR y CCR, los grupos de almacenamiento habilitados para SCR contienen más de una base de datos. No se puede habilitar la SCR para un grupo de almacenamiento que contenga más de una base de datos ni se puede agregar una base de datos siguiente o secundaria a un grupo de almacenamiento habilitado para SCR.

Si el equipo de origen de SCR no está en clúster, también puede hospedar otras funciones del servidor, como Transporte de concentradores, Acceso de cliente y Mensajería Unificada.

El punto final para la SCR se conoce como destino, y este destino puede ser:

  • Servidor Buzón de correo independiente que no tenga LCR habilitada para ningún grupo de almacenamiento

  • Un clúster independiente que sea un clúster de conmutación por error en el que se haya instalado la función de Buzón en clústeres pasivo, pero no se haya instalado un servidor Buzón de correo en clúster (por ejemplo, ninguna función de Buzón en clústeres activo) en el clúster.

Un equipo de destino para SCR debe tener instalada la función del servidor Buzón de correo aunque no tenga hospedados buzones de producción. La función del servidor Buzón de correo es necesaria, porque incluye el Servicio de replicación de Microsoft Exchange y otros componentes necesarios para la funcionalidad de SCR. Si el equipo de destino de SCR no está en clúster, también puede hospedar otras funciones del servidor, como Transporte de concentradores, Acceso de cliente y Mensajería Unificada

SCR está disponible en la Standard Edition de Exchange 2007 SP1. Si se usa un servidor de buzones en un entorno SCC o CCR como origen de SCR, la Enterprise Edition de Exchange 2007 SP1 es necesaria, porque la Enterprise Edition es necesaria cuando se trabaja con Exchange 2007 en clúster. Si se usa un clúster en espera como destino de SCR, también es necesaria la Enterprise Edition de Exchange 2007 SP1.

Comparación de SCR con LCR y CCR

SCR es parecida a LCR y CCR, pero presenta también características exclusivas:

  • SCR admite varios destinos de replicación por cada grupo de almacenamiento. LCR y CCR sólo admiten un destino de replicación por cada grupo de almacenamiento (copia pasiva).

  • SCR incluye un retraso integrado de la actividad de reproducción y permite a un administrador especificar un retraso adicional. Esto resulta útil en diversos escenarios. Por ejemplo, en caso de daños en la lógica de una base de datos activa, se podría usar el retraso integrado y el adicional configurado por el administrador para evitar daños en la lógica de la base de datos en el destino para SCR. LCR y CCR no cuentan con estos retrasos.

  • La SCR se administra por completo con el Shell de administración de Exchange. La Consola de administración de Exchange se puede usar para administrar muchos aspectos de LCR y CCR, pero no se puede usar para habilitar ni administrar aspectos de SCR.

Activación de copia de SCR

El proceso para usar una base de datos de destino de SCR se denomina activación y el modo en que se activa la base de datos depende de la naturaleza del error. Si una o varias de las bases de datos de origen de SCR están afectadas, puede usar la característica de portabilidad de bases de datos de Exchange 2007 como parte del proceso de activación para bases de datos de destino de SCR. Si todas las bases de datos de un servidor de origen de SCR están afectadas, o si se está recuperando un servidor completo o un servidor de buzones de correo en clúster, puede usar las características de recuperación de servidor del programa de instalación (Setup/m:RecoverServer para un servidor independiente y Setup /RecoverCMS para un servidor de buzones de correo en clúster) como parte del proceso de activación.

Nota

Si los planes de recuperación incluyen el uso de Setup /RecoverCMS para recuperar un servidor de buzones de correo en clúster (CCR o SCC) que tiene uno o más grupos de almacenamiento habilitados para SCR, se debe deshabilitar SCR para los grupos de almacenamiento antes de ejecutar Setup /RecoverCMS.

Para obtener más información acerca de la activación y la recuperación en un entorno de SCR, consulte Activar destinos de replicación continua en espera.

Escenarios de implementación de SCR

SCR permite usar la replicación continua para replicar datos del servidor de buzones de correo desde un servidor de buzones independiente o desde un servidor de buzones de correo en clúster en un entorno SCC o CCR. En las dos figuras siguientes se ilustran algunas de las opciones de configuración posibles de SCR.

Uso de SCR para replicar un grupo de almacenamiento desde un servidor de buzones independiente en otro servidor de buzones

SCR de un servidor independiente a otro

En la figura anterior se ilustra el uso de SCR para replicar varios grupos de almacenamiento desde un servidor de buzones en otro servidor de buzones. En este ejemplo, los servidores de buzones no están en clúster y ambos actúan como origen y destino de SCR. En este ejemplo, cada servidor se encuentra en un centro de datos distinto y en un sitio de Active Directory diferente. En función de la naturaleza del error, la recuperación de un grupo de almacenamiento en cualquiera de los servidores podría realizarse con la portabilidad de la base de datos o la opción de instalación /RecoverServer.

Uso de CCR para replicar grupos de almacenamiento localmente y de SCR para replicar un grupo de almacenamiento en una ubicación remota

CCR local con SCR remota

En la figura anterior se muestra un modelo de uno por uno, CCR por SCR. En este ejemplo, EXCLUS1 es un servidor de buzones de correo en clúster en un entorno CCR ubicado en el sitio de Active Directory REDMOND. EXCLUS1DR es un clúster en espera que se encuentra en el sitio de Active Directory QUINCY. En este caso, todos los grupos de almacenamiento en el destino de SCR se pueden recuperar con el modificador de instalación /RecoverCMS. Si no hace falta recuperar todos los grupos de almacenamiento, se puede recuperar uno o varios grupos de almacenamiento con la portabilidad de la base de datos.

Uso de CCR para replicar grupos de almacenamiento localmente y de SCR para replicar grupos de almacenamiento en ubicaciones remotas

Replicación CCR en destinatarios locales y varios destinatarios SCR

En la figura anterior se muestra un modelo de uno por varios, CCR por SCR. Los equipos a la izquierda representan los dos nodos CCR físicos en el mismo centro de datos. Los equipos a la derecha representan los dos destinos de SCR en un segundo centro de datos. En este ejemplo se replica un único grupo de almacenamiento en varios destinos de SCR en dos equipos distintos. El grupo de almacenamiento se puede recuperar en cada destino de SCR mediante uno de estos dos métodos:

  • Se puede usar /RecoverCMS para recuperar grupos de almacenamiento sólo desde un único origen de CCR.

  • Se puede usar la portabilidad de la base de datos para recuperar grupos de almacenamiento de varios orígenes de CCR.

Uso de varios destinos de SCR remotos para una SCC

Clústeres de copia única (SCC) con destino SCR remoto

En la figura anterior se muestra un modelo de uno por varios, SCC por SCR. Los equipos a la izquierda representan los dos nodos SCC físicos en un único centro de datos. Los equipos a la derecha representan los destinos de SCR en un centro de datos independiente. En este ejemplo se replica un único grupo de almacenamiento en dos destinos independientes en un segundo centro de datos. Este grupo de almacenamiento en el destino de SCR se puede recuperar con el modificador de instalación /RecoverCMS.

Actualizaciones de cmdlet para SCR

La SCR se administra con el Shell de administración de Exchange. SP1 incluye un parámetro nuevo llamado StandbyMachine que se puede usar con varios de los cmdlets de administración y configuración de la replicación continua del Shell de administración de Exchange. Concretamente, los siguientes cmdlets incluyen ahora la compatibilidad con SCR y el parámetro StandbyMachine:

  • Suspend-StorageGroupCopy

  • Resume-StorageGroupCopy

  • Update-StorageGroupCopy

  • Restore-StorageGroupCopy

  • Get-StorageGroup

  • Get-StorageGroupCopyStatus

Además de estas actualizaciones de cmdlet, se han actualizado los cmdlets New-StorageGroup y Enable-StorageGroupCopy de modo que admitan SCR. En Exchange 2007 SP1, se puede usar New-StorageGroup para crear un nuevo grupo de almacenamiento habilitado para SCR y Enable-StorageGroupCopy para habilitar SCR para un grupo de almacenamiento existente. Estos cmdlets incluyen los siguientes parámetros actualizados:

  • -StandbyMachine   Este parámetro especifica el nombre del equipo de destino de SCR.

  • -ReplayLagTime   Este parámetro se usa para especificar el tiempo que el servicio de replicación de Microsoft Exchange debería esperar antes de reproducir los archivos de registro que se han copiado en el equipo de destino de SCR. El formato de este parámetro es (días.horas:minutos:segundos). El ajuste predeterminado para este valor es 24 horas (1.0:0:0). El ajuste máximo permitido para este valor es 7 días. El ajuste mínimo permitido es 0 segundos, si bien cuando este valor se ajusta a 0 segundos, elimina eficazmente cualquier retraso en la actividad de reproducción por encima del retraso predeterminado, que es de 50 archivos de registro. Después de establecer el valor de este parámetro, no se puede cambiar sin deshabilitar y volver a habilitar SCR.

  • -TruncationLagTime   Este parámetro se usa para especificar el tiempo que el servicio de replicación de Microsoft Exchange debería esperar antes de truncar los archivos de registro que se han copiado en el equipo de destino de SCR y se han reproducido en la copia de la base de datos. El intervalo de tiempo empieza una vez que el registro se ha reproducido correctamente en la copia de la base de datos. El formato de este parámetro es (días.horas:minutos:segundos). El ajuste máximo permitido para este valor es 7 días. El ajuste mínimo permitido es 0 segundos, si bien cuando este valor se ajusta a 0 segundos, se elimina eficazmente cualquier retraso en la actividad de truncamiento de registro. Después de establecer el valor de este parámetro, no se puede cambiar sin deshabilitar y volver a habilitar SCR.

Además del retraso configurado por el administrador especificado con el parámetro ReplayLagTime, Exchange evitará también que se reproduzca una cantidad fija de archivos de registro en un destino de SCR, independientemente del valor de ReplayLagTime, mediante la fórmula Como máximo ("valor de ReplayLagTime" o "X archivos de registro"), siendo X=50. Se trata de una protección adicional contra la necesidad de reinicializar un grupo de almacenamiento en casos en que un origen de SCR en un entorno de replicación continua (por ejemplo, LCR o CCR) sufre una mala conmutación por error y entra en línea por medio del cmdlet Restore-StorageGroupCopy. Mediante el retraso de la actividad de reproducción en los destinos para SCR, cuando se produce una mala conmutación por error para un origen de SCR, la posibilidad de que se reinicialicen las copias de SCR se reducen al mínimo, porque la naturaleza de la pérdida de datos en el origen de SCR acerca las dos copias en el tiempo.

Importante

El retraso integrado acumulado de la reproducción de 50 archivos de registro y el tiempo predeterminado de 24 horas afectan a la creación de la base de datos inicial de destinos de SCR. No se creará una base de datos de destinos de SCR hasta que se hayan replicado 50 archivos de registro de transacción en el equipo de destino de SCR y hasta que haya transcurrido el tiempo especificado en ReplayLagTime (el valor predeterminado es 24 horas).

Actualizaciones de la instalación para SCR

SCR se ha diseñado en gran parte para errores importantes, como un error total del sitio. Estos tipos de escenarios de error implican actividades manuales, como la activación de un centro de datos de copia de seguridad y un retroceso al centro de datos principal.

Tomando como ejemplo la figura Uso de varios destinos de SCR remotos para una SCC que aparece anteriormente en este tema, plantéese qué ocurrirá cuando el centro de datos principal (el sitio en el que se encuentra la SCC) produzca un error y se tome la decisión de activar el segundo centro de datos como sitio principal de sustitución. Cuando se activa el segundo centro de datos, la configuración del centro de datos original se conserva en Active Directory y es utilizada por el segundo centro de datos tras la activación. La configuración del servidor de buzones de correo en clúster para la SCC también se conserva en el clúster original. Para que el clúster original vuelva a estar en línea, la configuración del servidor de buzones de correo en clúster se debe eliminar de los nodos del clúster sin que ello afecte a la configuración del servidor de buzones de correo en clúster en Active Directory (que está siendo utilizada por el segundo centro de datos).

Para facilitar que esto ocurra y en otros escenarios de resiliencia del sitio, se ha modificado la instalación en Exchange 2007 SP1. Concretamente, el programa de instalación incluye ahora una nueva opción de línea de comandos llamada /ClearLocalCMS que se usa para eliminar la información sobre la configuración del servidor de buzones de correo en clúster de los nodos del clúster original sin que ello afecte a la información sobre la configuración almacenada en Active Directory. Por ejemplo, para borrar los datos de la configuración local de un servidor de buzones de correo en clúster llamado EXCLUS1, se debe ejecutar el comando siguiente localmente en todos los nodos en el clúster original del que desee quitar un servidor de buzón de correo en clúster:

Setup /ClearLocalCMS

Tenga presentes los requisitos y restricciones siguientes cuando use la opción /ClearLocalCMS:

  • Esta opción sólo se puede usar localmente, no remotamente.

  • Esta opción se puede usar sólo en los nodos que hacen funciones de host para un servidor de buzones en clúster (por ejemplo, nodos activos); no se puede usar en nodos pasivos.

  • Esta opción no elimina los archivos de programa de Microsoft Exchange ni actualiza la información de configuración en Active Directory.

  • Esta opción se puede usar sólo si el servidor de buzones de correo en clúster local no está conectado y si el nodo local no aparece en la lista RedundantMachines del servidor de buzones de correo en clúster local.

  • La cuenta usada para eliminar la configuración del servidor de buzones de correo en clúster local debe tener delegados permisos de administrador de Exchange Server para el servidor de buzones de correo en clúster.

  • Si los nodos del clúster se ejecutan en Windows Server 2008, después de ejecutar Setup /ClearLocalCMS, se deshabilitará el objeto de equipo virtual (VCO). Se debe volver a habilitar el VCO.

Para obtener más información

Para obtener más información acerca de la planeación de SCR, consulte Diseño de la replicación continua en espera. Para obtener información acerca de la administración de SCR, incluidas instrucciones detalladas para habilitar o deshabilitar SCR para un grupo de almacenamiento, consulte Administración de la replicación continua en espera.