Aktivieren von SCR-Zielen

 

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1

Letztes Änderungsdatum des Themas: 2008-06-19

Mit der fortlaufenden Standbyreplikation (Standby Continuous Replication, SCR), einem neuen Feature in Microsoft Exchange Server 2007 Service Pack 1 (SP1), können Sie fortlaufende Replikation verwenden, um Postfachserverdaten von einem eigenständigen Postfachserver, von einem Postfachclusterserver in einem Einzelkopiecluster oder in einer Umgebung mit fortlaufender Clusterreplikation (Cluster Continuous Replication, CCR) zu replizieren.

Wie der Name schon nahelegt, ist die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR) für die Verwendung in Standbywiederherstellungsszenarien ausgelegt. Der Prozess zur Aktivierung von Kopien der Postfachserverdaten, die von SCR erstellt und verwaltet werden, erfolgt manuell und sollte nur ausgeführt werden, wenn ein gravierender Fehler auftritt. SCR ist nicht für einfache Serverausfälle bestimmt, die sich durch einen Neustart oder ähnliche einfache Maßnahmen beheben lassen. Sie können ein SCR-Ziel unter Verwendung von Datenbankportabilität, mithilfe der Serverwiederherstellungsoption (Setup /m:RecoverServer) oder, wenn es sich um einen Postfachclusterserver handelt, mit der Postfachclusterserver-Wiederherstellungsoption (Setup /RecoverCMS) aktivieren. Die von Ihnen zu wählende Option hängt von Ihrer Konfiguration und dem Typ des aufgetretenen Fehlers ab. Wenn die SCR-Quelle ein Postfachclusterserver ist, ist die optimale Zielkonfiguration ein Standbycluster. Ist die SCR-Quelle ein eigenständiger Postfachserver, ist die optimale Zielkonfiguration ein eigenständiger Postfachserver. Zwar ist es nicht erforderlich, die Zielkonfiguration analog zur Quellkonfiguration zu gestalten, doch kann die Verwendung identischer Konfigurationen die Wiederherstellungszeiten verkürzen. Wenn die SCR-Quelle beispielsweise ein Postfachclusterserver und das SCR-Ziel ein eigenständiger Postfachserver statt eines Standbyclusters ist, dauert der vollständige Serverwiederherstellungsprozess länger. Die Ursache hierfür ist, dass ein eigenständiger Postfachserver eine eigene Postfachserveridentität hat, die zuerst entfernt werden muss (durch Deinstallation von Exchange), damit "Setup /RecoverCMS" ausgeführt werden kann.

SCR-Aktivierungs- und Wiederherstellungsszenarien

SCR wurde entwickelt, um Wiederherstellungsoptionen auf Datacenterebene zu ermöglichen und ergänzt die durch LCR, CCR und SCC bereitgestellte datacenterinterne Ausfallsicherung. SCR ermöglicht eine Trennung von hoher Verfügbarkeit (sowohl Dienst- als auch Datenverfügbarkeit) und Standortausfallsicherung. SCR kann beispielsweise mit CCR kombiniert werden, um Speichergruppen lokal in einem primären Datacenter (mithilfe von CCR für hohe Verfügbarkeit) und remote in einem sekundären oder Sicherungsdatacenter (mithilfe von SCR für Standortausfallsicherung) zu replizieren.

Weitere Informationen zur Verwendung von SCR mit einem Standbyfailovercluster in einem Szenario zur Standortausfallsicherung finden Sie unter Fortlaufende Standbyreplikation: Standortflexibilität durch Ersatzcluster. Das Beispiel in diesem Thema beschreibt, wie eine Organisation (Contoso, Ltd.) SCR in einem Szenario zur Standortausfallsicherung einsetzt. In diesem Szenario fällt das primäre Datacenter aus und Contoso, Ltd. trifft die Entscheidung, das sekundäre Datacenter zu aktivieren. Nach der Aktivierung des sekundären Datacenters wird das primäre Datacenter neu konfiguriert und zu gegebener Zeit im Rahmen eines kontrollierten Switchovers wieder zum primären Datacenter gemacht.

Weitere Informationen zur Verwendung von SCR mit Datenbankportabilität finden Sie unter Fortlaufende Standbyreplikation: Datenbankportabilität. Das Beispiel in diesem Thema beschreibt, wie eine Organisation (Woodgrove Bank) SCR und Datenbankportabilität für die Wiederherstellung nach dem Ausfall einer einzelnen Datenbank verwendet. In diesem Szenario wird festgestellt, dass eine SCR-Quelldatenbank physikalisch beschädigt ist, und der Administrator trifft die Entscheidung, die SCR-Zieldatenbank zu aktivieren. Während der Aktivierung ist SCR deaktiviert, die SCR-Zieldatenbank wird als Produktionsdatenbank bereitgestellt, und die Benutzerpostfächer werden verlagert. Nachdem der Datenzugriff für die Clients wiederhergestellt wurde, wird SCR wieder aktiviert, damit die Speichergruppe Redundanz und Schutz für das SCR-Ziel wiederherstellen kann.