Fortlaufende lokale Replikation

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

Letztes Änderungsdatum des Themas: 2008-01-17

Die fortlaufende lokale Replikation (Local Continuous Replication, LCR) ist eine Lösung mit einem Server, bei der mit integrierter asynchroner Protokollversand- und wiedergabetechnologie eine Speichergruppenkopie auf einem zweiten Datenträgersatz, der mit demselben Server wie die Produktionsspeichergruppe verbunden ist, erstellt und verwaltet wird. Die Produktionsspeichergruppe wird als aktive Kopie bezeichnet und die auf dem separaten Datenträgersatz verwaltete Kopie der Speichergruppe als passive Kopie. Die folgende Abbildung zeigt eine grundlegende Bereitstellung von LCR.

Grundlegende Bereitstellung von LCR

LCR bietet den Protokollversand, die Protokollwiedergabe und einen schnellen manuellen Wechsel zu einer sekundären Kopie der Daten (als Aktivierung bezeichnet). LCR ist auf die Senkung der Gesamtbetriebskosten von Microsoft Exchange Server 2007 ausgelegt durch:

• Verkürzung der Wiederherstellungsdauer bei Ausfällen auf Datenebene, indem ein schneller Wechsel zu einer sekundären Onlinekopie der Daten ermöglicht wird.

• Verringern der Anzahl regelmäßiger vollständiger Sicherungen, die zum Schutz der Daten erforderlich sind. Datensicherungen sind von entscheidender Bedeutung, wenn ein Notfall eintritt. Zwar macht LCR das Erstellen von Sicherungen nicht grundsätzlich überflüssig, doch wird die Notwendigkeit, regelmäßig vollständige, tägliche Sicherungen zu erstellen, erheblich verringert.

• Ermöglichen der Verlagerung von VSS-Sicherungen (Volume Shadow Copy Service) von der aktiven Kopie einer Speichergruppe auf die passive Kopie der Speichergruppe. Alle vier VSS-Sicherungstypen (vollständige Sicherung, Kopiesicherung, inkrementelle und differenzielle Sicherung) können anhand der passiven Kopie durchgeführt werden. Durch die Verlagerung der Sicherungen von der aktiven auf die passive Kopie wird die Anzahl verfügbarer, wertvoller Datenträger-E/As für die LUNs (Logical Unit Number) der aktiven Kopie erhöht.

Die fortlaufende lokale Replikation ermöglicht die Konfiguration, den Betrieb, die Überprüfung, die Entfernung und die Aktivierung einer Speichergruppenkopie. Bei Bedarf kann eine passive Kopie als Produktionsdatenbank aktiviert und dann bereitgestellt und für Clients verfügbar gemacht werden. Üblicherweise kann diese Aufgabe als Konfigurationsänderung ausgeführt werden, entweder durch Wechseln der aktiven Speichergruppe und der Datenbankpfade ändern oder durch eine Betriebssystemaktion auf einer niedrigeren Ebene (z. B. durch Wechseln der den Protokoll- oder Datenbankvolumes zugeordneten Bereitstellungspunkte).

Für LCR gelten keine besonderen Speicheranforderungen. Mit LCR kann jede von Windows Server 2003 oder Windows Server 2008 unterstützte Speicherlösung verwendet werden, einschließlich DAS (Direct-Attached Storage), SAS (Serially Attached SCSI) und iSCSI (Internet SCSI). Eine Liste zertifizierter Speicherlösungen finden Sie im Windows Server-Katalog getesteter Produkte.

Die fortlaufende lokale Replikation ist eine besonders gut geeignete Option für Benutzer, die nach einem Ausfall oder Beschädigungen von Postfachdaten eine schnelle Wiederherstellung benötigen, bei denen jedoch geplante und ungeplante Serverausfälle zulässig sind. LCR bietet Folgendes:

• Schnelle Wiederherstellung in zwei Schritten bei Beschädigung oder Ausfall einer Produktionsdatenbank

• Schutz für die Benutzer, die diesen am meisten benötigen

• Minimale Auswirkung auf die E/A-Vorgänge in der Produktionsdatenbank und auf dem Protokolldatenträger

• Möglichkeit der Verlagerung von VSS-Sicherungen auf die passive Kopie der Datenbank und von Protokollen

• Möglichkeit der Reduzierung der auf die Sicherungsmedien zu übertragenden Gesamtdatenmenge bei gleichzeitiger Vergrößerung des Zeitfensters für die Sicherung

• Verwaltung über die Exchange-Verwaltungskonsole oder Exchange-Verwaltungsshell

Verbesserungen von LCR in Exchange 2007 SP1

Microsoft Exchange Server 2007 Service Pack 1 (SP1) enthält verschiedene Verbesserungen von LCR, u. a. Verwendung des Transportpapierkorbs, zusätzliche Elemente der Benutzeroberfläche in der Exchange-Verwaltungskonsole, verbesserte Status- und Überwachungsfunktionen sowie bessere Leistung.

Transportpapierkorb für LCR aktiviert

Das Transportpapierkorb-Feature der Serverfunktion Hub-Transport wurde in Exchange 2007 SP1 erweitert, sodass nun LCR unterstützt wird. In der RTM-Version (Release to Manufacturing) von Microsoft Exchange Server 2007 war der Transportpapierkorb nur für Umgebungen mit fortlaufender Clusterreplikation (Cluster Continuous Replication, CCR) verfügbar. Anders als bei CCR, wo die Anforderung für die erneute Zustellung aus dem Transportpapierkorb bei der Wiederherstellung automatisch ausgeführt wird, muss dieser Vorgang in einer LCR-Umgebung manuell ausgeführt werden. Das Cmdlet Restore-StorageGroupCopy wurde in Exchange 2007 SP1 aktualisiert und umfasst nun die Anforderung für die erneute Übermittlung aus dem Transportpapierkorb. Wenn ein Administrator mit dem Cmdlet Restore-StorageGroupCopy eine passive Kopie einer Speichergruppe in einer LCR-Umgebung aktiviert, wird daher die Anforderung für die erneute Übermittlung aus dem Transportpapierkorb als Teil der Aktivierung ausgeführt.

Der Transportpapierkorb nutzt die Redundanz in der Umgebung, um einen Teil der vom Failover betroffenen Daten verfügbar zu machen. Insbesondere verwalten Hub-Transport-Server eine Warteschlange mit den zuletzt zugestellten E-Mails. Diese Warteschlange ist abhängig von der Aufbewahrungsdauer von E-Mails und dem gesamten verwendeten Speicherplatz. Dem Task Restore-StorageGroup wurde neue Funktionalität hinzugefügt. Wenn nun ein Administrator diesen Task verwendet, um die passive Kopie einer Speichergruppe zu aktivieren, fordert der Microsoft Exchange-Replikationsdienst von jedem Hub-Transport-Server am Standort des Postfachservers die erneute Zustellung von Nachrichten im Transportpapierkorb an. Der Informationsspeicher löscht automatisch die Duplikate und stellt verlorene E-Mails erneut zu.

In Exchange 2007 SP1 bleibt eine E-Mail-Nachricht nur unter der Voraussetzung im Transportpapierkorb erhalten, dass mindestens ein Empfänger der Nachricht über ein Postfach auf einem Postfachclusterserver in einer CCR-Umgebung oder auf einem eigenständigen Server in einer für LCR konfigurierten Speichergruppe verfügt.

Für folgende Elemente kann der Transportpapierkorb einen Datenverlust nicht verhindern:

• Ordner Entwürfe für alle Microsoft Outlook-Clients im Onlinemodus.

• Termine, Aktualisierungen von Kontakten, Aktualisierungen von Eigenschaften, Tasks und Aktualisierungen von Tasks.

• Ausgehende E-Mail-Nachrichten, die vom Client an den Hub-Transport-Server unterwegs sind. Es gibt eine Zeitspanne, in der E-Mail-Nachrichten nur auf dem Postfachserver des Absenders existieren.

Ausführliche Anweisungen zum Konfigurieren der Einstellungen für den Transportpapierkorb finden Sie unter Konfigurieren des Transportpapierkorbs für die fortlaufende lokale Replikation.

Verbesserungen der Exchange-Verwaltungskonsole

In Exchange 2007 SP1 wurden verschiedene neue Elemente der Benutzeroberfläche hinzugefügt, mit denen die Verwaltungserfahrung für Hochverfügbarkeitsfeatures wie LCR verbessert wird. Diese Verbesserungen umfassen unter anderem:

• Benutzeroberfläche des Transportpapierkorbs   Dem Knoten Hub-Transport im Arbeitsbereich Organisationskonfiguration wurde die neue Registerkarte Globale Einstellungen hinzugefügt. Diese Registerkarte umfasst die Seite Transporteinstellungen - Eigenschaften, auf der Sie die Einstellungen für den Transportpapierkorb für die Organisation konfigurieren können:

  • Maximale Größe pro Speichergruppe (MB)   Gibt die maximale Größe der Transportpapierkorb-Warteschlange für jede Speichergruppe an.

  • Maximale Aufbewahrungsdauer (Tage)   Gibt an, wie lange eine E-Mail-Nachricht in der Transportpapierkorb-Warteschlange aufbewahrt werden soll.

• Verwaltung der fortlaufenden Replikation   Der Benutzeroberfläche der Exchange-Verwaltungskonsole wurden zusätzliche Steuerelemente hinzugefügt, die es dem Administrator ermöglichen, die fortlaufende Replikation anzuhalten, fortzusetzen, zu aktualisieren und wiederherzustellen. Diese Steuerelemente entsprechen der Verwendung der folgenden Cmdlets der Exchange-Verwaltungsshell:

  • Suspend-StorageGroupCopy

  • Resume-StorageGroupCopy

  • Update-StorageGroupCopy

  • Restore-StoreGroupCopy

  Mithilfe dieser Cmdlets und der entsprechenden Exchange-Verwaltungskonsolenaufgaben können Sie die fortlaufende Replikation sowohl in LCR- als auch in CCR-Umgebungen verwalten.

Verbesserungen von Status und Überwachung

In Exchange 2007 SP1 sind auch verschiedene Änderungen enthalten, die auf eine höhere Verwaltungsfreundlichkeit von Exchange 2007 abzielen. Dazu zählen Verbesserungen der Berichtsfeatures für Cluster in Exchange 2007 RTM sowie zusätzliche Funktionalität für die proaktive Überwachung von Umgebungen mit fortlaufender Replikation. Insbesondere werden durch die Änderungen und Verbesserungen bekannte Mängel des Cmdlets Get-StorageGroupCopyStatus korrigiert, ein neues Cmdlet namens Test-ReplicationHealth eingeführt und eine verbesserte Einsichtnahme in das vom Transportpapierkorb abgedeckte Verlustfenster bereitgestellt.

Verbesserungen des Cmdlets "Get-StorageGroupCopyStatus"

In Exchange 2007 RTM gibt es mehrere Umstände, unter denen der von Get-StorageGroupCopyStatus gemeldete Status und die Leistungsindikatoren der fortlaufenden Replikation ungenau oder irreführend sind:

• Eine Speichergruppe, die nicht aktiv ist (d. h. sich nicht ändert), kann als Fehlerfrei gemeldet werden, obwohl sie möglicherweise nicht fehlerfrei ist. Diese Situation tritt ein, weil der fehlerhafte Zustand erst erkannt wird, wenn ein Protokoll wiedergegeben wird.

• Während der Initialisierung der Replikation wird der Replikationssatus erneut bewertet und ist möglicherweise nicht mehr genau. Nach Abschluss der Initialisierung wird der Status aktualisiert.

• Der Wert des Felds LastLogGenerated kann falsch sein, wenn die Bereitstellung der Datenbank in der Speichergruppe aufgehoben wird.

• Wenn in der Mitte eines Protokollstreams mindestens ein Protokoll fehlt, setzt die passive Kopie ihre Wiederherstellungsversuche fort, was dazu führt, dass der Replikationsstatus zwischen den Zuständen Fehler und Fehlerfrei wechselt. Wenn dies eintritt, wachsen die Wiedergabe- und Kopiewarteschlangen weiterhin an.

• Unter seltenen Umständen kann ein Protokoll erfolgreich überprüft werden, aber dennoch nicht fehlerfrei wiedergegeben werden. In dieser Situation wechselt das System während der Wiederherstellungsversuche ständig zwischen den Zuständen Fehler und Fehlerfrei. Wenn dies eintritt, wachsen die Wiedergabe- und Kopiewarteschlangen weiterhin an.

Das Cmdlet Get-StorageGroupCopyStatus wurde auch durch Hinzufügen neuer Statusinformationen verbessert:

• Das Cmdlet Get-StorageGroupCopyStatus meldet einen SummaryCopyStatus von "ServiceDown", wenn nicht über das Netzwerk auf den Microsoft Exchange-Replikationsdienst auf dem Zielcomputer zugegriffen werden kann.

• Das Cmdlet Get-StorageGroupCopyStatus meldet einen SummaryCopyStatus von "Initialisieren", wenn der Microsoft Exchange-Replikationsdienst auf dem Zielcomputer die Anfangstests beim Startvorgang noch nicht abgeschlossen hat. Es wurde außerdem eine neuer Leistungsindikator erstellt, um diesen Status als Booleschen Wert darstellen zu können.

• Das Cmdlet Get-StorageGroupCopyStatus meldet einen SummaryCopyStatus von "Synchronisieren", wenn das inkrementelle erneute Seeding noch nicht abgeschlossen ist.

Die neuen Zustände für den Wert SummaryCopyStatus sind nur bei Verwendung der Exchange 2007 SP1-Version der Exchange-Verwaltungstools sichtbar. Bei Verwendung der Exchange 2007 RTM-Version der Exchange-Verwaltungstools wird der Status für jeden vorherigen Zustand als Fehler gemeldet.

Test-ReplicationHealth (Cmdlet)

Mit Exchange 2007 SP1 wird ein neues Cmdlet namens Test-ReplicationHealth eingeführt. Dieses Cmdlet ist auf die proaktive Überwachung der fortlaufenden Replikation sowie der fortlaufenden Replikationspipeline ausgelegt. Das Cmdlet Test-ReplicationHealth prüft alle Aspekte der Replikation, der Clusterdienste und der Speichergruppenreplikation sowie den Wiedergabestatus, um eine vollständige Übersicht über das Replikationssystem bereitzustellen. Insbesondere wenn das Cmdlet Test-ReplicationHealth auf einem Knoten im Cluster ausgeführt wird, führt es die in der folgenden Tabelle beschriebenen Tests aus.

Vom Test-ReplicationHealth-Cmdlet ausgeführte Tests

Leistungsverbesserungen

In Exchange 2007 SP1 wurden verschiedene Leistungsverbesserungen vorgenommen, die für Bereitstellungen mit hoher Verfügbarkeit von Vorteil sind. Zu diesen Verbesserungen zählen E/A-Verringerungen für die Datenträger, auf denen sich passive Kopien von Speichergruppen befinden, in Umgebungen mit fortlaufender Clusterreplikation. In Exchange 2007 SP1 wurde das Design der Architektur mit fortlaufender Replikation so geändert, dass der Datenbankcache nun zwischen den einzelnen Instanzen der Protokollwiedergabe für die Speichergruppenkopie beibehalten wird. Durch die Beibehaltung des Datenbankcaches zwischen den einzelnen Instanzen der Protokollwiedergabe wird der Microsoft Exchange-Replikationsdienst in die Lage versetzt, die Datenbankcachefeatures der Extensible Storage Engine (ESE) zu nutzen, wodurch wiederum die Menge der Datenträger-E/A-Operationen für die LUNs der passiven Kopie verringert wird. In Exchange 2007 RTM hingegen wurde für jeden Batch von Protokollwiedergaben ein neuer Datenbankcache erstellt, was dazu führte, dass die Datenträger-E/A-Aktivität für die passiven LUNs bis zu zwei- bis dreimal so hoch war wie die Datenträger-E-/A-Aktivität für die aktiven LUNs.

Verwenden der fortlaufenden Standbyreplikation mit LCR

Die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR) ist ein neues Feature in Exchange 2007 SP1. SCR erweitert das vorhandene fortlaufende Replikationsfeature und aktiviert neue Datenverfügbarkeitsszenarien für Exchange 2007-Postfachserver. SCR verwendet dieselbe Protokollversand- und -wiedergabetechnologie, die auch von der LCR und CCR verwendet wird, um zusätzliche Bereitstellungsoptionen und -konfigurationen bereitzustellen.

Mit SCR können Sie die fortlaufende Replikation verwenden, um Postfachserverdaten von einem eigenständigen Postfachserver (mit oder ohne LCR) oder von einem Postfachclusterserver in einer SCC-Umgebung (Single Copy Cluster, Einzelkopiecluster) oder einer CCR-Umgebung zu replizieren.

Die Aktivierung von Postfachserverdaten, die mit SCR erstellt und verwaltet werden, erfolgt manuell. Sie ist für Situationen konzipiert, in denen ein schwerwiegender Fehler auftritt. Darunter fallen keine einfachen Serverausfälle, die durch einen Neustart oder anderweitig rasch zu beheben sind. Sie können ein SCR-Ziel mit der Datenbankportabilität, der Option für die Serverwiederherstellung (Setup /m:RecoverServer), oder, bei einem Postfachclusterserver, mit der Option für die Wiederherstellung von Postfachclusterservern (Setup /RecoverCMS) aktivieren. Die von Ihnen zu wählende Option hängt von Ihrer Konfiguration und dem Typ des aufgetretenen Fehlers ab.

Weitere Informationen zur SCR finden Sie unter Fortlaufende Standbyreplikation.

Weitere Informationen

In den folgenden Themen wird erläutert, wann und wie die LCR als Teil eines Hochverfügbarkeits- und Datenausfallsicherheitsplans verwendet wird:

• Planen der fortlaufenden lokalen Replikation

• Verwalten der fortlaufenden lokalen Replikation

• Problembehandlung von Problemen der fortlaufenden lokalen Replikation