Fortlaufende Standbyreplikation

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

Letztes Änderungsdatum des Themas: 2008-10-21

Die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR) ist ein in Microsoft Exchange Server 2007 Service Pack 1 (SP1) eingeführtes neues Feature. Wie der Name schon besagt, ist die SCR auf Fälle ausgelegt, in denen Standbywiederherstellungsserver verwendet werden bzw. deren Verwendung aktiviert wird. SCR erweitert die vorhanden Features zur fortlaufenden Replikation, die sich in der RTM-Version von Exchange Server 2007 befinden und ermöglicht neue Datenverfügbarkeitsszenarien für Postfachserver, die SP1 ausführen. SCR verwendet dieselbe Protokollversand- und -wiedergabetechnologie, die auch von der LCR (Local Continuous Replication) und CCR (Cluster Continuous Replication) verwendet wird, um zusätzliche Bereitstellungsoptionen und -konfigurationen bereitzustellen.

SCR ermöglicht eine Trennung von hoher Verfügbarkeit (umfasst die Dienst- und Datenverfügbarkeit) und Standortflexibilität. SCR kann beispielsweise mit CCR kombiniert werden, um Speichergruppen lokal in einem Hauptdatacenter (unter Verwendung von CCR für eine hohe Verfügbarkeit) und remote in einem sekundären oder Sicherungsdatacenter (unter Verwendung von SCR für die Standortflexibilität) zu replizieren. Dieses sekundäre Datacenter kann einen passiven Knoten in einem Failovercluster enthalten, der die SCR-Ziele hostet. Diese Art von Cluster wird als Standbycluster bezeichnet, da sie keine Postfachclusterserver enthält, aber schnell durch einen Ersatz-Postfachclusterserver in einem Wiederherstellungsszenario bereitgestellt werden kann. Wenn das Hauptdatacenter ausfällt oder die Verbindung auf andere Weise unterbrochen wird, können die in diesen SCR-Zielen gehosteten Standbycluster schnell auf dem Standbycluster aktiviert werden.

Quellen und Ziele

Wie LCR und CCR verwendet SCR das Konzept aktiver und passiver Kopien von Speichergruppen, verweist auf diese aber als Quellen und Ziele. Ebenso wie CCR erfordert SCR, dass die Datenbank- und Protokolldateipfade für die Quelle und das Ziel gleich sind.

Der Ausgangspunkt für SCR wird als Quelle bezeichnet, wobei es sich um eine beliebige Speichergruppe oder eines der folgenden Objekte handeln kann:

• Eigenständiger Postfachserver

• Postfachclusterserver in einem Einzelkopiecluster (Single Copy Cluster, SCC)

• Postfachclusterserver in einer CCR-Umgebung

  Hinweis

  Wiederherstellungsspeichergruppen können für SCR nicht aktiviert werden.

Wie bei LCR und CCR können SCR-aktivierte Speichergruppen nicht mehr als eine Datenbank enthalten. Sie können SCR nicht für eine Speichergruppe aktivieren, die mehrere Datenbanken enthält. Außerdem können Sie einer SCR-aktivierten Speichergruppe keine zweite oder nachfolgende Datenbanken hinzufügen.

Wenn der SCR-Quellcomputer nicht in einem Cluster ist, kann er auch noch andere Serverfunktionen aufnehmen, wie z. B. die Serverfunktionen Hub-Transport, ClientAccess und UnifiedMessaging.

Der Endpunkt für SCR wird als Ziel bezeichnet und dabei kann es sich um eines der folgenden Objekte handeln:

• Einen eigenständiger Postfachserver, für den LCR für keine Speichergruppe aktiviert ist.

• Einen Ersatzcluster, ein Failovercluster, auf dem die Serverfunktion Passive ClusteredMailbox installiert ist. Im Cluster wurde jedoch kein Postfachclusterserver (z. B. keine Funktion Active ClusteredMailbox) installiert.

Auf einem SCR-Zielcomputer muss die Serverfunktion Mailbox installiert sein, auch wenn er keine Produktionspostfächer hostet. Die Serverfunktion Mailbox ist erforderlich, da sie den Microsoft Exchange-Replikationsdienst und andere für die SCR-Funktionalität erforderliche Komponenten umfasst. Wenn der SCR-Zielcomputer nicht in einem Cluster ist, kann er auch noch andere Serverfunktionen aufnehmen, wie z. B. die Serverfunktionen Hub-Transport, ClientAccess und UnifiedMessaging.

SCR ist in der Standard Edition von Exchange 2007 SP1 verfügbar. Wenn ein Postfachserver in einer SCC- oder CCR-Umgebung als SCR-Quelle verwendet wird, ist die Enterprise Edition von Exchange 2007 SP1 erforderlich, da die Enterprise Edition beim Clustering von Exchange 2007 benötigt wird. Wenn ein Standbycluster als SCR-Ziel verwendet wird, ist ebenfalls die Enterprise Edition von Exchange 2007 SP1 erforderlich.

Vergleichen von SCR mit LCR und CCR

SCR ist ähnlich wie LCR und CCR, weist aber eigene eindeutige Merkmale auf:

• SCR unterstützt mehrere Replikationsziele pro Speichergruppe. LCR und CCR unterstützen nur ein Replikationsziel pro Speichergruppe (die passive Kopie).

• SCR umfasst eine integrierte Verzögerung für die Wiedergabeaktivität und ermöglicht es einem Administrator, eine zusätzliche Verzögerung anzugeben. Dies ist in vielen Szenarien hilfreich. Bei einer logischen Beschädigung einer aktiven Datenbank können beispielsweise die integrierte und die vom Administrator konfigurierte zusätzliche Verzögerung verwendet werden, um die logische Beschädigung einer SCR-Zieldatenbank zu verhindern. LCR und CCR verfügen nicht über derartige Verzögerungen.

• SCR wird vollständig mithilfe der Exchange-Verwaltungsshell verwaltet. Die Exchange-Verwaltungskonsole kann zum Verwalten vieler Aspekte von LCR und CCR verwendet werden, jedoch nicht zum Aktivieren oder Verwalten von SCR-Aspekten.

SCR-Kopieaktivierung

Der Prozess zur Verwendung einer SCR-Zieldatenbank wird als Aktivierung bezeichnet. Die Art, in der die Datenbank aktiviert wird, ist von der Art des Fehlers abhängig. Ist mindestens eine der Datenbanken auf der SCR-Quelle betroffen, können Sie die Datenbankportabilitätsfunktion in Exchange 2007 im Rahmen des Aktivierungsprozesses für die SCR-Zieldatenbanken verwenden. Sind alle Datenbanken auf einem SCR-Quellserver betroffen, oder wenn ein vollständiger Server oder Postfachclusterserver wiederhergestellt wird, können Sie die Serverwiederherstellungsfunktionen von Setup (Setup /m:RecoverServer für einen eigenständigen Server und Setup /RecoverCMS für einen Postfachclusterserver) im Rahmen des Aktivierungsprozesses verwenden.

Weitere Informationen zur Aktivierung und Wiederherstellung in einer SCR-Umgebung finden Sie unter Aktivieren von SCR-Zielen.

SCR-Bereitstellungsszenarien

Mithilfe von SCR können Sie die fortlaufende Replikation dazu verwenden, Postfachserverdaten eines eigenständigen Postfachservers oder eines Postfachclusterservers in einer SCC- oder CCR-Umgebung zu replizieren. Die nachfolgenden Abbildungen veranschaulichen eine Auswahl der möglichen SCR-Konfigurationsoptionen.

Verwenden von SCR zum Replizieren einer Speichergruppe eines eigenständigen Postfachservers auf einen anderen Postfachserver

Die vorangehende Abbildung veranschaulicht die Verwendung von SCR zum Replizieren mehrerer Speichergruppen eines Postfachservers auf einen anderen Postfachserver. In diesem Beispiel sind die Postfachserver keine Postfachclusterserver und beide fungieren als SCR-Quellen und -Ziele. In diesem Beispiel befindet sich jeder Server in einem anderen Datacenter sowie an einem anderen Active Directory-Standort. In Abhängigkeit von der Art des Fehlers kann die Wiederherstellung einer Speichergruppe oder beider Server mithilfe der Datenbankportabilität oder der Installationsoption /RecoverServer durchgeführt werden.

Verwenden von CCR zum lokalen Replizieren von Speichergruppen sowie von SCR zum Replizieren einer Speichergruppe an einem Remotespeicherort

Die vorangehende Abbildung veranschaulicht ein CCR-zu-SCR-Modell (1:1). In diesem Beispiel ist EXCLUS1 ein Postfachclusterserver in einer CCR-Umgebung, der sich am Active Directory-Standort REDMOND befindet. EXCLUS1DR ist ein Standbycluster, der sich am Active Directory-Standort QUINCY befindet. In diesem Fall kann die Wiederherstellung aller Speichergruppen des SCR-Ziels mithilfe des Installationsschalters /RecoverCMS erreicht werden. Wenn nicht alle Speichergruppen wiederhergestellt werden müssen, können eine oder mehrere Speichergruppen mithilfe der Datenbankportabilität wiederhergestellt werden.

Verwenden von CCR zum lokalen Replizieren von Speichergruppen sowie von SCR zum Replizieren von Speichergruppen an mehreren Remotespeicherorten

Die vorangehende Abbildung veranschaulicht ein CCR-zu-SCR-Modell (1:N). Die Computer auf der linken Seite stellen die beiden physischen CCR-Knoten in demselben Datacenter dar. Die Computer auf der rechten Seite stellen zwei SCR-Ziele in einem zweiten Datacenter dar. In diesem Beispiel wird eine einzelne Speichergruppe auf mehrere SCR-Ziele auf zwei verschiedenen Computern repliziert. Die Wiederherstellung der Speichergruppe auf beiden SCR-Zielen kann mithilfe einer der beiden folgenden Methoden erreicht werden:

• /RecoverCMS kann nur zum Wiederherstellen von Speichergruppen aus einer einzelnen CCR-Quelle verwendet werden.

• Die Datenbankportabilität kann zum Wiederherstellen von Speichergruppen aus mehreren CCR-Quellen verwendet werden.

Verwenden mehrerer SCR-Ziele für einen SCC

Die vorangehende Abbildung veranschaulicht ein SCC-zu-SCR-Modell (1:N). Die Computer auf der linken Seite stellen die beiden physischen SCC-Knoten in einem einzelnen Datacenter dar. Die Computer auf der rechten Seite stellt SCR-Ziele in einem separatem Datacenter dar. In diesem Beispiel wird eine einzelne Speichergruppe auf zwei eigenständigen Zielen in einem zweiten Datacenter repliziert. Die Wiederherstellung dieser Speichergruppe des SCR-Ziels kann mithilfe des Installationsschalters /RecoverCMS erreicht werden.

Cmdlet-Aktualisierungen für SCR

SCR wird mithilfe der Exchange-Verwaltungsshell verwaltet. SP1 umfasst einen neuen Parameter mit der Bezeichnung StandbyMachine für mehrere der Cmdlets der Exchange-Verwaltungsshell, die zum Verwalten und Konfigurieren der fortlaufenden Replikation verwendet werden. Insbesondere die folgenden Cmdlets umfassen jetzt die Unterstützung von SCR und den Parameter StandbyMachine:

• Suspend-StorageGroupCopy

• Resume-StorageGroupCopy

• Update-StorageGroupCopy

• Restore-StorageGroupCopy

• Get-StorageGroup

• Get-StorageGroupCopyStatus

Zusätzlich zu den vorherigen Cmdlet-Aktualisierungen wurden die Cmdlets New-StorageGroup und Enable-StorageGroupCopy für die Unterstützung von SCR aktualisiert. In Exchange 2007 SP1 können Sie New-StorageGroup verwenden, um eine für SCR aktivierte Speichergruppe zu erstellen und Enable-StorageGroupCopy verwenden, um SCR für eine vorhandene Speichergruppe zu aktivieren. Diese Cmdlets umfassen die folgenden aktualisierten Parameter:

• -StandbyMachine   Dieser Parameter gibt den Namen des SCR-Zielcomputers an.

• -ReplayLagTime   Mithilfe dieses Parameters wird die Zeit angegeben, die der Microsoft Exchange-Replikationsdienst warten muss, bevor die Protokolldateien wiedergegeben werden, die auf den SCR-Zielcomputer kopiert wurden. Das Format für diesen Parameter ist (Tage.Stunden:Minuten:Sekunden). Die Standardeinstellung für diesen Wert ist 24 Stunden (1.0:0:0). Die maximal zulässige Einstellung für diesen Wert ist 7 Tage. Die niedrigste zulässige Einstellung ist 0 Sekunden, obwohl das Einstellen dieses Werts auf 0 Sekunden sämtliche über der Standardverzögerung von 50 Protokolldateien liegende Verzögerungen bei der Protokollwiedergabe effektiv beseitigt. Nachdem der Wert für diesen Parameter eingestellt wurde, kann er nicht geändert werden, ohne SCR zu deaktivieren und anschließend erneut zu aktivieren.

• -TruncationLagTime   Mithilfe dieses Parameters wird die Zeit angegeben, die der Microsoft Exchange-Replikationsdienst warten muss, bevor die Protokolldateien abgeschnitten werden, die auf den SCR-Zielcomputer kopiert und in die Kopie der Datenbank wiedergegeben wurden. Der Zeitraum beginnt nach der erfolgreichen Wiedergabe des Protokolls in die Kopie der Datenbank. Das Format für diesen Parameter ist (Tage.Stunden:Minuten:Sekunden). Die maximal zulässige Einstellung für diesen Wert ist 7 Tage. Die niedrigste zulässige Einstellung ist 0 Sekunden, obwohl das Einstellen dieses Werts auf 0 Sekunden jegliche Verzögerung bei Protokollabschneideaktivitäten de facto beseitigt. Nachdem der Wert für diesen Parameter eingestellt wurde, kann er nicht geändert werden, ohne SCR zu deaktivieren und anschließend erneut zu aktivieren.

Zusätzlich zu der vom Administrator konfigurierten Wiedergabeverzögerung, die mithilfe des Parameters ReplayLagTime angegeben wird, verhindert Exchange auch die Wiederhabe einer festen Anzahl von Protokolldateien auf einem SCR-Ziel, unabhängig vom Wert für ReplayLagTime, wobei die Formel Maximum von ("Wert von ReplayLagTime" oder "X Protokolldateien") verwendet wird. Dabei ist X=50. Dies ist ein zusätzlicher Schutz vor dem erneuten Seeding für eine Speichergruppe in Situationen, in denen eine SCR-Quelle, bei der es sich um eine fortlaufende Replikationsumgebung wie beispielsweise LCR (Local Continuous Replication) oder CCR (Cluster Continuous Replication) handelt, einen verlustreichen Failover erfährt und mithilfe des Cmdlets Restore-StorageGroupCopy online gestellt wird. Durch das Verzögern der Wiedergabeaktivität auf den SCR-Zielen wird die Wahrscheinlichkeit eines erneuten Seedings für die SCR-Kopien bei einem verlustreichen Failover minimiert, da die Art des Datenverlustes bei den SCR-Quellen die beiden Kopien zeitlich näher bringt.

Einrichten von Aktualisierungen für SCR

SCR wurde hauptsächlich für schwerwiegende Fehler entworfen, z. B. für vollständige Standortausfälle. Diese Arten von Fehlerszenarien beziehen manuelle Aktivitäten ein, z. B. die Aktivierung eines Sicherungsdatacenters sowie ein Wechsel zurück zu einem Hauptdatacenter.

Bedenken Sie unter Verwendung der zuvor in diesem Thema als Beispiel aufgeführten Abbildung Verwenden mehrerer SCR-Remoteziele für einen SCC was geschieht, wenn das Hauptdatacenter (der Standort mit der SCC) ausfällt und die Entscheidung getroffen wird, das zweite Datacenter als primären Ersatzstandort zu aktivieren. Wenn das zweite Datacenter aktiviert ist, verbleibt die ursprüngliche Datacenterkonfiguration in Active Directory, und diese Konfiguration wird vom zweiten Datacenter nach der Aktivierung verwendet. Die Konfiguration des Postfachclusterservers für die SCC verbleibt ebenfalls auf dem ursprünglichen Cluster. Damit der ursprüngliche Cluster wieder online gestellt werden kann, muss die Konfiguration des Postfachclusterservers von den Clusterknoten entfernt werden, ohne die Konfiguration des Postfachclusterservers in Active Directory zu beeinflussen (die vom zweiten Datacenter verwendet wird).

Um diese und andere Standortflexibilitätsszenarien ermöglichen zu können, wurde das Setup in Exchange 2007 SP1 modifiziert. Das Setup umfasst insbesondere eine neue Befehlszeilenoption mit der Bezeichnung /ClearLocalCMS, die zum Löschen der Konfigurationsinformationen des Postfachclusterservers von den ursprünglichen Clusterknoten verwendet wird, ohne sich auf die Konfigurationsinformationen auszuwirken, die in Active Directory gespeichert werden. Sie würden beispielsweise den folgenden Befehl lokal auf jedem Knoten im ursprünglichen Cluster, von dem ein Postfachclusterserver entfernt werden soll, ausführen, um die lokalen Konfigurationsdaten für einen Postfachclusterserver namens EXCLUS1 zu löschen:

Setup /ClearLocalCMS

Beachten Sie die folgenden Anforderungen und Einschränkungen, wenn Sie die Option /ClearLocalCMS verwenden:

• Diese Option kann nur lokal verwendet werden; sie kann nicht remote verwendet werden.

• Diese Option kann nur auf Knoten verwendet werden, auf denen sich ein Postfachclusterserver befindet (z. B. aktive Knoten), nicht auf passiven Knoten.

• Diese Option entfernt nicht die Microsoft Exchange-Programmdateien und aktualisiert keine Konfigurationsinformationen in Active Directory.

• Diese Option kann nur verwendet werden, wenn der lokale Postfachclusterserver offline ist und der lokale Knoten nicht auf der Liste RedundantMachines für den lokalen Postfachclusterserver steht.

• Dem zum Löschen der lokalen Konfiguration des Postfachclusterservers verwendeten Konto müssen Exchange-Serveradministratorberechtigungen für den Postfachclusterserver erteilt werden.

• Wenn die Clusterknoten unter Windows Server 2008 ausgeführt werden, wird das virtuelle Computerobjekt (VCO) im Anschluss an die Ausführung von Setup /ClearLocalCMS deaktiviert. Sie müssen das VCO dann neu aktivieren.

Weitere Informationen

Weitere Informationen zum Planen der SCR finden Sie unter Planen der fortlaufenden Standbyreplikation. Weitere Informationen zum Verwalten von SCR, einschließlich ausführlicher Anleitungen zum Aktivieren oder Deaktivieren von SCR für eine Speichergruppe, finden Sie unter Verwalten der fortlaufenden Standbyreplikation.