Local Continuous Replication en Exchange 2007
Por Daniel Seveso
Local Continuous Replication (LCR), es una nueva funcionalidad de alta disponibilidad incorporada en Exchange 2007. La misma permite tener una réplica de la base de datos de producción en un disco local del propio Mailbox Server, sin necesidad de implementar servicios de Cluster.
Esta funcionalidad conocida como “Log Shipping”, es implementada mediante la replicación de los logs de transacciones de la base de datos a un disco alternativo en el servidor.
¿Para qué sirve?
La principal ventaja de esta funcionalidad es la reducción del tiempo necesario para recuperar la base de producción en caso de fallas. Teniendo una réplica de la base de datos y logs de transacciones en un disco o set de discos alterno, nos permite montar esta réplica en producción y tener el servidor en producción en cuestión de minutos.
Otras ventajas indirectas incluyen: Posibilidad de disminuir la cantidad de full backups durante la semana, al tener una copia de la base replicada. LCR no remplaza los backups normales pero nos da flexibilidad adicional pudiendo agendar backups completos más espaciados. Posibilidad de respaldar la base de datos pasiva (usando Volume Shadow copy Service), en lugar de la de producción, pudiendo ejecutar el backup durante horarios de oficina sin impactar los discos de producción.
¿Cómo funciona?
LCR corre en un único servidor, y utiliza “log shipping” para mantener actualizada una copia de un Storage Group de producción. La función de log shipping combinada con un mecanismo de aplicación de estos logs a la base de datos (log replay) y un método manual para el intercambio de las bases en caso de falla, hace que LCR sea un método efectivo de alta disponibilidad. Microsoft Exchange Replication Service es el servicio encargado de la replicación y aplicación de logs de transacciones a esta copia. LCR es implementado a nivel del Storage Group (SG). Cuando se habilita un SG para LCR, se realiza una copia de la base de datos al directorio predefinido en la configuración del SG. Una vez que la base se copia físicamente, se configura como parte del Storage Group replicado en un proceso denominado “Seeding”, estableciendo el punto de partida de la replicación. Una vez que la base se encuentra en el Storage Group replicado los transaction logs se replicarán en forma asíncrona del SG original al SG replicado. El hecho de que la replicación sea asíncrona determina que siempre habrá una diferencia de tiempo en la aplicación de los logs en el SG original y el replicado. El servicio de replicación se encarga de copiar y aplicar los logs de transacciones a la base de datos replicada.
¿Qué es “log shipping”?
Log shipping es la automatización del proceso de replicación y aplicación de los logs de transacciones de una base de datos fuente a otra destino. Este proceso mantiene las dos bases de datos sincronizadas, con una pequeña diferencia en el tiempo. Esta diferencia radica en que la replicación de un log de transacciones a la base de datos destino, se realiza después que el mismo se ha aplicado a la base de datos original.
Mecanismos adicionales del servicio de replicación se encargan verificar el checksum de los logs replicados verificando que no estén corruptos, y que no se eliminen logs en el origen luego de un backup en línea, si estos aún no han sido replicados.
¿Cuáles son los requerimientos y limitaciones?
Los requerimientos específicos para LCR incluyen:
- Relación 1:1 de base de datos por Storage Group. LCR no puede habilitarse si el Storage Group contiene más de una base de datos. Aunque esto puede parecer una limitante, en Exchange 2007 el límite de Storage Groups ha sido incrementado a 50, por lo que en definitiva tenemos más capacidad que la disponible en Exchange 2003.
- LCR puede ser implementado para carpetas públicas, solamente cuando hay un solo Public Folder store en la organización. Replicación de carpetas públicas entre varios PF stores y LCR no pueden habilitarse simultáneamente.
¿Cuáles son las mejores prácticas de implementación?
- LCR no cambia las mejores prácticas en cuanto a ubicación de las bases de datos con respecto a los logs de transacciones con respecto a desempeño y recuperación. Tampoco cambian los requerimientos de I/O, ni los tiempos de respuesta recomendados para operaciones de lectura y escritura en discos. Por lo tanto, los volúmenes que mantienen la copia de las bases de datos y logs de transacciones deben tener características similares a sus correspondientes en producción.
- Si bien los volúmenes utilizados para la réplica no requieren ser del mismo tamaño que en producción, si usamos LCR como un método de alta disponibilidad, tenemos que considerar espacio suficiente para su crecimiento.
- El uso de “Mount Points” no es un requerimiento pero es soportado por LCR y altamente recomendado. Los “Mount Points” permiten superar la barrera de las 26 unidades de disco y posibilita una rápida reconfiguración, permitiendo “intercambiar” los discos donde se encuentran las bases de datos y logs de producción por los de sus respectivas copias.
- El tamaño máximo recomendado para una base de datos usando LCR es entre 100 y 200Gb dependiendo del tiempo esperado para backup y recuperación.
- Debemos considerar un incremento entre 30 y 40% en términos de CPU y memoria RAM si implementamos LCR para todas las bases de datos en el servidor.
¿Cómo habilito y utilizo LCR en caso de falla de la base de datos?
Como ejemplo de configuración, supongamos que tenemos un storage group “First Storage Group” y un mailbox store “Mailbox Database”, y queremos habilitar LCR para dicha base de datos. Los pasos a seguir serían los siguientes:
1) Configurar los discos para las copias replicadas:
Para simplificar la prueba, digamos que la base de producción se encuentra en un mount point “FSG” en el directorio “C:\Program Files\Microsoft \Exchange Server\Mailbox\FSG”. Instalaremos un disco para la copia de la base de datos y los logs creando un mount point en “C:\Program Files\Microsoft \Exchange Server\Mailbox\LocalCopies”.
Primero inicializaremos y crearemos la partición del nuevo disco usando Disk Manager.
Una vez inicializado, particionado y formateado, podemos ver el volumen usando mountvol tool:
C:\>mountvol
Possible values for VolumeName along with current mount points are:
\\?\Volume{482f9e51-4839-11db-b240-806e6f6e6963}\
C:\
\\?\Volume{482f9e52-4839-11db-b240-806e6f6e6963}\
D:\
\\?\Volume{482f9e53-4839-11db-b240-806e6f6e6963}\
A:\
\\?\Volume{ffcca007-e059-11db-9160-0003ff0ffec8}\
*** NOT MOUNTABLE UNTIL A VOLUME MOUNT POINT IS CREATED ***
\\?\Volume{ffcca00a-e059-11db-9160-0003ff0ffec8}\
C:\Program Files\Microsoft\Exchange Server\Mailbox\FSG\
Creamos un directorio para el nuevo mount point y le asignamos el nuevo volumen:
C:\>md "C:\Program Files\Microsoft\Exchange Server\Mailbox\LocalCopies"
C:\>mountvol "C:\Program Files\Microsoft\Exchange Server\Mailbox\LocalCopies" \\?\Volume{ffcca007-e059-11db-9160-0003ff0ffec8}\
2) Habilitar LCR
Luego que tenemos el disco montado en el directorio, habilitamos la replicación usando el siguiente comando de Exchange Management Shell (EMS):
Enable-DatabaseCopy -Identity “LC2-E2K71\First Storage Group\Mailbox Database”
-CopyEDBFilePath:"C:\Program Files\Microsoft\Exchange Server\Mailbox\Local
Copies\Mailbox Database.edb"
Enable-StorageGroupCopy -Identity “LC2-E2K71\First Storage Group”
–CopyLogFolderPath:“C:\Program Files\Microsoft\Exchange Server\Mailbox\Local
Copies” -CopySystemFolderPath:“C:\Program Files\Microsoft\Exchange Server\Mailbox\LocalCopies”
El hecho de habilitar la réplica también efectúa el “seeding” de la misma. “Seeding” es la operación por la cual se crea un punto de inicio en la replicación. El contenido inicial del directorio “LocalCopies” sería el siguiente (recuerda que aquí estamos usando el mismo directorio para logs y base de datos. En un ambiente de producción estarían separados).
3) Verificar la replicación
Podemos verificar el estado de la replicación y otros datos útiles con el siguiente comando de EMS:
[PS] C:\>Get-StorageGroupCopyStatus -identity "first storage group" |fl
Identity : LC2-E2K71\First Storage Group
StorageGroupName : First Storage Group
SummaryCopyStatus : Healthy
CCRTargetNode :
Failed : False
FailedMessage :
Seeding : False
Suspend : False
SuspendComment :
CopyQueueLength : 0
ReplayQueueLength : 0
LatestAvailableLogTime : 4/1/2007 2:10:57 PM
LastCopyNotificationedLogTime : 4/1/2007 2:10:57 PM
LastCopiedLogTime : 4/1/2007 2:10:57 PM
LastInspectedLogTime : 4/1/2007 2:10:57 PM
LastReplayedLogTime : 4/1/2007 2:10:57 PM
LastLogGenerated : 92
LastLogCopyNotified : 92
LastLogCopied : 92
LastLogInspected : 92
LastLogReplayed : 92
LatestFullBackupTime :
LatestIncrementalBackupTime :
SnapshotBackup :
IsValid : True
ObjectState : Unchanged
En caso de falla de la base de datos de producción:
1) Revisar el estado de replicación en la copia para determinar si es aceptable para utilización en producción. (Usando Get-StorageGroupCopyStatus)
2) Desmontar la base de datos corrupta de producción (si es que está aún montada)
Dismount-database –Identity “LC2-E2K71\First Storage Group\Mailbox Database”
3) Reconfigurar los directorios a las bases de datos. Esto puede realizarse de dos formas:
a. Reconfigurando los Mount Points a nivel de los discos, dejando la configuración del Storage Group intacta. (Recomiendo esta forma para evitar confusión con la asignación de unidades)
C:\>mountvol
Possible values for VolumeName along with current mount points are:
\\?\Volume{482f9e51-4839-11db-b240-806e6f6e6963}\
C:\
\\?\Volume{ffcca007-e059-11db-9160-0003ff0ffec8}\
C:\Program Files\Microsoft\Exchange Server\Mailbox\LocalCopies\
\\?\Volume{ffcca00a-e059-11db-9160-0003ff0ffec8}\
C:\Program Files\Microsoft\Exchange Server\Mailbox\FSG\
\\?\Volume{482f9e52-4839-11db-b240-806e6f6e6963}\
D:\
\\?\Volume{482f9e53-4839-11db-b240-806e6f6e6963}\
A:\
Borro las asignaciones:
C:\>mountvol "C:\Program Files\Microsoft\Exchange Server\Mailbox\FSG" /d
C:\>mountvol "C:\Program Files\Microsoft\Exchange Server\Mailbox\localcopies" /d
Creo nuevamente las asignaciones intercambiando los volúmenes:
C:\>mountvol "C:\Program Files\Microsoft\Exchange Server\Mailbox\localcopies" \\?\Volume{ffcca00a-e059-11db-9160-0003ff0ffec8}\
C:\>mountvol "C:\Program Files\Microsoft\Exchange Server\Mailbox\FSG" \\?\Volume{ffcca007-e059-11db-9160-0003ff0ffec8}\
Habilito la copia para ser usada en producción sin cambiar los directorios de trabajo:
Restore-StorageGroupCopy -Identity: “First Storage Group”
Esta es la salida de ejecución del comando anterior. Los mensajes de Warning son debido a las diferencias entre el directorio de producción y su copia:
WARNING: Failed to copy remaining log files (through Exx.log) during Restore-StorageGroupCopy operation for storage group copy (First Storage Group). Failure reason: Transaction log file action LogInspector failed for storage group LC2-E2K71\First Storage Group.
Identity : LC2-E2K71\First Storage Group
LastLogGenerated : 105
LastLogInspected : 105
LatestAvailableLogTime : 4/1/2007 8:07:18 PM
LastInspectedLogTime : 4/1/2007 8:07:18 PM
IsValid : True
ObjectState : Unchanged
Confirm
Restore-StorageGroupCopy failed to copy all remaining logs for 'First Storage Group'. Please use the Restore-StorageGroupCopy cmdlet in the Exchange Management Shell to copy all remaining log files. If you do not continue this operation, this task will still leave this copy in an unrestored state.
However, you can force an immediate restore if you confirm now.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):y
WARNING: Successfully created temporary log file during Restore-StorageGroupCopy operation for storage group copy (First Storage
Group).
WARNING: Restore-StorageGroupCopy for storage group First Storage Group was successful. All logs were not successfully copied.
Time of the failure was: 4/1/2007 3:11:50 PM.
Last log copied was 105 at 4/1/2007 8:07:18 PM.
Luego de montar la base de datos, verificamos que el directorio de trabajo no ha cambiado:
[PS] C:\>Get-MailboxDatabase |fl –property EdbFilePath
EdbFilePath : C:\Program Files\Microsoft\Exchange Server\Mailbox\FSG\Mailbox.edb
b. Reconfigurando el Storage Group.
Este método es más directo pero cambiará los directorios de trabajo, lo que puede generar confusión y problemas con tareas programadas que utilicen los directorios como parámetro.
Restore-StorageGroupCopy -Identity:”First Storage Group” -ReplaceLocations:$true
Esta es la salida de ejecución del parámetro anterior:
Base name: e00
Log file: C:\Program Files\Microsoft\Exchange Server\Mailbox\FSG\E000000005E.log
Csv file: C:\Program Files\Microsoft\Exchange Server\Mailbox\LocalCopies\IgnoredLogs\cinmpnn3.4ii
Base name: e00
Log file: C:\Program Files\Microsoft\Exchange Server\Mailbox\LocalCopies\E000000005E.log
Csv file: C:\Program Files\Microsoft\Exchange Server\Mailbox\LocalCopies\IgnoredLogs\ax0zpjrp.ptc
Integrity check passed for log file: C:\Program Files\Microsoft\Exchange Server\Mailbox\LocalCopies\inspector\E00.log
WARNING: The Restore-StorageGroupCopy operation for storage group copy First Storage Group was successful, and production paths were updated. All logs were successfully copied.
Podemos confirmar que el directorio de trabajo ha cambiado y la replicación deshabilitada:
[PS] C:\>get-mailboxdatabase|fl -Property edbfilepath
EdbFilePath : C:\Program Files\Microsoft\Exchange Server\Mailbox\LocalCopies\Mailbox Database.edb
[PS] C:\>Get-StorageGroup -identity "first storage group"
Name Server Replicated Recovery
---- ------ ---------- --------
First Storage Group LC2-E2K71 None False
4) Luego que el Storage group está en producción nuevamente, debemos borrar el contenido de las réplicas existentes y volver a habilitar la misma.
Pueden encontrar información adicional sobre LCR, CCR y SCC en la sección de Alta Disponibilidad de la documentación de Exchange 2007. Hay un Laboratorio Virtual disponible en TechNet para que puedas probar LCR en acción.
¡Hasta pronto!