Implementando DAG en Exchange 2010 (Parte III)


por Daniel Seveso

Este es el último artículo de esta serie y continuación de la Parte I y Parte II. Partimos de un una configuración de DAG de dos nodos donde cada nodo correrá todos los roles de Exchange. Esta es la mínima expresión posible de alta disponibilidad con Exchange 2010, siendo aún una configuración válida para un ambiente de producción.

 

Agregando replicas de bases de datos al DAG

En el artículo anterior, creamos un DAG e incluímos los dos nodos como miembros del mismo. Para que el DAG tenga sentido práctico, tenemos que crear copias de las bases de datos activas.  Desde el Exchange Management Console usaré la opción “Add Mailbox Database Copy…” para agregar una copia de DB1 en el servidor LABE2K10-2:

image

Seleccionamos LABE2K10-2 para definir la copia y proseguimos con el botón “Add”.

image

Obtendremos un reporte del resultado de nuestra operación:

image

Una vez completo el procedimiento de copia, la misma aparecerá en la sección “Database Copies” cuando seleccionamos la base de datos en la ventana superior. “Copy Status” indica cual es el estado actual de la copia.

image

Es interesante revisar en el log de aplicación, el proceso de “seeding” durante la copia de la base de datos al  servidor LABE2K10-2.

Log Name:      Application
Source:        MSExchangeRepl
Event ID:      4022
Level:         Information
Computer:      LabE2K10-2.lab10.net
Description:
A new seed request has been added to the queue for database ‘DB1’ with the following arguments:

RpcSeederArgs: [ InstanceGuid=’a41907df-9961-4d0b-be23-367b4ac5a1a4′, DeleteExistingFiles=’True’, AutoSuspend=’True’, SeedingPath=”, LogFolderPath=”, NetworkId=”, StreamingBackup=’False’, SourceMachineName=”, DatabaseName=”, ManualResume=’False’, SeedDatabase=’1′, SeedCiFiles=’1′, CompressOverride=”='<null>’, EncryptOverride=’='<null>’ ].

Log Name:      Application
Source:        MSExchangeRepl
Event ID:      4028
Level:         Information
Computer:      LabE2K10-2.lab10.net
Description:
Seed request for database ‘DB1’ has been processed and seeding will now begin.

Log Name:      Application
Source:        MSExchangeRepl
Event ID:      4037
Level:         Information
Computer:      LabE2K10-2.lab10.net
Description:
Seed request for database ‘DB1’ has been successfully completed.

Luego que el seeding finaliza (copia del archivo EDB), comienza la copia de los logs de transacciones. Como esta base nunca ha sido respaldada, el servicio de replicación MSExchangeRepl en el servidor LABE2K10-2 comienza la copia desde el primer log (generation 1)

Log Name:      Application
Source:        MSExchangeRepl
Event ID:      2114
Level:         Information
Computer:      LabE2K10-2.lab10.net
Description:
The replication instance for database DB1 has started copying log files. The first log file copied was generation 1.

Pueden observar que la copia de la base de datos en el servidor LABE2K10-2 utilizó los mismos directorios y unidades usados por la base de datos original en el servidor LABE2K10-1:

image

La información del catálogo de búsqueda también es copiada durante el proceso desde el servidor que posee  la copia activa de la base de datos (directorio CatalogData…)’

Usaré ahora Power Shell (en adelante PS) para copiar la segunda base de datos DB2, asi pueden comparar los dos métodos.

El comando completo es:

[PS] C:\>Add-MailboxDatabaseCopy -Identity ‘DB2’ -MailboxServer ‘LABE2K10-1’ -ActivationPreference ‘2’

ActivationPreference es el parámetro diferenciador que el servicio de Active Manager tomará en cuenta cuando haya más de una base de datos que cumple las condiciones de volverse activa en caso de failover o switchover

image 

El comando Get-DatabaseCopyStatus nos dirá cual es el estado de una base en particular y todas sus copias en el DAG. Marqué en rojo los valores relevantes en nuestro contexto. Noten la información en la copia sobre el estado de la replicación (CopyQueueLength, LastReplayedLogTime, etc):

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus DB2 |fl

RunspaceId                       : 2c63732a-5bd2-478b-94ad-b8dc8b9f3422
Identity                         : DB2\LABE2K10-2
Name                             : DB2\LABE2K10-2
DatabaseName                     : DB2
Status                           : Mounted

MailboxServer                    : LABE2K10-2
ActiveDatabaseCopy               : labe2k10-2

ActivationSuspended              : False
ActionInitiator                  : Unknown
ErrorMessage                     :
ErrorEventId                     :
ExtendedErrorInfo                :
SuspendComment                   :
SinglePageRestore                : 0
ContentIndexState                : Healthy
CopyQueueLength                  : 0
ReplayQueueLength                : 0
LatestAvailableLogTime           :
LastCopyNotificationedLogTime    :
LastCopiedLogTime                :
LastInspectedLogTime             :
LastReplayedLogTime              :
LastLogGenerated                 : 0
LastLogCopyNotified              : 0
LastLogCopied                    : 0
LastLogInspected                 : 0
LastLogReplayed                  : 0
LatestFullBackupTime             :
LatestIncrementalBackupTime      :
LatestDifferentialBackupTime     :
LatestCopyBackupTime             :
SnapshotBackup                   :
SnapshotLatestFullBackup         :
SnapshotLatestIncrementalBackup  :
SnapshotLatestDifferentialBackup :
SnapshotLatestCopyBackup         :
LogReplayQueueIncreasing         : False
LogCopyQueueIncreasing           : False
OutstandingDumpsterRequests      : {}
OutgoingConnections              :
IncomingLogCopyingNetwork        :
SeedingNetwork                   :
ActiveCopy                       : True

RunspaceId                       : 2c63732a-5bd2-478b-94ad-b8dc8b9f3422
Identity                         : DB2\LABE2K10-1
Name                             : DB2\LABE2K10-1
DatabaseName                     : DB2
Status                           : Healthy
MailboxServer                    : LABE2K10-1
ActiveDatabaseCopy               : labe2k10-2

ActivationSuspended              : False
ActionInitiator                  : Service
ErrorMessage                     :
ErrorEventId                     :
ExtendedErrorInfo                :
SuspendComment                   :
SinglePageRestore                : 0
ContentIndexState                : Healthy
CopyQueueLength                  : 0
ReplayQueueLength                : 0
LatestAvailableLogTime           : 4/2/2010 1:23:07 PM
LastCopyNotificationedLogTime    : 4/2/2010 1:23:07 PM
LastCopiedLogTime                : 4/2/2010 1:23:07 PM
LastInspectedLogTime             : 4/2/2010 1:23:07 PM
LastReplayedLogTime              : 4/2/2010 1:23:07 PM
LastLogGenerated                 : 11
LastLogCopyNotified              : 11
LastLogCopied                    : 11
LastLogInspected                 : 11
LastLogReplayed                  : 11
LatestFullBackupTime             :
LatestIncrementalBackupTime      :
LatestDifferentialBackupTime     :
LatestCopyBackupTime             :
SnapshotBackup                   :
SnapshotLatestFullBackup         :
SnapshotLatestIncrementalBackup  :
SnapshotLatestDifferentialBackup :
SnapshotLatestCopyBackup         :
LogReplayQueueIncreasing         : False
LogCopyQueueIncreasing           : False
OutstandingDumpsterRequests      : {}
OutgoingConnections              :
IncomingLogCopyingNetwork        :
SeedingNetwork                   :
ActiveCopy                       : False

Swithover

Switchover es el término que encontrarán el la documentación de Exchange 2010 refiriendo a la operación manual de activar la copia de una base de datos. La diferencia con “Failover” es que el failover activa la copia como consecuencia de una falla en la base de datos o el servidor que tiene la copia activa.

Para confirmar que todo funcione correctamente, iniciamos un switchover de DB1 (activaremos la copia que reside en LABE2K10-2). Hay tres formas de realizar un switchover. Usando el asistente “Move Active Mailbox Database”, usando el menú de contexto “Activate Database Copy…” (ambase en el Exchange Management Console), o desde PS mediante el comando:

[PS] C:\>Move-ActiveMailboxDatabase -Identity ‘DB1’ -ActivateOnServer ‘LABE2K10-2’ -MountDialOverride ‘Lossless’

Usaré el asistente para activar DB1:

image

image

La opción “Override automatic database mount dial setting..” permite indicar una configuración diferente del parámetro “AutoDatabaseMountDial” configurado en el mailbox server. Este parámetro define que tipo de tolerancia a pérdida de información vamos a permitir. Cuando hacemos un switchover, asumimos que el servidor con la copia activa está en línea, y por lo tanto elegiremos normalmente “Lossless”, opción que requiere que todos los logs de transacciones sean copiados desde el nodo activo antes de activar y montar la copia, por lo tanto, sin pérdida de información.

image

image

Si inspeccionamos el status en PS veremos que la base está montada en LABE2K10-2

[PS] C:\>Get-MailboxDatabaseCopyStatus DB1

Name             Status   CopyQueue ReplayQueue LastInspectedLogTime   ContentIndex
                          Length    Length                             State
—-             ——   ——— ———– ——————–   ————
DB1\LABE2K10-1   Healthy  0         0           4/2/2010 3:46:56 PM    Healthy
DB1\LABE2K10-2   Mounted  0         0                                  Healthy

 

Failover

Esta prueba no tiene mucho vértigo en un artículo 🙂 …sería más interesante verla en una demo, pero aquí va de todas formas. Partimos del estado inicial en que ambas bases están activas en el nodo LABE2K10-1.

[PS] C:\>Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus

Name            Status          CopyQueue ReplayQueue LastInspectedLogTime   ContentIndex
                                Length    Length                             State
—-            ——          ——— ———– ——————–   ————
DB1\LABE2K10-1  Mounted         0         0                                  Healthy
DB1\LABE2K10-2  Healthy         0         0           4/2/2010 4:15:07 PM    Healthy
DB2\LABE2K10-2  Healthy         0         0           4/2/2010 4:03:02 PM    Healthy
DB2\LABE2K10-1  Mounted         0         0                                  Healthy

 

Simularé una falla simplemente pausando la ejecución del nodo LABE2K10-1 en Hyper-V y ejecutando repetidas veces el siguiente comando. Los siguientes son los dos estados por el cual pasa la operación:

[PS] C:\>Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus

Name            Status          CopyQueue ReplayQueue LastInspectedLogTime   ContentIndex
                                Length    Length                             State
—-            ——          ——— ———– ——————–   ————
DB1\LABE2K10-1  ServiceDown     0         0                                  Unknown
DB1\LABE2K10-2  Healthy         0         0           4/2/2010 4:30:12 PM    Healthy
DB2\LABE2K10-2  Healthy         0         0           4/2/2010 4:29:07 PM    Healthy
DB2\LABE2K10-1  ServiceDown     0         0                                  Unknown

[PS] C:\>Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus

Name            Status          CopyQueue ReplayQueue LastInspectedLogTime   ContentIndex
                                Length    Length                             State
—-            ——          ——— ———– ——————–   ————
DB1\ALBE2K10-1  ServiceDown     0         0                                  Unknown
DB1\LABE2K10-2  Mounted         0         0                                  Healthy
DB2\LABE2K10-2  Mounted         0         0                                  Healthy
DB2\LABE2K10-1  ServiceDown     0         0                                  Unknown

 

Las bases quedarán activas en el nodo LABE2K10-2 luego de pequeño lapso de tiempo (< 1min).

Es interesante también revisar el log de aplicaciones del nodo LABE2K10-2 y observar la secuencia de eventos desde que el cluster service pierde comunicación con el nodo LABE2K10-1 en adelante. No incluiré los eventos porque escapa al objetivo de este artículo, solo mencionaré la lista de acciones:

  • El servicio Replication informa cuantos logs faltan y de acuerdo a esto cual será la acción a tomar con la base de datos (montarla o no montarla automáticamente)
  • El servicio Information Store informa si el failover implicará perdida de inforamción (lossy failover)
  • El servicio ESE comienza la incorporación de los logs de transacciones pendientes para montar las bases de datos
  • El Active Manager avisa del movimiento de cada base activa de LABE2K10-1 a LABE2K10-2
  • El Active Manager avisa que ha montado la base de datos y en qué server
  • El servicio Search Indexer resume el indexado de las bases de datos en el nodo LABE2K10-2

 

Referencias

Puedes encontrar información y referencias sobre DAG en mi artículo anterior.

Comments (3)

  1. LatamBlog says:

    Hola Juan Ramon,

    Muchas gracias por tus comentarios,

    Nuestro blog tiene un foco en los aspectos técnicos, de soporte y de funcionalidad de varios productos Microsoft.

    Por información de ventas puedes consultar el sitio de Microsoft Latinoamérica (http://www.microsoft.com/es/xl/default.aspx) y también el sitio de comunidades en español que lo eliges de la barra de menú.

    Saludos!

  2. juannramon says:

    no soy un experto  pero gracia s paor  lainformacion mi trabajo  consiste en instalacio y enta  de software me gustaria  al g respecto  eso esto es algo qu yo prendi empiricamaente por  medio de la experinecia de natemano gracias por la ayuda recibida

  3. juannramon says:

    me parece una exelete  eidea que nos den a oportunidad  de creaar ser part parte  de estod proyectos par agente  tan preparada gracias por tu ayuda