Problembehandlung für die fortlaufende Clusterreplikation

  • Artikel

 

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

Letztes Änderungsdatum des Themas: 2008-01-14

In diesem Thema werden Problembehandlungsfragen erläutert, die sich auf die fortlaufende Clusterreplikation (Cluster Continuous Replication, CCR) beziehen. Weitere Informationen zu Tools, die Sie bei der Problembehandlung von CCR-Problemen unterstützen können, finden Sie unter Tools für die Problembehandlung bei Bereitstellungen für hohe Verfügbarkeit.

Die in diesem Thema behandelten Verfahren betreffen die folgenden Probleme, die in einer CCR-Umgebung auftreten können:

  • Get-StorageGroupCopyStatus meldet, dass ein Fehler der Datenbank aufgetreten ist und kein Seeding durchgeführt wurde.

  • Get-StorageGroupCopyStatus meldet, dass ein Fehler der Datenbank aufgetreten ist. Der FailedMessage-Wert zeigt an, dass eine Abweichung bei der Speichergruppenkopie aufgetreten ist.

  • Get-StorageGroupCopyStatus meldet, dass ein Fehler der Datenbank aufgetreten ist. Der Wert FailedMessage liefert detaillierte Informationen zur Fehlerquelle.

  • Warnungen, Leistungsindikatoren oder Get-StorageGroupCopyStatus zeigen an, dass Kopie- oder Wiedergabewarteschlangen für eine Speichergruppenkopie gesichert werden.

  • Get-StorageGroupCopyStatus meldet eine überholte Zeitangabe für LastInspectedLogTime.

  • Erfolg bei Failover oder Move-ClusteredMailboxServer, die Datenbanken können jedoch nicht bereitgestellt werden.

  • Erfolg bei Failover, doch einige Datenbanken werden nicht automatisch oder manuell bereitgestellt. Alternativ meldet Get-ClusteredMailboxServerStatus Fehler bei mindestens einer Datenbank.

  • Fehler beim Bereitstellen einer Datenbank beim Starten in einer CCR-Umgebung.

  • Das Clusterereignis MSExchangeRepl 2073 wird protokolliert und warnt, dass der Microsoft Exchange-Replikationsdienst ein angegebenes Verzeichnis nicht finden kann.

  • Move-ClusteredMailboxServer leitet aufgrund eines Replikationsproblems keine planmäßige Ausfallzeit ein.

  • Die Replikation wird nach dem Failover in einer oder mehreren Speichergruppen nicht erneut synchronisiert.

  • Fehler beim Seeding.

Wenn andere als die hier aufgelisteten Fehler auftreten, untersuchen Sie das Ereignisprotokoll auf beiden Knoten, um die Ursache zu bestimmen, und verwenden Sie die in den Protokollen enthaltenen Informationen, um zu bestimmen, welche Wiederherstellungsaktionen ergriffen werden müssen. Wenn Sie die Uhrzeit bestimmt haben, zu der der Fehler aufgetreten ist, können andere Ereignisprotokolle Sie beim besseren Verständnis des Problems unterstützen. Wenn diese Informationen unzureichend sind, kann die Uhrzeit des Auftretens des Problems verwendet werden, um Ihre Analyse und die Größe des Überprüfungsfensters in cluster.log einzuengen. Das Clusterprotokoll bietet für Aktionen, die vom Clusterverwaltungssystem ausgeführt werden, Informationen auf Ablaufverfolgungsebene.

Bevor Sie beginnen

Damit Sie das folgende Verfahren ausführen können, muss Folgendes an das verwendete Konto delegiert worden sein: die Exchange Server-Administrator-Rolle und die lokale Gruppe Administratoren für den Zielserver. Weitere Informationen zu Berechtigungen, zum Delegieren von Rollen und zu den Rechten, die für die Verwaltung von Microsoft Exchange Server 2007 erforderlich sind, finden Sie unter Überlegungen zu Berechtigungen.

Verfahren

"Get-StorageGroupCopyStatus" meldet, dass ein Fehler der Datenbank aufgetreten ist und kein Seeding ausgeführt wurde

  • Mögliche Ursachen   Ein Konfigurationsproblem, oder die Replikationskopie weist keine gültige Basisdatenbank auf. Dieses Problem kann durch ein nicht ausgeführtes Seeding beim Hinzufügen des passiven Knotens verursacht worden sein.

  • Lösung

    • Überprüfen Sie, ob der Informationsspeicher für die Kopie ordnungsgemäß konfiguriert und in Betrieb ist. Wenn Sie einen Fehler finden, können Sie eine erneute Überprüfung der Kopie auslösen, indem Sie die Speichergruppe anhalten und wieder aufnehmen.

    • Überprüfen Sie, ob die Speichergruppen- und Datenbankpfade relativ zum Informationsspeicher auf dem passiven Server ordnungsgemäß konfiguriert wurden. Sie können dies mithilfe des Cmdlets Get-StorageGroup in der Exchange-Verwaltungskonsole ausführen.

    • Verwenden Sie das Cmdlet Update-StorageGroupCopy, um ein Seeding der Speichergruppenkopie auszuführen.

"Get-StorageGroupCopyStatus" meldet, dass sich die Datenbank in einem Fehlerzustand befindet, und der FailedMessage-Wert zeigt an, dass eine Abweichung bei der Speichergruppenkopie aufgetreten ist

  • Mögliche Ursachen   Tritt bei einem Failover auf, wenn so viele Protokolle verloren wurden, dass die Datenbank auf dem zuvor aktiven Server nicht ohne ein vollständiges Seeding mit der aktuell aktiven Datenbank synchronisiert werden kann. Diese Situation kann in LCR nicht eintreten.

  • Lösung   Verwenden Sie das Cmdlet Update-StorageGroupCopy, um ein Seeding der Speichergruppenkopie auszuführen.

"Get-StorageGroupCopyStatus" meldet, dass sich die Datenbank in einem Fehlerzustand befindet, und der FailedMessage-Wert liefert detaillierte Informationen zur Fehlerquelle

  • Mögliche Ursachen   Eine Vielzahl möglicher Ursachen kann dazu führen, dass eine Speichergruppenkopie als fehlerhaft bestimmt wird. Die zwei vorangehenden Fälle, ein nicht ausgeführtes Seeding und eine Abweichung der Kopie, stellen zwei Beispiele dar. Der FailedMessage-Wert identifiziert das erkannte Problem spezifisch.

  • Lösung   Führen Sie das Cmdlet Get-StorageGroupCopyStatus aus, um den vollständigen FailedMessage-Wert abzurufen, wodurch das erkannte spezifische Problem identifiziert wird. Analysieren Sie die vom FailedMessage-Wert bereitstellten Informationen, und lösen Sie die gemeldete Bedingung. Wenn die gemeldete Bedingung in einem fehlerhaften oder fehlenden Protokoll besteht, versuchen Sie, ein nicht fehlerhaftes Protokoll mit der richtigen Generierungsnummer zu finden. Wenn das richtige Protokoll nicht gefunden werden kann, verwenden Sie das Cmdlet Update-StorageGroupCopy, um ein erneutes Seeding auszuführen. Wenn die Nachricht impliziert, dass die Protokolle auf der Quelle nicht verfügbar sind, entfernen Sie die Freigabe für das Protokollverzeichnis auf der Quelle, und starten Sie den Replikationsdienst auf dem betreffenden Knoten erneut.

Warnungen, Leistungsindikatoren oder "Get-StorageGroupCopyStatus" zeigen an, dass Kopie- oder Wiedergabewarteschlangen für eine Speichergruppenkopie gesichert werden.

  • Mögliche Ursachen   Ein Rückstandsprotokoll der Protokollkopie oder -wiedergabe kann anzeigen, dass entweder ein Problem oder eine vorübergehende Situation in einem Wiederherstellungsvorgang besteht. Eine vorübergehende Situation tritt ein, wenn ein zuvor offline geschalteter passiver Knoten online geschaltet wird oder eine Speichergruppenkopie vor Kurzem wieder aufgenommen wurde, nachdem sie für einen erheblichen Zeitraum angehalten worden war. Das Beenden des Microsoft Exchange-Replikationsdiensts auf dem passiven Knoten hat eine ähnliche Wirkung wie das Anhalten aller Speichergruppenkopien auf dem Knoten. Wenn die Situation nicht vorübergehend ist, kann sie durch eine der folgenden Bedingungen verursacht sein:

    • Konfigurationsproblem.

    • Angehaltene Speicherkopie.

    • Der Wiedergabedienst ist beendet.

    • Speicherfehler oder Offlinestatus.

    • Der passive Knoten ist offline.

  • Lösung   Bestimmen Sie, ob es sich um ein wirkliches Problem oder um eine vorübergehende Situation handelt:

    • Bestimmen Sie, ob der Microsoft Exchange-Replikationsdienst auf beiden Knoten ausgeführt wird. Dies kann mithilfe des des Snap-Ins Dienste durchgeführt werden. Wenn der Dienst auf einem der Knoten beendet wurde, müssen Sie ihn starten.

    • Führen Sie das Cmdlet der Exchange-Verwaltungsshell Get-StorageGroupCopyStatus mit der Option fl (formatierte Liste) aus, und bestimmen Sie, ob die passive Kopie angehalten ist. Wenn sie angehalten ist, überprüfen Sie, ob die Dateien der passiven Kopie ordnungsgemäß vorhanden sind, und nehmen Sie dann die Speichergruppenkopie mithilfe des Cmdlets Resume-StorageGroupCopy wieder auf.

    • Führen Sie das Cmdlet Get-StorageGroupCopyStatus mit der Option fl aus, und bestimmen Sie, ob die Kopie Fehlerfrei ist. Wenn die Kopie einen Fehlerzustand aufweist, überprüfen Sie die Liste der Statusfelder, um die erforderliche Korrekturaktion zu ermitteln.

    • Beobachten Sie die Replikationsleistungsindikatoren über einen Zeitraum von mehreren Minuten, um festzustellen, ob der Vorgang fortschreitet. Achten Sie insbesondere auf die Wiedergabegenerierungsnummer und die Inspektionsgenerierungsnummer. Wenn die Länge der Kopiewarteschlange zunimmt, die Länge der Wiedergabewarteschlange jedoch kurz oder abnehmend ist, liegt möglicherweise ein Problem mit der Netzwerkdateifreigabe auf dem aktiven Server oder mit dem aktiven Server selbst vor. Vergewissern Sie sich mithilfe des Befehls "net share", mit Windows-Explorer oder mithilfe des Snap-Ins "Computerverwaltung", dass für das Protokollverzeichnis der Kopie der aktiven Speichergruppe eine Netzwerkfreigabe definiert wurde. Sie können die GUID der Speichergruppe mithilfe des Cmdlets Get-StorageGroup und der Option fl in der Exchange-Verwaltungsshell bestimmen.

"Get-StorageGroupCopyStatus" meldet eine alte Zeitangabe für "LastInspectedLogTime"

  • Mögliche Ursachen   Für dieses Problem kommen drei mögliche Ursachen in Frage:

    • Die Bereitstellung der Datenbank der aktiven Speichergruppenkopie ist aufgehoben.

    • Die aktive Speichergruppenkopie ist bereitgestellt, verändert sich jedoch nicht in einem befriedigenden Tempo. Daher werden von der aktiven Speichergruppenkopie keine Protokolle erstellt.

    • Der Microsoft Exchange-Replikationsdienst wird auf dem passiven Knoten nicht ausgeführt.

  • Lösung   Bestimmen Sie, welche der drei Ursachen vorliegt, indem Sie wie folgt vorgehen:

    • Bestimmen Sie mithilfe der Exchange-Verwaltungskonsole oder durch Ausführen des Cmdlets Get-StorageGroupStatus in der Exchange-Verwaltungsshell, ob die Bereitstellung der Datenbank aufgehoben ist. Wenn die Bereitstellung aufgehoben ist, müssen Sie die Datenbank bereitstellen, und Änderungen an der Datenbank (z. B. Aktivitäten in der Datenbank) müssen vorgenommen werden, bevor sich LastInspectedLogTime ändert.

    • Vergewissern Sie sich, dass der Microsoft Exchange-Replikationsdienst auf dem passiven Knoten ausgeführt wird. Wenn der Dienst beendet wurde, müssen Sie ihn starten.

    • Überprüfen Sie, ob die Datenbank Protokolle generiert, nachdem Sie sichergestellt haben, dass die Datenbank bereitgestellt ist. Sehen Sie im Protokollverzeichnis der aktiven Datenbank nach, und identifizieren Sie die Protokolldatei mit der höchsten Generierungsnummer. Überprüfen Sie den Zeitstempel für dieses Protokoll. Er sollte dem Wert in LastInspectedLogTime entsprechen.

Erfolg bei Failover oder "Move-ClusteredMailboxServer", die Datenbanken werden jedoch nicht bereitgestellt

  • Mögliche Ursachen   Die normale Ursache dieses Problems besteht darin, dass der Clusterdienst nicht ausreichend autorisiert ist, um die Datenbank bereitzustellen. Alternativ hat der Failover zu mehr verlorenen Protokollen geführt, als von den Konfigurationseinstellungen der automatischen Bereitstellung zugelassen wird. Die andere typische Ursache bei einem Failover besteht darin, dass die passiven Kopien zum Zeitpunkt des Ausfalls nicht fehlerfrei waren.

  • Lösung   Berechtigungsprobleme beim Clusterdienstkonto treten normalerweise bei der Installation auf. Wenn die Datenbanken beim Ende der Installation nicht bereitgestellt werden, zeigt dies normalerweise an, dass dem Clusterdienstkonto nicht die entsprechenden Berechtigungen erteilt wurden. Um dieses Problem zu beheben, erteilen Sie dem Clusterdienstkonto die erforderlichen Berechtigungen, fahren Sie den gesamten Cluster dann ordnungsgemäß herunter, und starten Sie ihn neu. Sie können zu diesem Zweck (1) den Postfachclusterserver offline schalten, (2) den passiven Knoten herunterfahren, (3) den aktiven Knoten herunterfahren, (4) den aktiven Knoten starten, (5) den passiven Knoten starten und (6) den Postfachclusterserver online schalten.

    • Überprüfen Sie das Ereignisprotokoll, um zu bestimmen, ob beim Failover mehr Protokolle verloren wurden, als von den Konfigurationseinstellungen der automatischen Bereitstellung zugelassen wird. Nachdem Sie den Status der Datenbank der Speichergruppenkopie bestimmt haben, können Sie sie explizit bereitstellen, indem Sie das Cmdlet Restore-StorageGroupCopy in der Exchange-Verwaltungsshell ausführen. Führen Sie schließlich das Cmdlet Get-StorageGroupCopy aus, und überprüfen Sie den Wert von SummaryCopyStatus, um zu identifizieren, ob Probleme bei der zuvor aktiven Kopie vorliegen, die ihre Bereitstellung verhindern. Wenn Probleme bestehen, überprüfen Sie das Ereignisprotokoll, um die Ursache der Probleme zu identifizieren, und führen Sie anschließend Schritte zum Beheben des Problems aus.

Erfolg bei Failover, doch einige Datenbanken werden nicht automatisch oder manuell bereitgestellt. Alternativ meldet "Get-ClusteredMailboxServerStatus" Fehler bei mindestens einer Datenbank

  • Mögliche Ursachen   Ein kürzlich erfolgter Failover hat zu mehr verlorenen Protokollen geführt, als von den Konfigurationseinstellungen der automatischen Bereitstellung zugelassen wird. Die andere typische Ursache bei einem Failover besteht darin, dass die passive Kopie zum Zeitpunkt des Ausfalls nicht fehlerfrei war.

    Hinweis

    Datenbanken können für einen kurzen Zeitraum aufgrund eines planmäßigen oder unplanmäßigen Ausfalls als fehlerhaft oder offline markiert sein. Dieser Status ist vorübergehend, und er tritt auf, während der Replikationsdienst versucht, eine endgültige Kopie aller verfügbaren Protokolle zu erstellen.

  • Lösung   Überprüfen Sie das Ereignisprotokoll, um zu bestimmen, warum ein Fehler beim Bereitstellen der Datenbank aufgetreten ist. Möglicherweise tritt ein Fehler beim Bereitstellen der Datenbank aufgrund von Beschädigung der Protokoll- oder Datenbankdateien auf. Wenn die Ereignisse darauf hinweisen, stellen Sie den Zugriff auf die Datenbank wieder her, indem Sie den aktiven Server auf den anderen Knoten verschieben. Sie können bestimmen, ob bei der Datenbank ein Fehler vorliegt, indem Sie das Ereignisprotokoll überprüfen. Nachdem Sie den Status der Datenbank der Speichergruppenkopie bestimmt haben, können Sie sie explizit bereitstellen, indem Sie das Cmdlet Restore-StorageGroupCopy in der Exchange-Verwaltungsshell ausführen. Führen Sie schließlich das Cmdlet Get-StorageGroupCopyStatus aus, und überprüfen Sie den Wert von SummaryCopyStatus, um zu identifizieren, ob Probleme bei der zuvor aktiven Kopie vorliegen, die ihre Bereitstellung verhindern. Wenn der Status anzeigt, dass die Speichergruppenkopie zu alt ist, um aktiviert zu werden, kann die Datenbank wiederhergestellt werden, wenn der fehlerhafte Knoten wieder zum Betrieb zurückkehrt und mehr Protokolle verfügbar sind. Die Protokolle werden automatisch kopiert, und Sie müssen keine Aktion ausführen.

Fehler beim Bereitstellen einer Datenbank beim Starten in einer CCR-Umgebung

  • Mögliche Ursachen   Der Fehler beim Bereitstellen der Datenbank kann das Ergebnis einer expliziten Administratoraktion sein. Wenn die Bereitstellung einer Datenbank explizit aufgehoben wird und der Postfachclusterserver anschließend offline geschaltet wird, wird die Datenbank beim nächsten Starten nicht online geschaltet. Eine weitere mögliche Ursache besteht darin, dass die zugelassene Protokollanzahl bei einem Failover verloren wurde.

  • Lösung   Sie können das Cmdlet Get-ClusteredMailboxServerStatus in der Exchange-Verwaltungsshell ausführen, um zu überprüfen, ob der Informationsspeicher auf dem Knoten in Betrieb ist. Verwenden Sie die Exchange-Verwaltungskonsole oder die Exchange-Verwaltungsshell, um einen Bereitstellungsvorgang der betroffenen Datenbankkopie zu versuchen. Weitere Informationen zum Bereitstellen der Datenbankkopie finden Sie unter Bereitstellen einer Datenbank in einer Umgebung mit fortlaufender Clusterreplikation. Überprüfen Sie nach dem Bereitstellungsvorgang das Ereignisprotokoll, um zu bestimmen, ob Fehler gemeldet wurden.

Das Clusterereignis MSExchangeRepl 2073 wird protokolliert und warnt, dass der Microsoft Exchange-Replikationsdienst ein angegebenes Verzeichnis nicht finden kann

  • Mögliche Ursachen   Das Fehlerereignis zeigt an, dass der Microsoft Exchange-Replikationsdienst das Verzeichnis nicht erstellen konnte, das durch das Ereignis angegeben wird. Der Microsoft Exchange-Replikationsdienst versucht, mehrere erforderliche Verzeichnisse zu erstellen, wenn diese nicht bereits vorhanden sind. Dabei handelt es sich z. B. um Verzeichnispfade für Quellprotokolldateien, Zielprotokolldateien, Zielsystemdateien und den Pfad für die Protokolldateiüberwachung.

    Der Microsoft Exchange-Replikationsdienst ist ggf. nicht in der Lage, das angegebene Verzeichnis zu erstellen, weil ein Berechtigungsproblem besteht bzw. ein Hardware- oder ein Konfigurationsfehler aufgetreten ist.

  • Lösung   Untersuchen Sie den vom Ereignis zurückgegebenen Fehlercode. Stellen Sie sicher, dass der Verzeichnispfad verfügbar und der Zugriff darauf möglich ist. Überprüfen Sie die Dateisystemberechtigungen. Vergewissern Sie sich, dass der Speicher richtig konfiguriert ist und die Hardware ordnungsgemäß funktioniert.

"Move-ClusteredMailboxServer" leitet aufgrund eines Replikationsproblems keine planmäßige Ausfallzeit ein

  • Mögliche Ursachen   Das Cmdlet Move-ClusteredMailboxServer der Exchange-Verwaltungsshell schließt Gültigkeitsprüfungen ein, um eine geplante Ausfallzeit auf einem passiven Knoten zu verhindern, wenn die Replikation nicht auf allen Speichergruppenkopien vollständig fehlerfrei ist. Dieses Verhalten stellt sicher, dass geplante Ausfallzeiten nicht unangemessen lange ausgedehnt werden.

  • Lösung   Identifizieren Sie die spezifischen Speichergruppen, bei denen das Problem besteht, und beheben Sie alle Probleme. Die Fehlermeldung des Cmdlets Move-ClusteredMailboxServer identifiziert die problematische Speichergruppenkopie. Wenn Sie die Verschiebung ausführen und die Gültigkeitsprüfung ignorieren möchten, stellen Sie sicher, dass nur die Bereitstellung der Datenbank der fehlerhaften Speichergruppenkopie aufgehoben ist. Versuchen Sie den Verschiebevorgang erneut, und verwenden Sie den Parameter -IgnoreDismounted. Der Parameter IgnoreDismounted zeigt an, dass Speichergruppen mit aufgehobener Bereitstellung bei der Replikationsstatusüberprüfung ignoriert werden sollen.

Die Replikation wird nach dem Failover in einer oder mehreren Speichergruppen nicht erneut synchronisiert

  • Mögliche Ursachen   Die vom Cmdlet Get-StorageGroupCopyStatus zurückgegebene Fehlermeldung zeigt an, dass eine Abweichung bei der Datenbank vorliegt. Diese Situation beruht auf einem Failover, wenn der alte aktive Server vor dem Failover nicht genügend Protokolle repliziert hatte.

  • Lösung   Führen Sie ein erneutes Seeding der Datenbank mithilfe des Cmdlets Update-StorageGroupCopy in der Exchange-Verwaltungsshell aus.

Fehler beim Seeding

  • Mögliche Ursachen   Auf dem aktiven Server wird aktuell eine Sicherung ausgeführt, oder es liegt ein Verbindungsproblem vor.

  • Lösung   Überprüfen Sie, ob aktuell keine Sicherung der betroffenen Speichergruppenkopie oder Datenbank ausgeführt wird. Stellen Sie sicher, dass der aktive Knoten online ist.

Weitere Informationen

Weitere Informationen zu den in diesem Thema genannten Cmdlets der Exchange-Verwaltungsshell finden Sie unter den folgenden Themen:

Weitere Informationen zur Problembehandlung der fortlaufenden lokalen Replikation (Local Continuous Replikation, LCR) finden Sie unter Problembehandlung von Problemen der fortlaufenden lokalen Replikation.