Fortlaufende Standbyreplikation: Datenbankportabilität
Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1
Letztes Änderungsdatum des Themas: 2008-11-18
In diesem Thema wird ein Szenario beschrieben, in dem eine Organisation (Woodgrove Bank) fortlaufende Standbyreplikation (Standby Continuous Replication, SCR) sowie Datenbankportabilität verwendet, um die Wiederherstellung nach dem Ausfall einer einzelnen Datenbank vorzunehmen. In diesem Szenario wird festgestellt, dass eine SCR-Quelldatenbank physikalische Fehler aufweist, und der Administrator trifft die Entscheidung, die SCR-Zieldatenbank zu aktivieren. Während der Aktivierung wird die fortlaufende Standbyreplikation deaktiviert, die SCR-Zieldatenbank als Produktionsdatenbank bereitgestellt, und Benutzerpostfächer werden ausgelagert. Nachdem der Datenzugriff für Clients wiederhergestellt wurde, wird die fortlaufende Standbyreplikation für die Speichergruppe erneut aktiviert, um die Redundanz und den Schutz für das SCR-Ziel wiederherzustellen.
SCR und Datenbankportabilität
Woodgrove Bank hat Microsoft Exchange Server 2007 Service Pack 1 (SP1) bereitgestellt und sich entschieden, fortlaufende Standbyreplikation zum Bereitstellen einer redundanten Kopie der Speichergruppe auf einem Remotepostfachserver zu verwenden. Beide Postfachserver befinden sich am gleichen Standort des Active Directory-Verzeichnisdiensts und sind für die Verwendung Active Directory-integrierter DNS-Server konfiguriert. Das Active Directory-Replikationsintervall für den Active Directory-Standort ist mit 15 Minuten konfiguriert.
Die fortlaufende Standbyreplikation ist so konfiguriert, dass die Protokolldateien für eine einzelne Speichergruppe (SG1) repliziert werden, die eine einzelne Datenbank (MBX1) enthält. EXMBX1 ist der SCR-Quellcomputer, EXMBX2 der SCR-Zielcomputer. Die Pfade für die Speichergruppendateien (die auch die Transaktionsprotokolldateien umfassen) und die Datenbankdatei lauten E:\SG1 und D:\SG1\MBX1.EDB. Diese Pfade werden sowohl auf dem Quell- als auch auf dem Zielcomputer verwendet.
Diese Zuordnungen wurden mithilfe des folgenden Befehls konfiguriert:
Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
Der Zustand und Status der fortlaufenden Standbyreplikation für SG1 wurden mithilfe der Cmdlets Test-ReplicationHealth und Get-StorageGroupCopyStatus in der Exchange-Verwaltungsshell überprüft. Beispiel:
Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2 | fl
Um während des SCR-Zielaktivierungsvorgangs Zeit zu sparen, ist EXMBX2 mit einer Speichergruppe und einer Datenbank vorkonfiguriert, die als Teil der Datenbankportabilitätsvorgänge verwendet werden. Die Speichergruppe bzw. die Datenbank tragen die Namen SG1PORT und MBX1PORT.
Wichtig
SG1PORT und MBX1PORT sind von der Speichergruppe des SCR-Ziels und den Datenbankdateien getrennt. Aus diesem Grund sollten die Pfade für SG1PORT und MBX1PORT mit einem temporären Pfad konfiguriert werden, der keinen Konflikt mit den SCR-Zielpfaden verursacht.
Hinweis
Nachdem MBX1PORT erstellt wurde, wird empfohlen, die Datenbank bereitzustellen und diese Bereitstellung dann aufzuheben sowie alle Speichergruppendateien und Datenbankdateien zu löschen.
SCR-Zielaktivierung
Ein Messagingadministrator entdeckt einen Eintrag im Anwendungsprotokoll, der anzeigt, dass die SCR-Quelldatenbank einen physikalischen Fehler aufweist. Weil die fortlaufende Standbyreplikation für SG1 aktiviert war, wird schnell die Entscheidung gefällt, eine manuelle Aktivierung der SCR-Zieldatenbank für SG1 auszuführen und die Datenverfügbarkeit wiederherzustellen. Die Aktivierung der SCR-Zielkopie beginnt mit der Aufhebung der Bereitstellung der Datenbank in SG1. Anschließend wird die SCR-Zieldatenbank für die Bereitstellung vorbereitet, und die Postfächer der betroffenen Postfachdatenbank werden verschoben. Dies wird erreicht, indem die folgenden Schritte in der angegebenen Reihenfolge ausgeführt werden:
Die Bereitstellung der SCR-Quelldatenbank wird mithilfe des folgenden Befehls aufgehoben:
Dismount-Database EXMBX1\SG1\MBX1Der Prozess zum Deaktivieren der fortlaufenden Standbyreplikation und zum Vorbereiten der SCR-Zieldatenbank für die Bereitstellung beinhaltet die Ausführung des Cmdlets Restore-StorageGroupCopy. Dieser Task markiert die Datenbank der Speichergruppe als bereitstellbar und stellt einen Bericht zu den Datenverlusten zur Verfügung, die sich ggf. aus der Bereitstellung der Datenbank in der Speichergruppe ergeben. Er bestätigt außerdem, dass alle von der aktiven Kopie der Speichergruppe generierten Protokolldateien am Dateispeicherort der Speichergruppe der passiven Kopie vorhanden sind. Sollten Protokolldateien fehlen, versucht der Vorgang, die fehlenden Protokolldateien zu kopieren. Die fortlaufende Standbyreplikation wird deaktiviert und die Zieldatenbank mithilfe des folgenden Befehls auf die Bereitstellung vorbereitet:
Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
Wichtig
Wenn die SCR-Quelle nicht verfügbar ist, muss der Parameter Force dem Befehl Restore-StorageGroupCopy hinzugefügt werden.
Nach der Ausführung des Befehls Restore-StorageGroupCopy sollte ein Administrator überprüfen, ob sich die Datenbank im Zustand Clean Shutdown befindet. Wenn sich die Datenbank im Zustand Dirty Shutdown befindet, kann der Administrator die Datenbank in den Zustand Clean Shutdown versetzen, indem er die Exchange Server-Datenbankdienstprogramme (Eseutil) im Wiederherstellungsmodus (Eseutil /r) für die Datenbank ausführt. Genaue Anweisungen zum Ausführen von Eseutil im Wiederherstellungsmodus finden Sie unter Ausführen von Eseutil /R (Wiederherstellung).
Hinweis
Wenn das Speichergruppenpräfix (z. B. E00 oder E01) für die SCR-Quelle (EXMBX1\SG1) und die SCR-Zielspeichergruppe, die für die Datenbankportabilität verwendet wird (EXMBX2\SG1PORT), identisch ist, muss Eseutil nicht im Wiederherstellungsmodus ausgeführt werden. Der abschließende Vorgang der Datenbankbereitstellung versetzt die Datenbank in den Zustand Clean Shutdown, nachdem alle replizierten Protokolldateien wiedergegeben wurden.
Nachdem sich die Datenbank im Zustand Clean Shutdown befindet, führt der Administrator zwei Befehle aus, die Active Directory mit den neuen Speicherorten für die Dateien der Speichergruppe und die Datenbankdatei aktualisieren. Verwenden Sie die folgenden Befehle, um die Pfade für SG1PORT und MBX1PORT aus den temporären Pfaden in die Pfade für die Speichergruppen- und Datenbankdateien des SCR-Ziels zu ändern:
Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath E:\SG1 -LogFolderPath E:\SG1 -ConfigurationOnly Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath D:\SG1\MBX1.EDB -ConfigurationOnlyAnschließend muss die Datenbank während eines Wiederherstellungsvorgangs überschrieben werden. Aktivieren Sie zu diesem Zweck das Kontrollkästchen Diese Datenbank kann bei einer Wiederherstellung überschrieben werden unter den Eigenschaften des Datenbankobjekts in der Exchange-Verwaltungskonsole. Dieser Task kann auch mithilfe des folgenden Befehls in der Exchange-Verwaltungsshell ausgeführt werden:
Set-Mailboxdatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$trueNachdem die Datenbank für den Überschreibvorgang während einer Wiederherstellung konfiguriert wurde, kann der Administrator die Datenbank mithilfe des folgenden Befehls bereitstellen:
Mount-Database EXMBX2\SG1PORT\MBX1PORTNachdem die Datenbank bereitgestellt wurde, müssen die Postfächer, die in der SCR-Quelldatenbank gespeichert waren, so verschoben werden, dass sie auf MBX1PORT in EXMBX2 verweisen. Führen Sie zu diesem Zweck das Cmdlet Get-Mailbox aus, und leiten Sie die Ausgabe mittels Pipelining an das Cmdlet Move-Mailbox um. Während dieses Vorgangs ist es wichtig, dass die Microsoft Exchange-Systemaufsichts- und -Systempostfächer nicht in die Ausgabe des Cmdlets Get-Mailbox eingeschlossen werden, die mittels Pipelining an das Cmdlet Move-Mailbox umgeleitet wird. Führen Sie zu diesem Zweck den folgenden Befehl aus:
Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT
An diesem Punkt ist der Clientzugriff auf MBX1PORT möglich. Ob Benutzer jedoch tatsächlich auf ihre Postfächer zugreifen können, nachdem diese von EXMBX1\SG1\MBX1 nach EXMBX2\SG1PORT\MBX1PORT verschoben wurden, hängt von mehreren Faktoren ab:
Active Directory-Replikationswartezeit Abhängig von der Anzahl der Verzeichnisserver kann es einige Zeit dauern, bis die Aktualisierung in der Umgebung repliziert wurde.
Clientzugriffsmethode Messagingclients, die Microsoft Office Outlook 2007 und Nicht-Outlook-Clients ausführen, besitzen Zugriff auf das Postfach des Benutzers, nachdem die vom Clientzugriffsserver des Benutzers verwendeten Verzeichnisserver mit den neuen Pfaden aktualisiert wurden. Für Messagingclients, die Outlook 2003 oder eine frühere Version ausführen, muss das Desktopmessagingprofil des Benutzers mit dem neuen Servernamen aktualisiert werden, wenn der ursprüngliche Server ausgefallen oder anderweitig nicht verfügbar ist. Wenn der ursprüngliche Server online und für Antworten auf Clientanforderungen verfügbar ist, wird das Desktopmessagingprofil von Messagingclients, die Outlook 2003 oder eine frühere Version ausführen, automatisch durch den ursprünglichen Server mit dem Namen des neuen Servers aktualisiert, und das Desktopmessagingprofil muss nicht manuell geändert werden.
Wiederherstellen der Redundanz nach der SCR-Zielaktivierung
Nachdem Clients Zugriff auf ihre Postfächer und Postfachdaten besitzen, besteht der abschließende Schritt im Wiederherstellen der Redundanz durch erneutes Aktivieren der fortlaufenden Standbyreplikation. Dies geschieht durch Entfernen verbleibender Speichergruppen- und Datenbankdateien aus EXMBX1. Nachdem diese Dateien entfernt wurden, können die Pfade für EXMBX1\SG1\MBX1 an einen temporären Speicherort verschoben werden, und EXMBX1 kann zu einem SCR-Ziel von EXMBX2 werden. Nachdem dieser Vorgang abgeschlossen ist, wurde die Redundanz in der Umgebung wiederhergestellt.