Exchange 2010 DAG: Datenbankkopie mit Status „Failed and Suspended“ aktivieren

Ich teste gerade eine Exchange 2010 Database Availability Group mit zwei Servern. Ein Server hostet dabei die aktiven Datenbanken, der zweite Server dient ausschließlich als Backup und hostet nur passive Datenbankkopien.

Um einen automatischen Failover der Datenbanken zu verhindern, habe ich auf dem zweiten Server die DatabaseCopyAutoActivationPolicy auf Blocked gesetzt:

[PS] C:\Windows\system32>Set-MailboxServer 2010-mig-ex02 -DatabaseCopyAutoActivationPolicy Blocked

Name            DatabaseAvailab MAPIEncryptionRequired        AutoDatabaseMountDial        DatabaseCopyAutoActivationPo
                ilityGroup                                                                 licy
----            --------------- ----------------------        ---------------------        ----------------------------
2010-MIG-EX02   DAG001          False                         GoodAvailability             Blocked

In diesem Fall müssen die Datenbankkopien bei einer Downtime des primären Servers manuell aktiviert werden. Dabei gilt zu beachten, dass es sich bei diesem Vorgang um einen Switchover handelt und der Parameter MountDialOverride entscheidenen Einfluss auf den Erfolg der Aktion hat.

Wie auf folgendem Screenshot zu sehen ist, befindet sich die Kopie der Datenbank DB001 auf dem Server 2010-MIG-EX02 im Status „Healthy“ und die Queues sind leer, sprich die Kopie ist up to date:

Eine Überprüfung mit dem Cmdlet Get-MailboxDatabaseCopyStatus sieht ebenfalls gut aus:

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

Name                                          Status          CopyQueue ReplayQueue LastInspectedLogTime                       ContentIndex
                                                              Length    Length                                                 State
----                                          ------          --------- ----------- --------------------                       ------------
DB001\2010-MIG-EX02                           Healthy         0         0           15.06.2012 15:11:38                        Healthy

Und auch ein Test mittels Test-ReplicationHealth auf beiden Servern fördert keine Auffälligkeiten zu Tage:

[PS] C:\Windows\system32>Test-ReplicationHealth

Server          Check                      Result     Error
------          -----                      ------     -----
2010-MIG-EX02   ClusterService             Passed
2010-MIG-EX02   ReplayService              Passed
2010-MIG-EX02   ActiveManager              Passed
2010-MIG-EX02   TasksRpcListener           Passed
2010-MIG-EX02   TcpListener                Passed
2010-MIG-EX02   DagMembersUp               Passed
2010-MIG-EX02   ClusterNetwork             Passed
2010-MIG-EX02   QuorumGroup                Passed
2010-MIG-EX02   FileShareQuorum            Passed
2010-MIG-EX02   DBCopySuspended            Passed
2010-MIG-EX02   DBCopyFailed               Passed
2010-MIG-EX02   DBInitializing             Passed
2010-MIG-EX02   DBDisconnected             Passed
2010-MIG-EX02   DBLogCopyKeepingUp         Passed
2010-MIG-EX02   DBLogReplayKeepingUp       Passed

In einem Test simuliere ich auf dem Server 2010-MIG-EX01 den Ausfall des Storagesystems, auf dem sich die aktive Datenbank befindet. Dazu schalte ich die entsprechende Disk im Windows Disk Manager einfach auf „Offline“, so dass das entsprechende Laufwerk mit den Datenbankdateien von DB001 nicht mehr verfügbar ist.

Kurze Zeit später wechselt der Status der aktiven Datenbank auf „Dismounted“, die Kopie dagegen bleibt wie erwartet weiterhin „Healthy“:

Die Datenbankkopie kann danach problemlos aktiviert werden, indem man sie mit der rechten Maustaste anklickt, „Activate Database Copy“ wählt und eine der drei Optionen GoodAvailability, BestAvailability oder BestEffort für den Parameter MountDialOverride verwendet.

Bei der Auswahl von „GoodAvailability“ wird die Datenbank aktiviert, wenn die Copy Queue weniger oder gleich 6 ist, also sechs oder weniger Transaktionslogs fehlen. Wählt man „BestAvailability“, können 12 oder weniger Transaktionslogs fehlen. BestEffort hingegen aktiviert die Datenbank unabhängig von der Anzahl fehlender Logdateien.

Problematisch hingegen wird es, wenn die Option „Lossless“ gewählt wird. Dazu heißt es im Technet:

    If you specify this value, the database doesn’t automatically mount until all logs that were generated on the active copy have been copied to the passive copy.

Am Anfang dachte ich, dass die Option durchaus gewählt werden kann, solange die Copy Queue Length auf 0 steht. Tatsächlich erhielt ich beim Versuch, die Datenbank mit der Option „Lossless“ zu aktivieren, aber folgende Fehlermeldung:

--------------------------------------------------------
Microsoft Exchange Error
--------------------------------------------------------
Cannot activate database copy 'Activate Database Copy...'.

Activate Database Copy...
Failed
Error:
An Active Manager operation failed. Error The database action failed.
Error: The database was not mounted because it has experienced data
loss as a result of a switchover or failover, and the attempt to copy
the last logs from the source server failed. Please check the event
log for more detailed information. Specific error message: Attempt to
copy remaining log files failed for database DB001\2010-MIG-EX02
Error: The log copier was unable to continue processing for database
'DB001\2010-MIG-EX02' because the source server '2010-MIG-EX01.layer9.local'
returned an error: Invalid file path (-1023) [HResult: 0x80131501]. The
copier will automatically retry after a short delay.

. [Database: DB001, Server: 2010-mig-ex02.layer9.local]

An Active Manager operation failed. Error The database was not mounted
because it has experienced data loss as a result of a switchover or
failover, and the attempt to copy the last logs from the source server
failed. Please check the event log for more detailed information.
Specific error message: Attempt to copy remaining log files failed for
database DB001\2010-MIG-EX02. Error: The log copier was unable to continue
processing for database 'DB001\2010-MIG-EX02' because the source server
'2010-MIG-EX01.layer9.local' returned an error: Invalid file path (-1023)
[HResult: 0x80131501]. The copier will automatically retry after a short
delay.

. [Server: 2010-MIG-EX02.layer9.local]

Unmittelbar danach schlitterte die Datenbank in den wenig erfreulichen Status „Failed and Suspended“:

Äußerst negativ daran ist, dass sich eine Datenbank in diesem Status über die GUI nicht mehr aktivieren lässt. Das ist natürlich sehr schlecht, wenn der primäre Server gerade ausgefallen ist und die Kopie der Datenbank dringend benötigt wird.

Zum Glück gibt es aber für das Cmdlet Move-ActiveMailboxDatabase weitere Optionen, die über die GUI nicht verfügbar sind. Interessant für das aktuelle Problem ist der Parametet SkipHealthChecks:

    The SkipHealthChecks parameter specifies whether to bypass passive copy health checks. With the SkipHealthChecks parameter, you can move the active copy to a database copy that’s in the Failed state. This parameter should be used only if the initial attempt to move the active database has failed. This is because SkipHealthChecks performs additional validation to ensure that the log files are consistent, which can take a considerable amount of time.

Das klingt schon mal gut. Also ab in die PowerShell und folgenden Befehl abfeuern:

[PS] C:\Windows\system32>Move-ActiveMailboxDatabase -Identity "DB001" -ActivateOnServer "2010-mig-ex02" -MountDialOverride "BestAvailability" -SkipHealthChecks

Confirm
Are you sure you want to perform this action?
Moving mailbox database "DB001" from server "2010-MIG-EX01.layer9.local" to server "2010-MIG-EX02.layer9.local".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

…was aber leider aufgrund fehlerhafter Content Index Catalog Files ebenfalls fehlschlägt; obwohl der Content Index State bei der letzten Überprüfung (siehe oben) noch Healthy war:

Identity        ActiveServerAtS ActiveServerAtE Status     NumberOfLogsLost   RecoveryPoint MountStatus MountStatus
                tart            nd                                            Objective     AtMoveStart AtMoveEnd
--------        --------------- --------------- ------     ----------------   ------------- ----------- -----------
DB001           2010-mig-ex01   2010-mig-ex01   Failed                                      Dismounted  Dismounted
An Active Manager operation failed. Error The database action failed. Error: An error occurred while trying to validate the specified datab
ase copy for possible activation. Error: Database copy 'DB001' on server '2010-MIG-EX02.layer9.local' has content index catalog files in the f
ollowing state: 'Failed'.. [Database: DB001, Server: 2010-mig-ex02.layer9.local]
    + CategoryInfo          : InvalidOperation: (DB001:ADObjectId) [Move-ActiveMailboxDatabase], AmDbActionWrapperException
    + FullyQualifiedErrorId : 53570C59,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveActiveMailboxDatabase

Zum Glück gibt es aber mit SkipClientExperienceChecks einen Parameter, mit dem sich auch die Überprüfung des Content Index deaktivieren lässt:

    The SkipClientExperienceChecks parameter specifies whether to skip the search catalog (content index) state check to see if the search catalog is healthy and up to date. If the search catalog for the database copy you’re activating is in an unhealthy or unusable state and you use this parameter to skip the search catalog health check and activate the database copy, you will need to either re-crawl or reseed the search catalog.

Also noch mal zurück in die PowerShell und den entsprechenden erweiterten Befehl anwenden:

[PS] C:\Windows\system32>Move-ActiveMailboxDatabase -Identity "DB001" -ActivateOnServer "2010-mig-ex02" -MountDialOverride "BestAvailability
" -SkipClientExperienceChecks -SkipHealthChecks

Confirm
Are you sure you want to perform this action?
Moving mailbox database "DB001" from server "2010-MIG-EX01.layer9.local" to server "2010-MIG-EX02.layer9.local".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

Identity        ActiveServerAtS ActiveServerAtE Status     NumberOfLogsLost   RecoveryPoint MountStatus MountStatus
                tart            nd                                            Objective     AtMoveStart AtMoveEnd
--------        --------------- --------------- ------     ----------------   ------------- ----------- -----------
DB001           2010-mig-ex01   2010-mig-ex02   Succeeded  1                  15.06.2012... Dismounted  Mounted

Damit klappt es dann endlich: Die Datenbank ist aktiviert und wieder online. In der Exchange Management Console wird die Änderung entsprechend sichtbar:

Der Status des Content Index ist interessanterweise auch wieder Healthy:

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

Name                                          Status          CopyQueue ReplayQueue LastInspectedLogTime                       ContentIndex
                                                              Length    Length                                                 State
----                                          ------          --------- ----------- --------------------                       ------------
DB001\2010-MIG-EX02                           Healthy         0         0           15.06.2012 15:11:38                        Healthy

Nachdem das Storage des primären Servers wieder verfügbar ist, kann mittels Rechtsklick auf die dortige Datenbank und einem „Resume Database Copy“ die Datenbank wieder aktualisiert werden. Anschließend kann Sie über die GUI auch wieder aktiv geschaltet werden. Dabei kann auch problemlos Lossless verwendet werden – schließlich steht die Quelle in diesem Fall zur Verfügung und alle Logs können entsprechend kopiert werden.

Man lerne daraus: Bei einem manuellen Switchover sollte keinesfalls die Option „Lossless“ gewählt werden, wenn die Quelle nicht erreichbar ist.

Warum der Fehler bei einem automatischen Failover nicht auftritt, ist auch klar: Der Standardwert des Parameters AutoDatabaseMountDial steht auf GoodAvailability – d.h. solange die Copy Queue nicht größer als 6 ist, funktioniert alles problemlos. Würde der Standardwert dagegen auf Lossless stehen, käme es zum beschriebenen Problem.

Evtl. ist es sogar eine gute Idee, die AutoDatabaseMountDial auf einen etwas toleranteren Wert zu setzen, z.B. BestAvailability. In diesem Fall dürfen 12 Logdateien fehlen, was aber wiederum auch nur 12MB sind und in der Regel verkraftbar sein dürfte.

0 Responses to “Exchange 2010 DAG: Datenbankkopie mit Status „Failed and Suspended“ aktivieren”



  1. Schreibe einen Kommentar

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s





%d Bloggern gefällt das: