Replicación continua en espera: Portabilidad de bases de datos

 

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

Última modificación del tema: 2008-11-18

En este tema se ofrece información detallada de un escenario en el que una organización, Woodgrove Bank, usa una réplica continua en suspensión (SCR) y la portabilidad de bases de datos para recuperar un error de una base de datos única. En este escenario, se detecta que una base de datos de origen de SCR tiene daños físicos y el administrador toma la decisión de activar la base de datos de destino de SCR. Durante la activación, SCR está deshabilitado, la base de datos de destino de SCR está montada como la base de datos de producción y los buzones de usuario tienen una nueva base. Después de restaurar el acceso a los datos para los clientes, SCR se habilita de nuevo para el grupo de almacenamiento a fin de restaurar la redundancia y la protección para el destino de SCR.

SCR y portabilidad de bases de datos

Woodgrove Bank ha implementado el Service Pack 1 (SP1) de Microsoft Exchange Server 2007 y ha decidido usar SCR para proporcionar una copia redundante de un grupo de almacenamiento en un servidor de buzón remoto. Ambos servidores de buzón se encuentran en el mismo sitio del servicio de directorio de Active Directory y están configurados para usar servidores DNS con Active Directory integrado. El intervalo de réplica de Active Directory para el sitio de Active Directory está configurado para 15 minutos.

SCR está configurado de forma que los archivos de registro de transacciones se replican para un único grupo de almacenamiento, SG1, que contiene una única base de datos, MBX1. EXMBX1 es el equipo de origen de SCR y EXMBX2 es el equipo de destino de SCR. Las rutas de acceso de los archivos del grupo de almacenamiento (que incluyen los archivos de registro de transacciones) y el archivo de base de datos son E:\SG1 y D:\SG1\MBX1.EDB, respectivamente. Estas rutas se usan en los equipos de origen y destino.

Estas asignaciones se configuraron con el comando siguiente:

Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

El estado de SCR para SG1 se comprobó con los cmdlets Test-ReplicationHealth y Get-StorageGroupCopyStatus en el Shell de administración de Exchange. Por ejemplo:

Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2 | fl

Para ahorrar tiempo durante el proceso de activación de destino de SCR, EXMBX2 se configura previamente con un grupo de almacenamiento y una base de datos que se usarán como parte de las operaciones de portabilidad de bases de datos. El grupo de almacenamiento y las bases de datos se denominan SG1PORT y MBX1PORT, respectivamente.

Importante

SG1PORT y MBX1PORT son independientes del grupo de almacenamiento de destino de SCR y los archivos de bases de datos. Por lo tanto, las rutas para SG1PORT y MBX1PORT se deben configurar con una ruta temporal que no entre en conflicto con las rutas de destino de SCR.

Nota

Después de crear MBX1PORT, se recomienda que se monte y después se desmonte, y que se eliminen todos los archivos de grupo de almacenamiento y el archivo de la base de datos.

Activación de destino de SCR

Un administrador de mensajería observa una entrada del registro de eventos de la aplicación que indica que la base de datos de origen de SCR está dañada físicamente. Debido a que SCR se habilitó para SG1, se toma rápidamente la decisión de realizar una activación manual de la base de datos de destino de SCR para SG1 y de restaurar la disponibilidad de los datos. La activación de la copia de destino de SCR comienza por desmontar la base de datos en SG1. A continuación, la base de datos de destino de SCR se hace viable para el montaje y, a continuación, se crea una nueva base para los buzones de la base de datos de buzones afectada. Para hacerlo, siga los pasos siguientes en orden.

  1. La base de datos de SCR se desmonta con el comando siguiente:

    Dismount-Database EXMBX1\SG1\MBX1
    
  2. El proceso de deshabilitar SCR y de hacer viable la base de datos de destino de SCR para el montaje implica la ejecución del cmdlet Restore-StorageGroupCopy. Esta tarea indica que la base de datos del grupo de almacenamiento se puede montar y proporciona un informe sobre la pérdida de datos, si la hubiera, que será resultado del montaje de la base de datos en el grupo de almacenamiento. Asimismo, comprueba que todos los archivos de registro generados por la copia activa del grupo de almacenamiento existen en la ubicación de los archivos del grupo de almacenamiento de la copia pasiva. Si faltan archivos de registro, la operación intentará copiarlos. SCR se deshabilita y la base de datos de destino se convierte en viable para el montaje con el comando siguiente:

    Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
    

Importante

Si el origen de SCR no está disponible, se debe agregar el parámetro Force al comando Restore-StorageGroupCopy.

  1. Cuando se haya completado correctamente el comando Restore-StorageGroupCopy, un administrador deberá comprobar si la base de datos está en un estado de Cierre limpio. Si la base de datos se encuentra en estado de cierre incorrecto, el administrador puede dar a la base de datos un estado de cierre limpio ejecutando el modo de recuperación de las Utilidades de bases de datos de Exchange Server (Eseutil) (Eseutil /r) en la base de datos. Para obtener instrucciones detalladas acerca de cómo ejecutar el modo de recuperación Eseutil, consulte Cómo ejecutar Eseutil /R (Recuperación).

    Nota

    Si el prefijo del grupo de almacenamiento (por ejemplo, E00 o E01) es el mismo para el origen de SCR (EXMBX1\SG1) y el grupo de almacenamiento de destino de SCR que se usará para la portabilidad de bases de datos (EXMBX2\SG1PORT), no será necesario ejecutar Eseutil en modo de recuperación. La operación de montaje final de la base de datos otorgará a la base de datos un estado de cierre limpio tras reproducir todos los archivos de registro replicados.

  2. Cuando la base de datos esté en un estado limpio, el administrador ejecuta dos comandos que actualizan Active Directory con las nuevas ubicaciones para los archivos de los grupos de almacenamiento y el archivo de la base de datos. Use los siguientes comandos para cambiar las rutas para SG1PORT y MBX1PORT de las rutas temporales a las rutas para el grupo de almacenamiento de destino de SCR y los archivos de bases de datos:

    Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath E:\SG1 -LogFolderPath E:\SG1 -ConfigurationOnly
    Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath D:\SG1\MBX1.EDB -ConfigurationOnly
    
  3. A continuación, la base de datos se debe permitir a sí misma la sobreescritura durante una operación de restauración. Esto se puede conseguir activando la casilla para Una restauración puede sobrescribir esta base de datos en las propiedades de objeto de base de datos en la Consola de administración de Exchange. Esta tarea también se puede realizar con el siguiente comando del Shell de administración de Exchange:

    Set-Mailboxdatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true
    
  4. Después de configurar la base de datos para que se pueda sobrescribir durante una restauración, el administrador puede montar la base de datos con el siguiente comando:

    Mount-Database EXMBX2\SG1PORT\MBX1PORT
    
  5. Una vez montada la base de datos, los buzones con base en la base de datos de origen de SCR deben obtener una nueva base que señale a MBX1PORT en EXMBX2. Esto se puede realizar con el cmdlet Get-Mailbox y canalizando el resultado para el cmdlet Move-Mailbox. Durante este proceso, es importante que el Operador de sistema de Microsoft Exchange y los buzones del sistema no se incluyan en el resultado del cmdlet Get-Mailbox que está canalizado para el cmdlet Move-Mailbox. Esto se consigue con la ejecución del siguiente comando:

    Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT
    

Llegados a este punto, ya es posible el acceso de cliente a MBX1PORT. Sin embargo, la posibilidad de los usuarios de poder obtener acceso realmente a sus buzones después de moverse de EXMBX1\SG1\MBX1 a EXMBX2\SG1PORT\MBX1PORT depende de varios factores:

  • Latencia de replicación de Active Directory   Dependiendo del número de servidores de directorio, puede que la actualización tarde un tiempo en propagarse por el entorno.

  • Método de acceso de cliente   Los clientes de mensajería que ejecuten Microsoft Office Outlook 2007 y los clientes que no sean de Outlook tendrán acceso al buzón de usuario después de que los servidores de directorio usados por el servidor de acceso de cliente se hayan actualizado con las nuevas rutas. Los clientes de mensajería que ejecuten Outlook 2003 y versiones anteriores tendrán que actualizar el perfil de mensajería del escritorio del usuario con el nuevo nombre de servidor en el caso de que el servidor original esté inactivo o no disponible por alguna otra razón. Si el servidor original está en línea y disponible para responder solicitudes de clientes, entonces el servidor original actualizará automáticamente el perfil de mensajería de escritorio a los clientes de mensajería que ejecuten Outlook 2003 y versiones anteriores con el nuevo nombre de servidor, y no será necesario modificar manualmente el perfil de mensajería de escritorio.

Restauración de la redundancia tras la activación de destino de SCR

Después de que los clientes tengan acceso a sus buzones y datos de buzón, el paso final consiste en establecer de nuevo la redundancia volviendo a habilitar SCR. Esto se hace quitando el grupo de almacenamiento y los archivos de bases de datos que sobren de EXMBX1. Una vez que se han quitado los archivos, las rutas para EXMBX1\SG1\MBX1 se pueden mover a una ubicación temporal y EXMBX1 se puede convertir en un destino de SCR de EXMBX2. Una vez realizado, se habrá restaurado la redundancia para el entorno.