Verwalten der fortlaufenden Standbyreplikation

Exchange 2007
 

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

Letztes Änderungsdatum des Themas: 2008-11-19

Zusätzlich zur Verwaltung und Administration der täglichen Aufgaben einer Microsoft Exchange-Organisation gibt es spezifische Aufgaben für die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR). Im Allgemeinen fallen die folgenden Verwaltungsaufgaben für SCR an:

  • Konfigurieren des Datenträgerspeichers für SCR und Verwalten der Datenträgervolumes.

  • Aktivieren und Deaktivieren von SCR.

  • Überwachen der Replikationsaktivität.

  • Bereitstellen, Aufheben der Bereitstellung, Erstellen und Entfernen von Datenbanken.

  • Verschieben des Speicherorts für die Speicherung von Speichergruppen oder Datenbankdateien, wenn eine Speichergruppe SCR-aktiviert ist.

  • Überprüfen des Status des SCR-Ziels.

  • Verwalten der Replikations- und Wiedergabeaktivitäten.

  • Wiederherstellung nach Fehlern.

Diese Aufgaben werden im letzten Teil dieses Themas erläutert.

SCR kann ausschließlich mithilfe der Exchange-Verwaltungsshell aktiviert und verwaltet werden. Die Exchange-Verwaltungskonsole kann nicht zum Aktivieren oder Deaktivieren von SCR, zum Anzeigen des SCR-Status oder zum Verwalten der SCR-Aspekte verwendet werden.

Für SCR sind keine besonders konfigurierten Datenträgerspeicher erforderlich. SCR erfordert einen Speicher, der eine entsprechende Kapazität aufweist. Vergleichbare Speicherlösungen sollten für alle SCR-Ziele konfiguriert werden, die für dieselbe Speichergruppe konfiguriert sind. Es wird empfohlen, die Konfigurationsverfahren zu befolgen, die der Speicherlieferant bereitstellt, um die Konfiguration abzuschließen.

Bei der Verwaltung einer SCR-Umgebung ist es möglicherweise erforderlich, Datenträgervolumes zu verwalten, die mit Ihrem Servercomputer mit Exchange verbunden sind. Das Datenträgervolume muss z. B. zu Wartungszwecken oder aus anderen Gründen vorübergehend vom System getrennt werden. Wenn Wartungsarbeiten an dem Datenträgervolume ausgeführt werden müssen, das die aktive Kopie der Speichergruppe enthält, sollte die Bereitstellung der Datenbank in der aktiven Kopie der Speichergruppe aufgehoben werden. Wenn Wartungsarbeiten an den Datenträgervolumes ausgeführt werden müssen, das die passive Kopie der Speichergruppe enthalten, sollte jegliche E/A für den Datenträger beendet werden, indem die Replikation angehalten wird. Weitere Informationen zum Verwalten von Datenträgervolumes finden Sie unter Vorbereiten von Datenträgerverwaltungsaktivitäten bei Verwendung von SCR.

SCR wird nur in der Exchange-Verwaltungsshell und durch Ausführen des Cmdlets New-StorageGroup oder des Cmdlets Enable-StorageGroupCopy aktiviert. Beide Cmdlets umfassen einige neue Parameter, die mit Microsoft Exchange Server 2007 Service Pack 1 (SP1) eingeführt werden:

  • -StandbyMachine   Mithilfe dieses Parameters wird der Name des Computers angegeben, der das SCR-Ziel enthalten wird. Der Wert dieses Parameters wird als Teil 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 zum Active Directory-Verzeichnisdienstschema hinzugefügt wird, wenn Exchange 2007 SP1 in die Exchange-Organisation eingeführt wird.

  • -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. Die maximal zulässige Einstellung für diesen Wert ist 7 Tage. Die niedrigste zulässige Einstellung ist 0 Sekunden, obwohl sich das Einstellen dieses Werts auf 0 Sekunden nicht auf die Standardverzögerung bei der Protokollwiedergabe von 50 Protokolldateien auswirkt. Nachdem der Wert für diesen Parameter eingestellt wurde, kann er nicht geändert werden, ohne SCR zu deaktivieren und 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 erneut zu aktivieren.

  • -SeedingPostponed   Mithilfe dieses Parameters kann das anfängliche Seeding des SCR-Ziels übersprungen werden. Wenn dieser Parameter verwendet wird, muss der Administrator das Seeding für das SCR-Ziel manuell mithilfe des Cmdlets Update-StorageGroupCopy durchführen. Dieser Parameter ist nur mit dem Cmdlet Enable-StorageGroupCopy verfügbar. Es steht nicht mit dem Cmdlet New-StorageGroup zur Verfügung, da an diesem Punkt keine Quelldatenbank vorhanden ist.

    importantWichtig:
    Wenn Sie die Einstellungen für die Wiedergabe oder die Verzögerung beim Abschneiden ändern möchten, müssen Sie die SCR zuerst deaktivieren und unter Verwendung der neuen Werte für diese Einstellungen erneut aktivieren.

Zusätzlich zu der vom Administrator konfigurierten Wiedergabeverzögerung, die mithilfe des Parameters ReplayLagTime festgelegt wurde, verhindert Exchange auch die Wiedergabe einer festen Anzahl von Protokolldateien auf einem SCR-Ziel, unabhängig vom Wert für ReplayLagTime, mithilfe der folgenden Formel:

Maximum von ("Wert von ReplayLagTime" oder "X Protokolldateien")

wobei X=50 ist. 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.

importantWichtig:
Die integrierte Verzögerung von 50 Protokolldateien und der Wert des Parameters ReplayLagTime wirken sich auf die Erstellung der anfänglichen SCR-Zieldatenbank aus. Eine SCR-Zieldatenbank wird nicht erstellt, bevor 50 Transaktionsprotokolldateien auf den SCR-Zielcomputer repliziert wurden und die von ReplayLagTime (oder die Standardeinstellung von ReplayLagTime von 24 Stunden) angegebene Zeit abgelaufen ist.

Wenn Sie SCR für eine Speichergruppe aktivieren, wird automatisch eine Kopie der Speichergruppe (Systemdateien, Protokolldateien und die Datenbankdatei) auf dem SCR-Zielcomputer erstellt und verwaltet, wobei dieselben Pfade wie für die Speichergruppe der SCR-Quelle verwendet werden.

Nach der Aktivierung von SCR wird empfohlen, den Zustand und den Status der einzelnen Speichergruppen mithilfe des Cmdlets Test-ReplicationHealth zu überwachen. Ausführliche Anweisungen zum Aktivieren von SCR finden Sie unter Aktivieren der fortlaufenden Standbyreplikation für vorhandene Speichergruppen und Aktivieren der fortlaufenden Standbyreplikation für eine neue Speichergruppe.

Da Sie für eine SCR-Zieldatenbank keine Sicherungen erstellen können, basiert das Abschneiden von SCR-Protokollen nicht auf den Sicherungszeiten. Stattdessen wird das Abschneiden von Protokollen durch den Prüfpunkt an der SCR-Quelle und den Wert für TruncationLagTime bestimmt.

Wenn es sich bei der SCR-Quelle um einen Postfachclusterserver (CMS) in einer CCR-Umgebung handelt, dann umfasst das Abschneiden von Protokollen das erfolgreiche Kopieren und Untersuchen von Protokolldateien durch alle SCR-Ziele. Wenn somit ein SCR-Ziel nicht verfügbar ist, tritt das Abschneiden von Protokollen bei der SCR-Quelle auch dann nicht auf, wenn Datensicherungen erstellt wurden.

In einer SCR-Umgebung muss für ein SCR-Ziel, das deaktiviert und dann erneut aktiviert wurde, möglicherweise das erneute Seeding nicht durchgeführt werden, wenn alle erforderlichen Protokolldateien verfügbar sind; die Entscheidung fällt unter diesen Gesichtspunkten:

  • Wenn für die Speichergruppe die Umlaufprotokollierung aktiviert ist, führt das Löschen von Protokollen für das erneut aktivierte SCR-Ziel aufgrund von Lücken in der Protokollfolge dazu, dass ein erneutes Seeding erforderlich ist.

  • Wenn eine Datensicherung erstellt wird, die das Abschneiden von Protokolldateien umfasst, führt das Löschen von Protokollen für das erneut aktivierte SCR-Ziel aufgrund von Lücken in der Protokollfolge dazu, dass ein erneutes Seeding erforderlich ist.

Wenn die Protokolldateien über keine der zuvor genannten Methoden abgeschnitten werden, sollte das Deaktivieren und erneute Aktivieren von SCR kein erneutes Seeding erfordern. In diesem Fall müssen Protokolldateien am SCR-Ziel gelöscht werden, die aber von der SCR-Quelle erneut repliziert werden.

Wenn Sie vorhaben, ein zuvor deaktiviertes SCR-Ziel erneut zu aktivieren, ist es empfehlenswert, keine Protokolle abzuschneiden (z. B. durch Aktivieren der Umlaufprotokollierung oder durch Ausführen von Sicherungen, bei denen Protokolle abgeschnitten werden), bis das SCR-Ziel aktiviert und die Konfigurationsänderung, durch die die erneute Aktivierung erforderlich wurde, im gesamten Active Directory repliziert wurde.

SCR wird nur mithilfe des Cmdlets Disable-StorageGroupCopy und des Parameters StandbyMachine deaktiviert. Beim Deaktivieren von SCR ist es wichtig, dass Sie für den Parameter StandbyMachine den entsprechenden Wert einbeziehen. Wenn für die SCR-Speichergruppe auch LCR aktiviert ist und Sie den Parameter StandbyMachine nicht als Teil des Befehls einbeziehen, dann wird LCR für die Speichergruppe deaktiviert.

Das Deaktivieren von SCR ist erforderlich, um den Wert für den Parameter ReplayLagTime oder TruncationLogDelay zu ändern. Diese Werte können nicht geändert werden, solange SCR aktiviert ist. Um somit die Verzögerungseinstellungen für die Wiedergabe oder das Abschneiden zu ändern, müssen Sie zuerst SCR deaktivieren und dann mithilfe der neuen Werte für diese Einstellungen erneut aktivieren.

Ausführliche Anweisungen zum Aktivieren von SCR für eine Speichergruppe finden Sie unter Deaktivieren der fortlaufenden Standbyreplikation für eine Speichergruppe.

Zwar erfordert SCR keine besondere Überwachung, es wird jedoch empfohlen, alle Speichergruppen regelmäßig zu überwachen, damit sichergestellt ist, dass sie Protokolldateien ordnungsgemäß replizieren. Das Microsoft Exchange Server 2007 Management Pack für Microsoft Operations Manager 2005 enthält Warnmeldungen für mehrere wichtige Probleme, die in SCR-Umgebungen auftreten können:

  • Der Microsoft Exchange-Replikationsdienst wird nicht ausgeführt. Beachten Sie, dass das Ereignis, das diese Warnung generiert, nach dem Beenden des Diensts nicht wiederholt angezeigt wird. Daher gehen alle mit ihm verbundenen Warnungen verloren, wenn es gelöscht wird.

  • Die SCR-Zielkopie weist den Status "Fehler" auf.

  • Die SCR-Zielkopie weist den Status "Fehlerfrei" auf, ist jedoch beim Kopiervorgang des Protokolls im Rückstand.

Sie sollten alle vorangehenden Warnmeldungen schnellstmöglich untersuchen und beheben, die vom Exchange 2007 Management Pack generiert wurden.

Mit Exchange 2007 SP1 wird ein neues Cmdlet namens Test-ReplicationHealth eingeführt. Dieses Cmdlet ist auf die proaktive Überwachung der fortlaufenden Replikation (LCR, CCR und SCR) sowie der fortlaufenden Replikationspipeline ausgelegt. Das Cmdlet Test-ReplicationHealth prüft alle Aspekte der Replikation, der Clusterdienste, der Speichergruppenreplikation und den Wiedergabestatus, um eine umfassende Übersicht über das Replikationssystem bereitzustellen. Insbesondere führt das Cmdlet Test-ReplicationHealth die in der folgenden Tabelle beschriebenen Tests durch.

Vom Test-ReplicationHealth-Cmdlet ausgeführte Tests

Test Beschreibung

Status des Clusternetzwerks

Überprüft, ob alle auf dem lokalen Knoten gefundenen clusterverwalteten Netzwerke ausgeführt werden. Dieser Test ist nur in CCR-Umgebungen gültig.

Zustand der Quorumgruppe

Überprüft, ob die Clustergruppe, die die Quorumressource enthält, fehlerfrei ist. Dieser Test ist nur in CCR-Umgebungen gültig.

Zustand des Dateifreigabequorums

Überprüft, ob der Wert von FileSharePath, der vom Hauptknotensatzquorum mit Dateifreigabenzeuge verwendet wird, erreichbar ist. Dieser Test ist nur in CCR-Umgebungen gültig.

Zustand der Postfachclusterserver-Gruppe

Überprüft, ob der Postfachclusterserver fehlerfrei ist, indem sichergestellt wird, dass alle Ressourcen in der Gruppe online sind. Dieser Test ist nur in CCR-Umgebungen gültig.

Knotenzustand

Überprüft, das keiner der Knoten im Cluster sich im Zustand Angehalten befindet. Dieser Test ist nur in CCR-Umgebungen gültig.

Status der DNS-Registrierung

Überprüft, ob für alle clusterverwalteten Netzwerkschnittstellen, für die Erfolgreiche DNS-Registrierung vorschreiben festgelegt ist, die DNS-Registrierung (Domain Name System) ausgeführt wurde. Dieser Test ist nur in CCR-Umgebungen gültig.

Status des Replikationsdiensts

Überprüft, ob der Microsoft Exchange-Replikationsdienst auf dem passiven Knoten fehlerfrei ausgeführt wird.

Speichergruppenkopie angehalten

Überprüft, ob die fortlaufende Replikation für eine der Speichergruppen angehalten wurde.

Speichergruppenkopie mit Fehler

Überprüft, ob eine der Speichergruppenkopien den Status "Fehler" aufweist.

Länge der Speichergruppenreplikations-Warteschlange

Überprüft, ob eine der Speichergruppen eine Replikationskopiewarteschlange besitzt, die länger als die Schwellenwerte der bewährten Methoden ist. Zurzeit handelt es sich bei diesen Schwellenwerten um folgende:

  • Warnung   Warteschlangenlänge beträgt 3 bis 5 Protokolle.

  • Fehler   Warteschlangenlänge beträgt 6 oder mehr Protokolle.

Datenbanken mit nach Failover aufgehobener Bereitstellung

Überprüft, ob die Bereitstellung von Datenbanken nach einem Failover aufgehoben wurde oder sie den Status "Fehler" aufweist. Mit diesem Test wird nur das Vorhandensein von Datenbanken überprüft, die als Folge eines Failovers fehlerhaft sind.

Gelegentlich müssen Datenbanken in einer SCR-Umgebung bereitgestellt werden, oder die Bereitstellung muss aufgehoben werden. Wenn für die SCR-Quellspeichergruppe oder die Datenbank eine Neukonfiguration oder Wartung erforderlich ist, müssen Sie die Dienste für den Zeitraum dieser Aktivitäten blockieren, die mit beiden interagieren. Dies ist möglicherweise erforderlich, um eine Neukonfiguration vorzunehmen oder um Probleme mit dem Server oder der Datenbank zu beheben. Beim Aufheben der Bereitstellung einer Datenbank kann auf diese nicht zugegriffen werden.

Sie können den Speicherort einer Datenbank in einer SCR-aktivierten Speichergruppe ändern. In einer SCR-Umgebung gibt es zwei Datenbankdateien, eine pro Kopie. Wenn die Speichergruppendateien oder die Datenbankdatei verschoben werden, müssen die Speicherorte für beide Kopien zusammen geändert werden.

noteHinweis:
Der vollständige Pfad für die Speichergruppendateien und die Datenbankdatei muss für die SCR-Quelle sowie für alle SCR-Ziele übereinstimmen.

Für die Neukonfiguration des Speicherorts der Protokoll- und Systemdateien einer Speichergruppe und des Speicherorts der Datenbankdateien in einer SCR-Umgebung werden ähnliche Verfahren angewandt. Ausführliche Anweisungen zum Ändern des Speicherorts von Protokoll- und Systemdateien für eine SCR-aktivierte Speichergruppe finden Sie unter Verschieben einer Speichergruppe in eine Umgebung mit fortlaufender Standbyreplikation. Ausführliche Anweisungen zum Ändern des Speicherorts von Datenbankdateien in einer SCR-Umgebung finden Sie unter Verschieben einer Datenbank in einer Umgebung mit fortlaufender Standbyreplikation.

importantWichtig:
Datenbanken können nicht im Stammverzeichnis eines Volumes abgelegt werden.

Sämtliche Überwachungen und Statusanzeigen werden mithilfe der Exchange-Verwaltungsshell durchgeführt. Die Exchange-Verwaltungskonsole zeigt weder den Kopierstatus noch andere Informationen über SCR an. Nachdem die SCR für eine Speichergruppe aktiviert wurde, können mithilfe der Exchange-Verwaltungsshell die SCR-spezifischen Konfigurationseinstellungen für die Speichergruppe und ihre Datenbank angezeigt werden.

Exchange 2007 gibt eine Reihe von Statusinformationen für SCR-Kopien aus. In der folgenden Tabelle werden die Statusinformationen beschrieben, die für SCR-aktivierte Speichergruppen verfügbar sind. Ausführliche Anleitungen zum Abrufen von Statusinformationen finden Sie unter Anzeigen des Status der fortlaufenden Standbyreplikation.

noteHinweis:
In der folgenden Tabelle werden die Eigenschaften in der Reihenfolge aufgeführt, in der sie auftreten, wenn die vollständige Ausgabe des Cmdlets Get-StorageGroupCopyStatus angezeigt wird.

Für SCR-aktivierte Speichergruppen verfügbare Statusinformationen

Eigenschaft Beschreibung

Identity

Name und Name der abgefragten Speichergruppe.

StorageGroupName

Name der abgefragten Speichergruppe.

SummaryCopyStatus

Aktueller Gesamtstatus der SCR-Kopie. Die folgenden Werte sind möglich:

  • Nicht unterstützt   Die aktuelle Konfiguration unterstützt keine fortlaufende Replikation.

  • Deaktiviert   Der Computer wurde nicht als Ziel angegeben. Wenn der Zielcomputer die aktualisierten Informationen in Active Directory noch nicht gelesen hat, die ihn als Zielcomputer angeben, dann meldet er den Status "Deaktiviert". Wenn Sie diesen Zielcomputer für SCR aktiviert haben, dieser aber den Status "Deaktiviert" meldet, überprüfen Sie die Active Directory-Replikation auf Probleme oder Wartezeiten.

  • Fehler   Überprüfungsfehler (die Datenbank oder die Protokolle waren nicht kompatibel), oder die Speichergruppe ist nicht ordnungsgemäß für SCR konfiguriert.

  • Seeding   Das Seeding der Datenbank wird ausgeführt.

  • Initialisieren   Das System wird online geschaltet, aber die Replikation wurde noch nicht gestartet. Das System verbleibt in diesem Zustand, bis eine Transaktionsprotokolldatei generiert wurde.

  • Dienst nicht erreichbar    Der Microsoft Exchange-Replikationsdienst wird nicht ausgeführt.

  • Angehalten   Das Kopieren und die Wiedergabe des Transaktionsprotokolls wurde beendet.

  • Synchronisieren   Das System hat einen Failover erkannt und behebt aufgetretene Abweichungen.

  • Fehlerfrei   Der Status ist ordnungsgemäß und normal. Keine Vorgänge blockieren oder sind blockiert.

Failed

Die Überprüfung der Datenbank oder Protokolle hat eine Inkonsistenz festgestellt, die die Replikation verhindert. Möglicherweise liegt auch ein Konfigurations- oder Zugriffsproblem für die aktive oder passive Kopie vor. Mögliche Werte sind True und False.

FailedMessage

Textmeldung, die die Bedingung identifiziert, die den Replikationsfehler verursacht hat. Dies muss nicht der einzige Bereich im Rahmen der Replikation sein, in dem ein Problem aufgetreten ist.

Seeding

Das Seeding wird ausgeführt. Mögliche Werte sind True und False.

Anhalten

Die Replikation (und die Wiedergabe) wurde für die passive Kopie angehalten. Dies hindert die Datenbank am Fortschritt und verhindert, dass die Protokolle kopiert werden. Mögliche Werte sind True und False.

SuspendComment

Optionaler Administratorkommentar, der eine Begründung oder einen Hinweis bereitstellt, warum die Replikationsaktivitäten angehalten wurden.

CopyQueueLength

Die Anzahl der Transaktionsprotokolldateien, die auf den Kopiervorgang in den Protokolldateiordner der passiven Kopie warten. Eine Kopie wird erst als angeschlossen betrachtet, nachdem sie auf Fehler untersucht wurde.

ReplayQueueLength

Die Anzahl der kopierten Transaktionsprotokolldateien, die auf den Wiedergabevorgang in die passive Kopie warten.

LatestAvailableLogTime

Der Zeitstempel der Quellspeichergruppe der zuletzt erkannten neuen Transaktionsprotokolldatei.

LastCopyNotificationedLogTime

Die Zeit, die mit dem letzten neuen Protokoll verknüpft ist, das von der aktiven Speichergruppe erstellt wurde und der Kopie bekannt ist.

LastCopiedLogTime

Der Zeitstempel der Quellspeichergruppe der letzten erfolgreichen Kopie einer Transaktionsprotokolldatei.

LastInspectedLogTime

Der Zeitstempel der Zielspeichergruppe der letzten erfolgreichen Untersuchung einer Transaktionsprotokolldatei.

LastReplayedLogTime

Der Zeitstempel der Zielspeichergruppe der letzten erfolgreichen Wiedergabe einer Transaktionsprotokolldatei.

LastLogGenerated

Die letzte Protokollgenerierungsnummer, die bekanntermaßen auf der aktiven Kopie der Speichergruppe generiert wurde.

LastLogCopied

Die letzte Protokollgenerierungsnummer, die erfolgreich in den Protokollordner der passiven Kopie kopiert wurde.

LastLogNotified

Die letzte Protokollgenerierungsnummer, die von der aktiven Speichergruppe generiert wurde und der Kopie bekannt ist.

LastLogInspected

Die letzte Protokollgenerierungsnummer, die auf Konsistenz und Fehler untersucht wurde.

LastLogReplayed

Die letzte Protokollgenerierungsnummer, die erfolgreich in die passive Kopie der Speichergruppe wiedergegeben wurde.

LatestFullBackupTime

Der Zeitpunkt der letzten vollständigen Sicherung.

LatestIncrementalBackupTime

Der Zeitpunkt der letzten inkrementellen Sicherung.

SnapshotBackup

Die Sicherung wurde mithilfe von Legacystreaming-APIs oder des Volumeschattenkopie-Diensts (Volume Shadow Copy Service, VSS) vorgenommen. Mögliche Werte sind True und False.

Der Zustand einer SCR-Kopie lässt sich schnell durch Prüfen der Werte von SummaryCopyStatus, CopyQueueLength, ReplayQueueLength und LastInspectedLogTime einschätzen. Diese Eigenschaften zeigen an, ob die SCR-Kopie ordnungsgemäß funktioniert, und ob die SCR-Kopie sowohl in den Kopier- als auch in den Wiedergabeprotokollen relativ aktuell ist. Wenn der folgende Zustand eintritt, müssen Sie die Ursache dafür ermitteln und das Problem korrigieren:

  • Die Kopie befindet sich für einen erheblichen Zeitraum in einem nicht fehlerfreien Zustand.

  • Die Länge der Kopiewarteschlange ist größer als 5.

  • Die Länge der Wiedergabewarteschlange ist größer als 20.

  • Die Protokollzeit der letzten Überprüfung zeigt keine aktuelle Uhrzeit an. Dies kann durch zwei wahrscheinliche Ursachen bewirkt werden: In der Speichergruppe finden nicht viele Änderungen statt, oder der Replikationsdienst wurde beendet.

Die Werte für die Länge der Wiedergabe- und Kopiewarteschlange sind als Leistungsindikatoren verfügbar. Es handelt sich dabei um die Leistungsindikatoren CopyQueueLength und ReplayQueueLength unter dem Leistungsobjekt MSExchange-Replikation.

Es gibt einige sehr seltene Szenarien, in denen der Replikationsstatus irreführend sein kann. Im Folgenden finden Sie eine Liste dieser Szenarien:

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

  • Während der Initialisierung der Replikation wird der Replikationsstatus 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 einer Datenbank aufgehoben wird. Es werden aber alle Protokolle mit Endbenutzerinhalten repliziert, wenn die Speichergruppenkopie repliziert wird.

  • Wenn in der Mitte eines Protokollstreams mindestens ein Protokoll fehlt, setzt die passive Kopie ihre Wiederherstellungsversuche fort. Hierdurch wechselt der Replikationsstatus zwischen den Zuständen Fehler und Fehlerfrei. Die Wiedergabe- und Kopiewarteschlangen wachsen weiterhin an.

  • Unter manchen äußerst 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". Die Wiedergabe- und Kopiewarteschlangen wachsen weiterhin an.

Wenn Sie SCR verwenden, wird empfohlen, die Integrität aller SCR-Zielkopien regelmäßig zu überprüfen, indem eine physikalische Konsistenzprüfung der Datenbank und der Transaktionsprotokolldateien ausgeführt wird. Bei einer physikalischen Konsistenzprüfung werden die Transaktionsprotokolle und die Datenbankdateien auf Beschädigungen überprüft. Die können die Überprüfung mithilfe der Befehlszeilenversion des Microsoft-Volumenschattenkopie-Diensttools (VSSAdmin.exe) und den Exchange Server-Datenbankdienstprogrammen (Eseutil.exe) durchführen. Ausführliche Anweisungen zum Verwenden von VSSAdmin und Eseutil zum Überprüfen der Transaktionsprotokolle und Datenbankdateien auf physikalische Fehler finden Sie unter Überprüfen einer fortlaufenden Standbyreplikationskopie.

noteHinweis:
Bevor Sie eine physikalische Konsistenzprüfung auf einer Datenbank ausführen, müssen Sie vorübergehend alle Replikationsaktivitäten für die Speichergruppe anhalten. Sie können die Replikationsaktivitäten mithilfe des Cmdlets Suspend-StorageGroupCopy in der Exchange-Verwaltungsshell anhalten. Nachdem die Konsistenzprüfung abgeschlossen ist, können die Wiedergabeaktivitäten des Transaktionsprotokolls mithilfe des Cmdlets Resume-StorageGroupCopy erneut aufgenommen werden. Es wird empfohlen, dass Sie die Überprüfung außerhalb der normalen Betriebszeit durchführen und die Zeitspanne minimieren, die die Wiedergabeaktivität angehalten wird. Der Grund besteht darin, dass durch das Anhalten der Speichergruppenkopie alle Aktualisierungen der SCR-Kopie angehalten werden. Dies bewirkt, dass einige Inhalte fehleranfällig werden.

Für das Verwalten der Protokolldateireplikation und -wiedergabe in einer SCR-Umgebung sind die folgenden Hauptaktivitäten erforderlich:

  • Anhalten der Replikation für die Speichergruppenkopie

  • Neustarten der Replikation für die Speichergruppenkopie

  • Erneutes Seeding für eine Speichergruppe

Es kann aus vielerlei Gründen erforderlich sein, die Replikationsaktivitäten des Transaktionsprotokolls anzuhalten und dann neu zu starten. Die Transaktionsprotokollreplikation tritt auf, wenn der Microsoft Exchange-Replikationsdienst ausgeführt wird, eine Speichergruppe für SCR aktiviert wurde und sowohl die SCR-Quelle als auch das SCR-Ziel betriebsbereit sind. Wenn die Quelle oder das Ziel nicht mehr verfügbar ist, müssen Sie die Replikation beenden. Außerdem erfordern einige Verwaltungsaufgaben, z. B. das Seeding, dass die Replikation für eine für SCR aktivierte Speichergruppe angehalten wird. Wenn der gesamte Zugriff auf die Datendateien eines Ziels beendet werden muss, müssen Sie die Replikation anhalten.

Gelegentlich kann es notwendig sein, die Aktivitäten des SCR-Ziels zu steuern. Dies ist möglicherweise erforderlich, um eine Neukonfiguration vorzunehmen oder um Probleme mit dem Server oder der Datenbank zu beheben. Das Anhalten der Protokollwiedergabe ist ebenfalls erforderlich, um eine physikalische Konsistenzprüfung des SCR-Ziels auszuführen. Wenn es erforderlich ist, die Aktualisierungen der Datenbankkopie zu steuern, muss die Replikation für das SCR-Ziel angehalten werden. Die Replikation muss ggf. außerdem beim Bearbeiten der Protokolle des SCR-Ziels angehalten werden.

Weitere Informationen Anhalten von Replikationsänderungen an SCR-Kopien finden Sie unter Anhalten von Änderungen an einem Ziel der fortlaufenden Standbyreplikation. Weitere Informationen zum Neustarten von Replikationsänderungen an SCR-Kopien finden Sie unter Wiederaufnehmen der Replikation auf einem Ziel für die fortlaufende Standbyreplikation. Weitere Informationen zum Ausführen einer Integritätsüberprüfung für die Transaktionsprotokolle und Datenbankdateien der passiven Kopie finden Sie unter Überprüfen einer fortlaufenden Standbyreplikationskopie.

Das Seeding und erneute Seeding einer Speichergruppenkopie in einer SCR-Umgebung wird mithilfe des Cmdlets Update-StorageGroupCopy mit dem Parameter StandbyMachine ausgeführt (dabei handelt es sich um einen in Exchange 2007 SP1 neu hinzugefügten Parameter).

Ausführliche Anweisungen zum Seeding oder erneuten Seeding für ein SCR-Ziel finden Sie unter Seeding eines fortlaufenden Standbyreplikationsziels.

Nach einem Fehler oder einer Beschädigung einer Datenbankkopie müssen Sie einschätzen, ob der Betrieb sofort mithilfe des SCR-Ziels fortgesetzt werden soll. SCR stellt wichtige Informationen zur Verfügung, die Sie bei dieser Entscheidung unterstützen:

  • Status der Kopie zum Zeitpunkt des Fehlers

  • Wiedergabe- und Kopiewarteschlangen zum Zeitpunkt des Fehlers

  • Die Protokollzeit der letzten Überprüfung zum Zeitpunkt des Fehlers

Die entsprechenden Informationen können mithilfe des Cmdlets Get-StorageGroupCopyStatus abgerufen werden. Genaue Anweisungen zum Abrufen dieser Informationen finden Sie unter Anzeigen des Status der fortlaufenden Standbyreplikation.

noteHinweis:
Die Protokollzeit der letzten Überprüfung stellt Informationen zu den letzten Änderungen aus der SCR-Quelle zur Verfügung. Diese Informationen unterstützen Sie beim Erkennen von Fehlern, die auftreten, wenn der Microsoft Exchange-Replikationsdienst nicht gestartet wurde, weil die Warteschlangenlängen falsch sind, wenn der Microsoft Exchange-Replikationsdienst beendet wurde.

Die Länge der Kopiewarteschlange enthält die besten verfügbaren Informationen zur SCR-Quelle zum Zeitpunkt des Fehlers. Basierend auf diesen Informationen und Ihrer Einschätzung der Wiederherstellungszeit für die fehlerhafte Datenbank müssen Sie entscheiden, ob das verfügbare SCR-Ziel aktiviert werden soll:

  • Wenn die Länge der Wiedergabewarteschlange erheblich ist, kann die Wiederherstellung zeitaufwendig sein. Dies ist jedoch kein Hinweis darauf, dass erhebliche Datenverluste zu befürchten sind.

  • Wenn die Länge der Kopiewarteschlange erheblich ist, sind viele Protokolle verloren gegangen. Wenn die Datenbank aktiviert wird, wird sie im Zeitrahmen ungefähr des letzten kopierten Protokolls wiederhergestellt (diese Angabe kann auch mithilfe des Cmdlets Get-StorageGroupCopyStatus abgerufen werden).

  • Wenn die Protokollzeit der letzten Überprüfung weit vor dem Zeitpunkt des Fehlers liegt, wurde der Microsoft Exchange-Replikationsdienst wahrscheinlich beendet, und die Warteschlangeninformationen sind ungenau.

    noteHinweis:
    Aufgrund der Eigenschaften von SCR sowie von externen Wartezeiten und Kommunikationsfehlern ist es möglich, dass die Länge der Kopiewarteschlange ungenau ist, weil der aktuelle Status der aktiven Kopie asynchron aktualisiert wird. Im Allgemeinen beschränkt sich die Ungenauigkeit auf Aktivitäten, die ungefähr eine Minute vor und nach dem Fehler stattgefunden haben.
    noteHinweis:
    Eine fehlerhafte Datenbank kann nicht für das Seeding eines SCR-Ziels verwendet werden.
 
Anzeigen: