Activar destinos de replicación continua en espera

  • Artículo

 

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

Última modificación del tema: 2008-06-19

La replicación continua en espera (SCR), una nueva característica de Microsoft Exchange Server 2007 Service Pack 1 (SP1), permite usar replicación continua para replicar datos de servidor de buzones desde un servidor de buzones independiente, desde un servidor de buzones de correo en clúster en un clúster de copia única (SCC) o en un entorno de replicación continua en clúster (CCR).

Como su nombre indica, la SCR está pensada para su uso en casos de recuperación en espera. El proceso para activar copias de datos de servidor de buzón creados y mantenidos mediante SCR es manual y está pensado para ser usado únicamente cuando se produce un error importante. SCR no está pensado para usarse en interrupciones del servidor de poca importancia y que son recuperables mediante el reinicio o a través de algún otro recurso rápido. Se puede activar un destino de SCR mediante portabilidad de base de datos con la opción de recuperación del servidor (Setup /m:RecoverServer) o, si el servidor de buzones está organizado en clústeres, mediante la opción de recuperación de servidor de buzones de correo en clúster (Setup /RecoverCMS). La opción elegida se basará en la configuración y en el tipo de error que se produzca. Si el origen SCR es un servidor de buzones de correo en clúster, la configuración de destino óptima es un clúster en espera. Si el origen SCR es un servidor de buzones independiente, la configuración de destino óptima es un servidor de buzones de correo independiente. Aunque no existe ningún requisito para hacer coincidir la configuración de destino con la configuración de origen, si se usa la misma configuración se puede reducir el tiempo de recuperación. Por ejemplo, si el origen SCR es un servidor de buzones de correo en clúster y el destino SCR es un servidor de buzones independiente en lugar de un clúster en espera, el proceso total de recuperación del servidor tardará más tiempo. El motivo es que un servidor de buzones independiente tiene su propia identidad de servidor que primero es necesario quitar (desinstalando Exchange), de forma que se pueda ejecutar Setup /RecoverCMS.

Escenarios de activación y recuperación de SCR

SCR está diseñada para habilitar opciones de recuperación a nivel de centro de datos y para complementar la resistencia de los mismos proporcionada por la replicación continua local, la replicación continua en clúster y la replicación continua en espera. La SCR permite una separación de alta disponibilidad (integrada por disponibilidad de datos y de servicio) y la resistencia del sitio. Por ejemplo, SCR se puede combinar con CCR para replicar grupos de almacenamiento de manera local en un centro de datos principal (con CCR para alta disponibilidad) y de manera remota en un centro de datos secundario o de copia de seguridad (con SCR para resistencia del sitio).

Para obtener más información acerca de cómo usar SCR y un clúster de conmutación por error en espera en una situación de resistencia de sitio, consulte Replicación continua en espera: Fiabilidad de sitios con clúster en espera. El caso descrito en este tema muestra cómo usa SCR la organización Contoso, Ltd. en una situación de resistencia de sitio. En este escenario, el centro de datos principal produce un error y en Contoso, Ltd. se toma la decisión de activar un centro de datos secundario. Una vez que se ha activado el centro de datos secundario, el centro de datos principal se reconfigura y finalmente se restaura como centro de datos principal en una operación controlada.

Para obtener más detalles acerca de cómo usar la SCR con portabilidad de base de datos, consulte Replicación continua en espera: Portabilidad de bases de datos. El escenario descrito en este tema muestra cómo usa SCR y portabilidad de base de datos la organización Woodgrove Bank para recuperarse de un error en una sola base de datos. En este caso, se averigua que una base de datos de origen de SCR tiene daños físicos y el administrador decide activar la base de datos de destino de SCR. Durante la activación, se deshabilita SCR, se monta la base de datos destino de SCR como base de datos de producción y se vuelven a hospedar los buzones de usuario. Tras haber restaurado a los clientes el acceso a datos, SCR vuelve a estar habilitada para el grupo de almacenamiento para restaurar la redundancia y la protección de destino de SCR.