Kommunikation

Fortlaufende Standbyreplikation in Exchange Server 2007 Service Pack 1

Scott Schnoll

Kurz zusammengefasst:

• Konfigurieren der fortlaufenden Standbyreplikation
• Die Bedeutung von Redundanz
• Wie SCR Ausfallzeiten verringert

Service Pack 1 stellt mehrere neue Features und Verbesserungen für Exchange 2007 bereit. Eines dieser neuen Features, SCR (Standby Continuous Replication), dient dem Zweck, Organisationen sowohl Redundanz im Datencenter als auch Standortsicherheit bereitzustellen. Wie der Name bereits erkennen lässt, wurde SCR für

Szenarios entwickelt, in denen Standbywiederherstellungsserver verwendet werden oder die Verwendung solcher Server ermöglicht wurde.

Wenn Sie mit der Produktionsfreigabeversion (Release to Manufacturing, RTM) von Exchange 2007 vertraut sind, dann wissen Sie, dass diese Version über Protokollversandfeatures ebenfalls Redundanz im Datencenter und Standortsicherheit bietet und Windows®-Failovercluster unterstützt. In der RTM-Version steht Protokollversand (offiziell als „fortlaufende Replikation“ bezeichnet) in zwei Formen zur Verfügung: als fortlaufende lokale Replikation (Local Continuous Replication, LCR, siehe Abbildung 1) und als fortlaufende Clusterreplikation (Cluster Continuous Replication, CCR, siehe Abbildung 2).

Abbildung 1** LCR (Local Continuous Replication) **

Abbildung 2** Bei CCR findet der Protokollversand zu einem zweiten Server in einem Windows-Failovercluster statt **

Fortlaufende Replikation stellt Datenverfügbarkeit und Redundanz bereit, indem Administratoren ermöglicht wird, online ein Zweitexemplar jeder Postfachdatenbank zu aktivieren und zu verwalten. Diese Datenbankkopie bildet die erste Verteidigungslinie gegen Ausfall, Verlust oder Beschädigung einer Produktionsdatenbank. Statt Zeit auf die Suche eines Datensicherungsbands zur Wiederherstellung der Daten zu verschwenden, kann innerhalb weniger Minuten eine Datenbankkopie aktiviert und in eine Produktionsdatenbank verwandelt werden.

SCR erweitert die Szenarios, in denen Sie für Ihre Organisation die Verfügbarkeit von Daten und Diensten erreichen können. Die neuen Szenarios ermöglichen Ihnen, Topologien mit hoher Verfügbarkeit von Topologien mit Standortsicherheit zu trennen, und erlauben Ihnen zugleich, Konfigurationen bereitzustellen, die auf die spezifischen Anforderungen Ihrer Organisation in jedem Bereich zugeschnitten sind.

Die RTM-Version von Exchange 2007 stellt Redundanz im Datencenter und Standortsicherheit bereit, aber da LCR und CCR nur eine einzige zusätzliche Kopie jeder Datenbank bereitstellen, müssen Sie zwischen Standortsicherheit und Redundanz wählen. Bedenken Sie beispielsweise die von CCR bereitgestellten Möglichkeiten der Daten- und Dienstverfügbarkeit. In einem einzelnen Datencenter sowohl den aktiven als auch den passiven Knoten einzusetzen, liefert zwar Dienst- und Datenverfügbarkeit im Datencenter, aber keine Standortsicherheit (weil sich beide Knoten am selben physischen Standort befinden). Den aktiven Knoten in einem Datencenter und den passiven Knoten in einem zweiten Datencenter einzusetzen, bietet Ihnen zwar Standortsicherheit, aber keine Verfügbarkeit im Datencenter (weil sich der passive Knoten, der diese Features bereitstellt, in einem zweiten Datencenter befindet).

Da Sie mit SCR in Service Pack 1 zusätzliche Kopien jeder Datenbank erstellen können, schließen sich hohe Verfügbarkeit und Standortsicherheit nicht mehr gegenseitig aus. Sie können beispielsweise, wie in Abbildung 3 gezeigt, SCR mit CCR kombinieren, um Speichergruppen lokal in einem primären Datencenter zu replizieren (durch CCR, um hohe Verfügbarkeit zu erreichen) und um sie von einem Remotestandort aus in einem zweiten Datencenter oder einem Backupdatencenter zu replizieren (durch SCR, um Standortsicherheit zu erreichen). Das zweite Datencenter enthält einen Standbycluster, der in einem Standortwiederherstellungsszenario mit einem Ersatzpostfachclusterserver aktiviert und schnell bereitgestellt werden kann.

Abbildung 3** Ein Datencenter in Redmond nutzt CCR und ein Datencenter in Quincy nutzt SCR **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 3 zeigt eine Unternehmensbereitstellung mit zwei Datencentern mit jeweils eigenem Active Directory®-Standort: Redmond und Quincy. Der Standort in Redmond befindet sich im primären Datencenter (Produktionsdatencenter) und der Standort in Quincy in einem zweiten Datencenter (Backupdatencenter). In Redmond wird CCR genutzt, um Redundanz im Datencenter zu erzielen. Zusammen mit den für Exchange 2007 benötigten Infrastrukturelementen werden auf einem Standbycluster in Quincy SCR-Ziele konfiguriert, um Standortsicherheit zu erreichen. Diese zusätzlichen Infrastrukturelemente, zu denen Clientzugriffs- und Hub-Transport-Server, Active Directory- und DNS-Server sowie Internetzugang gehören, können dedizierte oder nicht dedizierte Ressourcen sein. Dedizierte Ressourcen sind dazu bestimmt, nur die Benutzer des Datencenters zu unterstützen, in dem sie sich befinden. Nicht dedizierte Ressourcen dagegen unterstützen sowohl Benutzer im lokalen Datencenter als auch Benutzer an anderen Standorten. Sie müssen abhängig von den Gegebenheiten in Ihrer Organisation entscheiden, ob Ressourcen dediziert oder nicht dediziert sein sollen. Weitere Informationen zu dedizierten und nicht dedizierten Ressourcen finden Sie in der Hilfedatei von Exchange Server 2007 unter technet.microsoft.com/bb201662.aspx unter dem Thema „Standortsicherheitskonfigurationen“. Beachten Sie auch, dass ein neues MNS (Majority Node Set)-Quorum verwendet wird. Wie Sie in Abbildung 3 sehen können, verwendet CCR in Exchange Server 2007 statt des herkömmlichen Voterknotens das MNS-Quorum mit Dateifreigabenzeuge (File Share Witness, FSW).

In Abbildung 4 stellt eine Umgebung mit CCR und SCR, die für Stabilität eingerichtet wurde, für die Postfächer und die auf dem Server „EXCLUS1“ gehosteten Dienste mehrere Schichten von Redundanz bereit und schützt dadurch diese Postfächer vor kleinen bis großen katastrophalen Ausfällen.

Abbildung 4** Eigenständige Postfachserver, die zum gegenseitigen Replizieren von Speichergruppen SCR verwenden **(Klicken Sie zum Vergrößern auf das Bild)

Kleine und mittlere Organisationen können ebenfalls von SCR profitieren. Wie in Abbildung 4 gezeigt, kann eine Organisation beispielsweise zwei eigenständige Postfachserver („EXMBX1“ und „EXMBX2“) einsetzen und SCR dazu verwenden, einige oder alle Speichergruppen von einem Postfachserver zum nächsten zu replizieren.

In diesem Beispiel handelt es sich sowohl bei „EXMBX1“ als auch bei „EXMBX2“ um Produktionsserver mit fünf aktiven Speichergruppen. Jede Speichergruppe ist eine SCR-Quelle für ein entsprechendes SCR-Ziel auf dem anderen Server. Beim Eintreten eines Speicherausfalls oder eines anderen Ereignisses, das dazu führt, dass eine als SCR-Quelle konfigurierte aktive Speichergruppe nicht verfügbar ist, kann die SCR-Zielkopie mit wenigen administrativen Aufgaben in der Exchange-Verwaltungsshell schnell aktiviert werden. Mit Microsoft® Office Outlook® 2007 und der Datenbankportabilität sowie dem AutoErmittlungsdienst in Exchange 2007 kann bei einem Verlust einer aktiven Speichergruppe (oder mehrerer aktiver Speichergruppen) die Ausfallzeit auf wenige Minuten begrenzt werden.

SCR-Quellen und -Ziele

Genau wie LCR und CCR arbeitet auch SCR nach dem Konzept aktiver und passiver Kopien einer Speichergruppe, die im Kontext von SCR aber als SCR-Quellen bzw. SCR-Ziele bezeichnet werden. Trotzdem sind SCR-Quellen und SCR-Ziele nichts anderes als Speichergruppenkopien. (Speichergruppen für die Wiederherstellung können bei SCR nicht aktiviert werden.)

SCR verwendet als Ausgangspunkt (SCR-Quelle) eine beliebige Speichergruppe auf einem eigenständigen Postfachserver oder Postfachclusterserver in einer Einzelkopieclusterumgebung (CCR-Umgebung). Dabei ist Folgendes zu beachten: Die SCR-Quelle kann zwar ein Postfachclusterserver sein, aber SCR selbst ist keine Clusterlösung und benötigt nicht den Windows-Clusterdienst. Der Endpunkt für SCR (SCR-Ziel) kann entweder ein eigenständiger Postfachserver oder ein Knoten in einem Failovercluster sein, auf dem die Funktion „Mailbox“ installiert, aber kein Postfachclusterserver im Cluster konfiguriert wurde.

Beziehungen zwischen Quelle und Ziel

Jede SCR-Quellspeichergruppe kann eine unbegrenzte Anzahl von SCR-Zielen besitzen. Beispielsweise könnte eine Quelle ein Ziel im gleichen Datencenter und ein zweites Ziel in einem separaten Datencenter besitzen. Von Microsoft wird jedoch empfohlen, nie mehr als vier Ziele pro Quelle zu verwenden. Falls Sie beschließen, mehr als vier Ziele zu verwenden, müssen Sie abschätzen, welche Auswirkungen dies möglicherweise im Hinblick auf Speicherbedarf, CPU-Auslastung und Datenträgerressourcen des SCR-Quellservers hat, und dies bei der Planung entsprechend berücksichtigen. Jeder SCR-Zielcomputer kann mehrere Quellserver besitzen. Sowohl auf dem Quellcomputer als auch auf dem Zielcomputer muss Service Pack 1 für Exchange 2007 ausgeführt werden. Es muss ein Betriebssystem verwendet werden, das von Service Pack 1 für Exchange 2007 unterstützt wird (z. B. Windows Server® 2008 oder Windows Server 2003 SP2). SCR kann jedoch unabhängig vom verwendeten Betriebssystem nicht betriebssystemübergreifend arbeiten, sondern erfordert, dass auf der SCR-Quelle das gleiche Betriebssystem wie auf allen SCR-Zielen für diese Quelle verwendet wird. Wenn auf der SCR-Quelle beispielsweise Windows Server 2003 ausgeführt wird, muss daher auf allen SCR-Zielen für diese Quelle ebenfalls Windows Server 2003 ausgeführt werden.

SCR ist in der Standard Edition von Exchange 2007 verfügbar. Wenn als SCR-Quelle ein Postfachclusterserver in einer SCC- oder CCR-Umgebung verwendet wird, ist die Enterprise Edition von Exchange 2007 erforderlich. Jedes SCR-Ziel unterstützt bei Verwendung der Enterprise Edition maximal 50 Instanzen (50 replizierte Speichergruppen) und bei Verwendung der Standard Edition maximal 5 Instanzen.

Bei SCR-Zielen sind ebenfalls bestimmte Anforderungen zu erfüllen. Erstens müssen der Quellcomputer und der Zielcomputer in der gleichen Active Directory-Domäne sein, sie dürfen sich aber an unterschiedlichen Active Directory-Standorten befinden. Zweitens müssen die Datenbank- und Protokolldateipfade auf der Quelle und auf allen Zielen dieser Quelle bei jeder Speichergruppe, die mit SCR repliziert wird, identisch sein. Drittens können Sie, wenn ein Knoten oder ein Server als SCR-Ziel konfiguriert wird, für keine Speichergruppe auf dem SCR-Zielcomputer LCR aktivieren und dem Standbyfailovercluster keine Postfachclusterserver hinzufügen.

Vergleich von SCR mit CCR und LCR

Wie in Abbildung 5 zu sehen ist, verwendet SCR das gleiche Protokollversand- und Wiedergabeverfahren wie LCR und CCR, um neue Bereitstellungsoptionen und Konfigurationen bereitzustellen. Genau wie bei LCR und CCR dürfen SCR-fähige Speichergruppen nicht mehr als eine einzige Datenbank enthalten. Darüber hinaus kann SCR nicht für eine Öffentliche Ordner-Datenbank verwendet werden, wenn in der Exchange-Organisation mehr als eine Öffentliche Ordner-Datenbank vorhanden ist.

Abbildung 5** SCR führt einen Protokollversand zu einem anderen Server oder einem passiven Knoten in einem Failovercluster durch **

Ein wichtiger Unterschied bei SCR besteht darin, dass SCR mehrere Ziele pro Speichergruppe unterstützt, während LCR und CCR nur ein einziges Ziel (die passive Kopie) unterstützen. Ein weiterer wichtiger Unterschied liegt darin, dass es im Gegensatz zu CCR und LCR nicht möglich ist, eine Sicherungskopie einer SCR-Kopie zu erstellen. Bei der Verwendung von SCR werden die Datenbankheader für SCR-Ziele aktualisiert und die Protokolldateien abgeschnitten, wenn unterstützte Sicherungen anhand der SCR-Quellspeichergruppe durchgeführt werden (oder wenn im Fall von CCR und LCR Sicherungen anhand der aktiven oder passiven Kopie der SCR-Quellspeichergruppe durchgeführt werden).

Genau wie bei LCR und CCR erfolgt der Protokollversand bei SCR fortlaufend und nach einem Pullmodell. Sobald eine neue Protokolldatei geschlossen und ihr unter Verwendung der nächsten sequenziellen Protokolldateizahl ein Name zugewiesen wurde, überträgt der auf dem SCR-Zielcomputer ausgeführte Microsoft Exchange-Replikationsdienst die geschlossenen Transaktionsprotokolldateien mittels Pull vom SCR-Quellcomputer, überprüft sie, wertet sie aus und verschiebt sie dann in den entsprechenden Ordner für Speichergruppenprotokolldateien auf dem SCR-Zielcomputer.

Wiedergabeverzögerungszeit

Nach dem Kopieren der Protokolldateien auf den SCR-Zielcomputer erfolgt bei SCR etwas, das bei LCR und CCR nicht passiert. Statt sofort die Protokolldateien in der Kopie der Datenbank wiederzugeben, setzt SCR eine integrierte Wiedergabeverzögerung von 50 Protokolldateien und 24 Stunden durch. SCR erlaubt Ihnen dazu, außer der integrierten Verzögerung eine zusätzliche zeitliche Verzögerung festzulegen. Es kann in verschiedenen Szenarios nützlich sein, die Wiedergabeaktivität zu verzögern. Beispielsweise könnte eine Verzögerung im Fall einer logischen Beschädigung einer aktiven Datenbank die logische Beschädigung der SCR-Zieldatenbank verhindern.

Die vom Administrator gesteuerte Wiedergabeverzögerung wird mithilfe eines Parameters namens „ReplayLagTime“ eingestellt, mit dem festgelegt wird, wie lange der Exchange-Replikationsdienst warten soll, bevor Protokolldateien wiedergegeben werden, die auf den SCR-Zielcomputer kopiert wurden. Die Verzögerungszeit wird im Format Tage.Stunden:Minuten:Sekunden festgelegt, und die Standardeinstellung beträgt 24 Stunden. Die maximal zulässige Einstellung für diesen Wert beträgt sieben Tage. Die zulässige Minimaleinstellung liegt bei Null Sekunden. Die Einstellung dieses Minimalwerts hat zur Folge, dass jegliche Verzögerung der Protokollwiedergabeaktivität, die auf die Standardverzögerung von 50 Protokolldateien folgt, deaktiviert wird.

Zusätzlich zu „ReplayLagTime“ besitzt Exchange unabhängig von dem für „ReplayLagTime“ eingestellten Wert eine integrierte, hartcodierte Verzögerung von 50 Protokolldateien. Um festzulegen, wann eine Protokolldatei wiedergegeben werden soll, verwendet Exchange die jeweils größere Verzögerungszeit, die durch „ReplayLagTime“ oder die Standardeinstellung von x Protokolldateien (x=50) festgelegt wird. Dies ist eine zusätzliche Sicherheitsvorkehrung gegen die Notwendigkeit, eine Speichergruppe durch Seeding erneut einrichten zu müssen, falls bei einer SCR-Quelle, die eine fortlaufende Replikation verwendet (z. B. ein Postfachclusterserver in einer CCR-Umgebung), ein Failover eintritt und eine oder mehrere Speichergruppen mithilfe des Cmdlets „Reset-StorageGroupCopy“ online geschaltet werden müssen. (Seeding bezeichnet den Prozess, die ESE (Extensible Storage Engine)-Streaming-Backup-APIs zu verwenden, um eine Onlinekopie der SCR-Quelldatenbank auf dem SCR-Zielcomputer anzufertigen.) Durch das Verzögern der Wiedergabeaktivität auf den SCR-Zielen beim Eintreten eines verlustbehafteten Failovers einer SCR-Quelle wird die Wahrscheinlichkeit gesenkt, dass die SCR-Kopien durch Seeding neu eingerichtet werden müssen, weil die Art des Datenverlusts auf der SCR-Quelle die beiden Kopien zeitlich näher zusammenrückt.

Abschneideverzögerungszeit

In der RTM-Version von Exchange 2007 werden in einer Umgebung mit fortlaufender Replikation Regeln durchgesetzt, damit eine Protokolldatei nur dann gelöscht wird, wenn sie gesichert und in der Kopie der Datenbank wiedergegeben wurde. Bei der Verwendung von SCR wird diese Regel geändert. Die SCR, die das Konzept mehrerer Datenbankkopien einführt, erlaubt es, dass Protokolldateien auf dem SCR-Quellcomputer abgeschnitten werden, sobald sie von allen SCR-Zielcomputern geprüft wurden. Mit dem Abschneiden der Protokolldateien auf dem SCR-Quellserver wird nicht gewartet, bis alle Protokolle in allen SCR-Zielen wiedergegeben wurden, weil SCR-Zielkopien mit langen Protokollwiedergabeverzögerungszeiten konfiguriert werden können.

Sie können für das Abschneiden der Protokolldateien auch eine zusätzliche Verzögerung hinzufügen, indem Sie einen neuen Parameter namens „TruncationLagTime“ verwenden, mit dem im Format „Tage.Stunden:Minuten:Sekunden“ festgelegt wird, wie lange der Exchange-Replikationsdienst warten soll, bevor Protokolldateien, die auf den SCR-Zielcomputer kopiert und in der Kopie der Datenbank wiedergegeben wurden, abgeschnitten werden. Die Zeitspanne beginnt, sobald die Protokolldateien erfolgreich in der Kopie der Datenbank wiedergegeben wurden. Die maximal zulässige Einstellung für diesen Wert beträgt sieben Tage, und die zulässige Minimaleinstellung liegt bei Null Sekunden. Allerdings bewirkt die Einstellung von Null Sekunden, dass jegliche Verzögerung des Abschneidens der Protokolldateien deaktiviert wird.

In einer SCR-Umgebung wird alle drei Minuten ein Hintergrundthread ausgeführt, um zu ermitteln, ob Protokolldateien abgeschnitten werden müssen. Wenn die Sequenz der Protokolldateigenerierung unter dem Protokolldateikontrollpunkt für die Speichergruppe liegt und die Protokolldatei älter als die Summe der Werte von „ReplayLagTime“ und „TruncationLagTime“ ist, wird eine Protokolldatei auf dem SCR-Ziel abgeschnitten.

In einer mit SCR erweiterten LCR- oder CCR-Umgebung wird eine Protokolldatei auf dem SCR-Ziel abgeschnitten, wenn die folgenden vier Kriterien erfüllt sind: Die Protokolldatei wurde gesichert, die Sequenz der Protokolldateigenerierung liegt unter dem Protokolldateikontrollpunkt für die Speichergruppe, die passive Kopie der Speichergruppe ist in einem Zustand, der es erlaubt, die Protokolldatei abzuschneiden, und alle SCR-Ziele haben die Protokolldatei geprüft.

Aktivieren und Verwalten von SCR

SCR wird mithilfe des Cmdlets „Enable-StorageGroupCopy“ in der Exchange-Verwaltungsshell aktiviert, das in SP1 mit einigen neuen Parametern aktualisiert wurde. Wie oben beschrieben können Sie mithilfe von „ReplayLagTime“ und „TruncationLagTime“ das Verhalten von SCR-Zielen teilweise steuern. Mit einem weiteren Parameter namens „SeedingPostponed“ kann das anfängliche Seeding des SCR-Ziels übersprungen werden. Das Seeding zu verschieben, kann in verschiedenen Situationen nützlich sein. Nehmen Sie beispielsweise einmal an, die Datenbank in der Speichergruppe, die für SCR aktiviert wird, hat eine Größe von 100 GB. Sie wollen vermeiden, dass in Zeiten maximaler Produktion 100 GB an Daten im Netzwerk übertragen werden. Mithilfe des Parameters „SeedingPostponed“ können Sie SCR sofort aktivieren und zu einem späteren Zeitpunkt einen Seeding-Task ausführen. Auf Wunsch können Sie mithilfe des Cmdlets „Update-StorageGroupCopy“ ein manuelles Seeding des SCR-Ziels durchführen.

Während die oben genannten Parameter optional sind, gibt es einen Parameter von „Enable-StorageGroupCopy“, der für SCR obligatorisch ist: „StandbyMachine“. Mit diesem Parameter wird der Name des Computers angegeben, der das SCR-Ziel enthält. Der Wert dieses Parameters wird als Bestandteil des Werts für das Attribut „msExchStandbyCopyMachines“ der Speichergruppe festgelegt, die für SCR aktiviert wird. Das Attribut „msExchStandbyCopyMachines“ ist eine Unicode-Zeichenfolge mit mehreren Werten, die dem Active Directory-Schema hinzugefügt wird, wenn Exchange 2007 SP1 in die Exchange-Organisation eingeführt wird. Dies ist einer der Gründe, warum SP1 eine Schemaaktualisierung für Active Directory erforderlich macht.

Der Parameter „StandbyMachine“ ist für SCR von zentraler Bedeutung, und in SP1 wurden mehrere Cmdlets aktualisiert, damit dieser Parameter für das Aktivieren und Verwalten von SCR-Zielen verwendet wird. Die aktualisierten Cmdlets werden in Abbildung 6 beschrieben.

Figure 6 Cmdlets, die den Parameter „Stand­by­Machine“ verwenden

Aktivieren von SCR-Zielen

SCR stellt eine oder mehrere aktuelle Kopien der Daten bereit, die verwendet werden können, falls die Originaldaten verloren gehen oder unbrauchbar werden sollten. Der Prozess, eine SCR-Zielkopie als neue Produktionsdatenbank bereitzustellen, wird als „Aktivierung“ bezeichnet. Die Aktivierung findet als Teil des Wiederherstellungsprozesses statt, der die Form einer Datenbankportabilität oder einer der zwei Wiederherstellungsoptionen („/m:RecoverServer“ zur Wiederherstellung eines eigenständigen Servers oder „/RecoverCMS“ zur Wiederherstellung eines Postfachclusterservers) annehmen kann.

Wie SCR verwendet werden kann

Im Folgenden wird aufgezeigt, wie ein fiktives Unternehmen SCR und Datenbankportabilität zur Wiederherstellung nach einem Ausfall einer Postfachdatenbank verwenden könnte. Sobald erkannt wird, dass die Produktionsdatenbank beschädigt ist, aktiviert der Administrator mithilfe von Datenbankportabilität die SCR-Zieldatenbank.

Die Organisation hat Exchange 2007 mit SP1 installiert und beschlossen, SCR zu nutzen, um auf einem entfernten Postfachserver eine Kopie einer Speichergruppe bereitzustellen. Sowohl der Quellpostfachserver als auch der Zielpostfachserver befinden sich am selben Active Directory-Standort und wurden dafür konfiguriert, mit Active Directory integrierte DNS-Server zu verwenden. Das Active Directory-Replikationsintervall wurde auf 15 Minuten gesetzt.

Aktivieren von SCR und Bereitstellen der Wiederherstellung

SCR wird so konfiguriert, dass Transaktionsprotokolldateien für eine einzige Speichergruppe (SG1) repliziert werden, in der eine einzige Datenbank (MBX1) enthalten ist. Die Pfade für die Speichergruppendateien und die Datenbankdatei lauten „C:\SG1“ und „C:\SG1\MBX1.EDB“. In diesem Fall ist „EXMBX1“ die SCR-Quelle und „EXMBX2“ das SCR-Ziel. Dies wurde folgendermaßen konfiguriert:

Enable-StorageGroupCopy EXMBX1\SG1 
-StandbyMachine EXMBX2

Nach Aktivieren von SCR wurden die Integrität und der Status von SCR für „SG1“ mit dem Cmdlet „Get-StorageGroupCopyStatus“ überprüft:

Get-StorageGroupCopyStatus EXMBX1\SG1 
-StandbyMachine EXMBX2

Um beim Prozess der Aktivierung des SCR-Ziels Zeit zu sparen, wird „EXMBX2“ mit einer Speichergruppe namens „SG1PORT“ und einer Datenbank namens „MBX1PORT“ vorkonfiguriert, die bei den Datenbankportabilitätsvorgängen verwendet werden. „SG1PORT“ und „MBX1PORT“ sind von der Speichergruppe und den Datenbankdateien des SCR-Ziels getrennt. Daher werden die Pfade für „SG1PORT“ und „MBX1PORT“ mit einem temporären Pfad konfiguriert, der keinen Konflikt mit den SCR-Zielpfaden hervorruft. „SG1PORT“ und „MBX1PORT“ werden nur als Datenbankportabilitätsobjekte verwendet. Die eigentliche Speichergruppe und die Datenbankdateien für „SG1PORT“ werden nicht benötigt. Darum hebt der Administrator die Bereitstellung von „MBX1PORT“ auf und löscht alle in der Speichergruppe enthaltenen Dateien. Die Speichergruppe und die Datenbankobjekte bleiben in Active Directory, weil sie später während des Wiederherstellungsprozesses zur Datenbankportabilität verwendet werden.

Aktivierung und Wiederherstellung

Ein Anwendungsereignisprotokolleintrag zeigt an, dass die SCR-Quelldatenbank physisch beschädigt ist. Da SCR für „SG1“ aktiviert wurde, wird entschieden, für „SG1“ eine manuelle Aktivierung der SCR-Zieldatenbank durchzuführen und Datenbankportabilität zu verwenden, um Datenverfügbarkeit wiederherzustellen. Die Aktivierung der SCR-Zielkopie beginnt damit, dass mit dem folgenden Cmdlet die Bereitstellung von „MBX1“ in „SG1“ aufgehoben wird:

Dismount-Database EXMBX1\SG1\MBX1

Danach wird die SCR-Zieldatenbank auf die Bereitstellung vorbereitet, und die Postfächer, die sich ursprünglich auf „MBX1“ befanden, werden auf „MBX1PORT“ verlagert.

Der Prozess zum Deaktivieren von SCR und zum Vorbereiten der SCR-Zieldatenbank auf die Bereitstellung umfasst das Ausführen des Cmdlets „Restore-StorageGroupCopy“. Dieser Task kennzeichnet die Datenbank der Speichergruppe als bereitstellbar und erstellt einen Bericht zum Datenverlust, der durch die Bereitstellung der Datenbank an die Speichergruppe entstehen könnte. Darüber hinaus überprüft der Task, ob am Dateispeicherort der Speichergruppe der passiven Kopie alle Protokolldateien vorhanden sind, die von der aktiven Kopie der Speichergruppe generiert werden. Falls Protokolldateien fehlen, versucht der Prozess, auch diese Dateien zu kopieren. Mit dem folgenden Cmdlet wird die SCR-Zieldatenbank auf die Bereitstellung vorbereitet:

Restore-StorageGroupCopy EXMBX1\SG1 
-StandbyMachine EXMBX2

In diesem Beispiel stehen die Protokolldateien aus der SCR-Quellspeichergruppe zum Kopieren zur Verfügung. Wenn diese Dateien nicht verfügbar sind (z. B. weil der SCR-Quellcomputer ausgeschaltet ist), muss der Parameter „Force“ dem Task „Restore-StorageGroupCopy“ hinzugefügt werden. Wenn dies nicht erfolgt, versucht „Restore-StorageGroupCopy“ in jedem Fall eine Verbindung zur SCR-Quelle herzustellen, um fehlende Protokolldateien zu kopieren, und wenn die SCR-Quelle nicht verfügbar ist, schlägt der Task „Restore-StorageGroupCopy“ fehl, und die Datenbank wird nicht auf die Bereitstellung vorbereitet. Durch Hinzufügen des Parameters „Force“ wird dem Task „Restore-StorageGroupCopy“ mitgeteilt, dass die Quelldateien nicht verfügbar sind. In diesem Fall wird der Verbindungsversuch unterlassen und damit fortgefahren, die SCR-Zieldatenbank auf die Bereitstellung vorzubereiten.

Sobald der Befehl „Restore-StorageGroupCopy“ abgeschlossen ist, muss der Administrator überprüfen, ob sich die Datenbank in einem fehlerfreien Shutdown-Status befindet. Wenn sich die Datenbank in einem fehlerhaften Shutdown-Status befindet (siehe technet.microsoft.com/aa996757.aspx), muss sie in einen fehlerfreien Shutdown-Status versetzt werden. Wenn das Protokolldateipräfix für die Speichergruppe (z. B. „E00“ oder „E01“) bei der SCR-Quelle (EXMBX1\SG1) und der Speichergruppe auf dem SCR-Ziel (SG1PORT), das für die Datenbankportabilität verwendet wird (EXMBX2\SG1PORT), identisch ist, ist es nicht erforderlich, „Eseutil“ im Wiederherstellungsmodus auszuführen. In diesem Fall wird die Datenbank durch den abschließenden Datenbankbereitstellungsvorgang in einen fehlerfreien Shutdown-Status versetzt, nachdem alle replizierten Protokolldateien wiedergegeben wurden. Wenn sich die Datenbank nicht in einem fehlerfreien Shutdown-Status befindet, müssen an der Datenbank Exchange Server-Datenbankdienstprogramme (Eseutil) im Wiederherstellungsmodus (Eseutil /r) ausgeführt werden.

Sobald sich die Datenbank in einem fehlerfreien Shutdown-Status befindet, können Sie zwei Befehle ausführen, die Active Directory mit neuen Speicherorten für die Speichergruppendateien und die Datenbankdatei aktualisieren. Diese Befehle ändern die Pfade für „SG1PORT“ und „MBX1“ von ihren ursprünglichen Pfaden in die Pfade für die bereitgestellte Speichergruppe und die Datenbank („SG1PORT“ und „MBX1PORT“):

Move-StorageGroupPath EXMBX2\SG1PORT 
-SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT 
-EdbFilePath C:\SG1\MBX1PORT.EDB 
–ConfigurationOnly

Bei den oben genannten Befehlen muss der Parameter „–ConfigurationOnly“ verwendet werden, damit in Active Directory nur die Konfigurationseinstellungen für diese Objekte aktualisiert werden. Es werden keine Daten oder Dateien verschoben. Dies ist auch nicht erforderlich, denn SCR hat die Daten bereits in „C:\SG1“ auf „EXMBX2“ repliziert.

Im nächsten Schritt wird die Datenbank (MBX1PORT) dafür konfiguriert, während eines Wiederherstellungsvorgangs ihre eigene Überschreibung zuzulassen. Dies erfolgt durch Auswahl des Kontrollkästchens für die Einstellung „Diese Datenbank kann bei einer Wiederherstellung überschrieben werden“ in der Exchange-Verwaltungskonsole in den Datenbankobjekteigenschaften oder durch Verwendung des folgenden Befehls in der Exchange-Verwaltungsshell:

Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT 
-AllowFileRestore:$true

Wenn die Datenbank dafür konfiguriert wurde, ihre eigene Überschreibung zuzulassen, muss die Datenbank als Nächstes mit dem folgenden Befehl bereitgestellt werden:

Mount-Database EXMBX2\SG1PORT\MBX1PORT

Sobald die Datenbank bereitgestellt wurde, müssen die Postfächer, die sich in der SCR-Quelldatenbank (SG1\MBX1) befanden, verlagert werden, damit sie auf „MBX1PORT“ auf „EXMBX2“ verweisen. Führen Sie einfach das Cmdlet „Get-Mailbox“ aus, und leiten Sie die Ausgabe zum Cmdlet „Move-Mailbox“. Während dieses Vorgangs ist es wichtig, dass die Exchange-Systemaufsicht und die Exchange-Systempostfächer nicht in der Ausgabe des Cmdlets „Get-Mailbox“ enthalten sind, die zum Cmdlet „Move-Mailbox“ geleitet wird. Diese Postfachobjekte müssen und sollen nicht verlagert werden. Es wird der folgende Befehl ausgeführt, um alle Benutzerpostfächer zu verlagern und Systempostfächer auszuschließen:

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

Jetzt ist Clientzugriff auf „MBX1PORT“ möglich. Ob Benutzer tatsächlich auf ihre Postfächer zugreifen können, nachdem sie von „EXMBX1\SG1\MBX1“ auf „EXMBX2\SG1PORT\MBX1PORT“ verschoben wurden, hängt jedoch von der Active Directory-Replikationswartezeit ab. Das heißt, abhängig von der Anzahl der Verzeichnisserver kann es einige Zeit dauern, bis sich die Aktualisierung in der Umgebung verbreitet hat. Darüber hinaus spielen auch die Clientzugriffsmethoden eine Rolle. Wenn die Verzeichnisserver, die vom Clientzugriffsserver des Benutzers verwendet werden, mit den neuen Pfaden aktualisiert wurden, haben sowohl Messaging-Clients, auf denen Outlook 2007 ausgeführt wird, als auch Clients, auf denen Outlook nicht ausgeführt wird, Zugriff auf das Postfach des Benutzers. Bei Messaging-Clients, auf denen Outlook 2003 und ältere Versionen ausgeführt werden, muss das Desktopmessagingprofil des Benutzers mit dem neuen Servernamen aktualisiert werden.

Abschließende Schritte

Sobald Clients Zugriff auf ihre Postfächer und ihre Postfachdaten haben, muss zum Schluss durch Aktivieren von SCR Redundanz eingerichtet werden. Dies wird erreicht, indem alle übrigen Speichergruppen- und Datenbankdateien aus „EXMBX1“ entfernt werden. Nach Entfernen der Dateien können die Pfade für „EXMBX1\SG1\MBX1“ in einen temporären Speicherort verschoben, und es kann „EXMBX1“ als SCR-Ziel von „EXMBX2“ verwendet werden.

Scott Schnoll ist Technischer Chefredakteur im Exchange Server-Team von Microsoft und schreibt Inhalte für Exchange Server 2007. Vor der Aufnahme seiner Tätigkeit bei Microsoft verfasste er das Buch „Exchange Server 2003 Distilled“ (Addison-Wesley Professional, 2004) und trug als Hauptautor zu „Exchange 2000 Server: The Complete Reference“ (McGraw-Hill/OsborneMedia, 2001) bei.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.