Verwalten der fortlaufenden Clusterreplikation
Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Letztes Änderungsdatum des Themas: 2009-06-10
Zusätzlich zu den Aufgaben im Rahmen der alltäglichen Verwaltung und Administration einer Exchange-Organisation gibt es spezielle Aufgaben für die Verwaltung der Umgebung mit fortlaufender Clusterreplikation (Cluster Continuous Replication, CCR). Im Allgemeinen lassen sich die CCR-Verwaltungsaufgaben in zwei Kategorien unterteilen:
Aufgaben im Zusammenhang mit einem Postfachclusterserver
Aufgaben im Zusammenhang mit Speichergruppen und Datenbanken in einem Postfachclusterserver
Aufgaben im Zusammenhang mit einem Postfachclusterserver
Die administrativen Aufgaben im Zusammenhang mit einem Postfachclusterserver in einer CCR-Umgebung umfassen Folgendes:
Verwalten von Datenträgervolumes.
Anzeigen von Konfigurationseinstellungen.
Überwachen der Replikationsaktivität.
Anzeigen und Erfassen von Leistungsdaten.
Verwalten von Postfachclusterservern. Hierzu zählt das Onlineschalten der Server, das Offlineschalten der Server und das Verschieben von Postfachclusterservern zwischen Knoten.
Verwalten der Replikation und der Wiedergabe von Protokolldateien.
Verwalten von Datenträgervolumes
Bei der Verwaltung einer CCR-Umgebung ist es möglicherweise erforderlich, Datenträgervolumes zu verwalten, die dem CCR-Cluster zugeordnet sind. Das Datenträgervolume muss z. B. zu Wartungszwecken oder aus anderen Gründen vorübergehend vom System getrennt werden. Wenn dies bei der aktiven Speichergruppe oder Datenbank erforderlich wird, sollte die Bereitstellung der Datenbanken in der Speichergruppe aufgehoben werden. Wenn ein solcher Vorgang für die passive Kopie der Speichergruppe oder Datenbank ausgeführt werden soll, müssen alle replikationsbezogenen E/A-Vorgänge (Eingabe/Ausgabe) auf dem Volume durch Anhalten der Replikation beendet werden.
Weitere Informationen zum Verwalten von Datenträgervolumes finden Sie unter Vorbereiten von Datenträgervolume-Verwaltungsaktivitäten für eine CCR-Kopie.
Anzeigen von Konfigurationseinstellungen
Nachdem die fortlaufende Clusterreplikation für einen Server aktiviert wurde, können die Konfigurationseinstellungen für Speichergruppen und Datenbanken auf dem Server mithilfe der Exchange-Verwaltungskonsole und der Exchange-Verwaltungsshell angezeigt werden.
Die Konfigurationsinformationen beinhalten die Speicherorte für die Speichergruppen- und Datenbankdateien. Darüber hinaus können Sie mithilfe der Exchange-Verwaltungsshell die Konfiguration im Zusammenhang mit Postfachclusterservern prüfen.
Ausführliche Anweisungen zum Anzeigen von CCR-Failover-Steuerungsinformationen finden Sie unter Anzeigen der Failover-Steuerungskonfiguration.
Überwachen der Replikationsaktivität
Die passive Kopie einer Datenbank ist nur von Nutzen, wenn sie aktuell ist. Zwar erfordert CCR 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 CCR-Umgebungen auftreten können:
Der Microsoft Exchange-Replikationsdienst wird auf dem passiven Knoten nicht ausgeführt. Das Ereignis, das diese Warnung generiert, wird nach dem Beenden des Diensts nicht wiederholt angezeigt. Daher gehen alle mit ihm verbundenen Warnungen verloren, wenn es gelöscht wird.
Die passive Kopie besitzt den Status "Fehler".
Die passive Kopie befindet sich in einem ordnungsgemäßen Zustand, ist jedoch beim Kopier- oder Wiedergabevorgang des Protokolls in erheblichem Rückstand.
Es wird außerdem empfohlen, Microsoft Operations Manager eine benutzerdefinierte Ereignisregel hinzuzufügen, die ausgelöst wird, wenn erkannt wird, dass ein passiver Knoten nicht ausgeführt wird und Teil des Clusters ist, der einen aktiven Knoten enthält. Wenn diese Bedingung eintritt, protokolliert der Clusterdienst ein Ereignis im Systemereignisprotokoll. Es wird empfohlen, die folgenden Kriterien für die Ereignisregel zu verwenden, die Teil des durch den Clusterdienst protokollierten Ereignisses sind:
Ereignisquelle: ClusSvc
Ereignis-ID: 1135
Weitere Informationen zum Erstellen von Ereignisregeln im Microsoft Operations Manager finden Sie unter Überwachen von Sicherheitsereignissen mit MOM.
Sie sollten alle vorherigen Warnungen, die von Exchange 2007 Management Pack oder einer benutzerdefinierten Ereignisregel generiert wurden, schnellstmöglich untersuchen und beheben.
Eine Alternative zum Verwenden des Exchange 2007 Management Packs für Microsoft Operations Manager 2005 besteht im regelmäßigen Ausführen eines Skripts, das das Cmdlet Get-StorageGroupCopyStatus in der Exchange-Verwaltungsshell ausführt. Das Cmdlet Get-StorageGroupCopyStatus gibt Warteschlangenlängen zurück, die die Anzahl der vom aktiven Knoten generierten Protokolle berücksichtigen. Aus Leistungsgründen enthalten die Leistungsindikatoren für die Warteschlangenlänge nur Informationen, die dem Microsoft Exchange-Replikationsdienst bekannt sind. Unter seltenen Umständen können diese Angaben inkonsistent mit dem Status des aktiven Knotens sein. Weitere Informationen zum Cmdlet Get-StorageGroupCopyStatus finden Sie unter "Anzeigen des Status von Speichergruppenkopien" weiter unten in diesem Thema.
Anzeigen und Erfassen von Leistungsdaten
Mithilfe von Leistungsindikatoren können Sie den Status der Replikation ermitteln. Weitere Informationen zur Verwendung von Leistungsindikatoren für die fortlaufenden Clusterreplikation finden Sie unter Anzeigen der Leistungsindikatoren für die fortlaufende Clusterreplikation.
Verwalten von Postfachclusterservern
Zu den drei administrativen Hauptaufgaben beim Verwalten eines Postfachclusterservers gehören das Onlineschalten eines Postfachclusterservers, das Offlineschalten des Servers und das Verschieben eines Postfachclusterservers zwischen Knoten im Cluster. Dieser Vorgang kann auch das Herunterfahren oder den Neustart eines der Knoten im Cluster als Teil der Updateverwaltung oder andere Wartungsaufgaben beinhalten.
Starten und Beenden eines Postfachclusterservers
Mit dem Tool zur Failoverclusterverwaltung (Windows Server 2008), Cluster Administrator (Windows Server 2003) und dem Befehlszeilentool Cluster.exe (in beiden Betriebssystemen) können Ressourcen online bzw. offline geschaltet werden. Wenn Sie einen Postfachclusterserver offline schalten, wird dieser beendet, wenn Sie einen Postfachclusterserver online schalten, wird er gestartet. Das empfohlene Verfahren zum Starten eines Postfachclusterservers besteht im Verwenden des Cmdlets Start-ClusteredMailboxServer. Das empfohlene Verfahren zum Beenden eines Postfachclusterservers besteht im Verwenden des Cmdlets Stop-ClusteredMailboxServer. In Exchange 2007 Service Pack 1 (SP1) kann auch der Assistenten zum Verwalten von Postfachclusterservern in der Exchange-Verwaltungskonsole zum Starten oder Beenden eines Postfachclusterservers verwendet werden.
Ausführliche Anweisungen zum Onlineschalten eines Postfachclusterservers finden Sie unter Starten eines Postfachclusterservers. Ausführliche Anweisungen zum Offlineschalten eines Postfachclusterservers finden Sie unter Beenden eines Postfachclusterservers.
Verschieben eines Postfachclusterservers zwischen Knoten
Das manuelle Verschieben eines Postfachclusterservers zwischen Knoten wird als Übergabe (Handoff) oder geplanter Ausfall bezeichnet. Zum Verschieben eines Postfachclusterservers verwenden Sie das Cmdlet Move-ClusteredMailboxServer. In Exchange 2007 SP1 steht Ihnen außerdem der Assistent zum Verwalten von Postfachclusterservern in der Exchange-Verwaltungskonsole zum Übergeben eines Postfachclusterservers zur Verfügung. Zwar können Sie das Tool zur Failoverclusterverwaltung (Windows Server 2008), Cluster Administrator (Windows Server 2003) und das Befehlszeilentool Cluster.exe (in beiden Betriebssystemen) zum Verschieben eines Postfachclusterservers zwischen Knoten verwenden, es wird jedoch empfohlen, eines der Exchange-Verwaltungstools zum Verschieben eines Postfachclusterservers vom aktiven Knoten auf den passiven Knoten zu verwenden, weil diese Tools eine Angabe des Grunds für die Übergabe ermöglichen. Darüber hinaus gilt Folgendes:
Wenn Sie die Clustertools verwenden, wird die Überprüfung des Zustands oder Status der passiven Kopie übersprungen, die von den Exchange-Verwaltungstools durchgeführt wird. Ihre Verwendung kann also zu einem umfangreichen Ausfall führen, während der Knoten die notwendigen Vorgänge ausführt, um die Bereitstellung der Datenbank zu ermöglichen.
Wenn Sie die Clustertools verwenden, kann eine Datenbank außerdem auf unbestimmte Zeit offline bleiben, weil die Replikation nicht ordnungsgemäß funktioniert. Die Clustertools sind im Gegensatz zu den Exchange-Verwaltungstools nicht in der Lage, den Status der Replikation zu bestimmen, bevor die Ressourcengruppe verschoben wird.
Hinweis
Das Verschieben eines Postfachclusterservers zwischen Knoten führt zu einer kurzen Unterbrechung des Betriebs. Darüber hinaus werden alle Sicherungen von Speichergruppen auf dem Postfachclusterserver abgebrochen.
Wenn die Replikation nicht ordnungsgemäß stattfindet oder durch diese Überprüfungen festgestellt wird, dass sich der passive Knoten nicht in einem akzeptablen Zustand für eine Übergabe befindet, führen die Exchange-Verwaltungstools die Übergabe nicht durch. Wenn dies der Fall, und Sie müssen den Postfachclusterserver dennoch auf den passiven Knoten verschieben, können Sie zu diesem Zweck die Clusterverwaltungstools verwenden.
Beim Verschieben eines Postfachclusterserver in ein Failovercluster mit Netzwerkwartezeit zwischen den Knoten, sollten Sie für das Verschieben den passiven Knoten verwenden.
Ausführliche Anweisungen zum Verschieben eines Postfachclusterservers zwischen Knoten finden Sie unter Verschieben eines Postfachclusterservers in einer CCR-Umgebung.
Ausführen des Wartungsprozesses auf dem Cluster
Die Wartung sollte immer auf dem passiven Knoten im Cluster erfolgen. Updates, Hotfixes und andere Anwendungen sollten generell nicht auf dem aktiven Knoten (einem Knoten, der aktuell Besitzer eines Postfachclusterservers ist) installiert werden. Ausführliche Anleitungen zum Installieren von Exchange-Updaterollups in einer CCR-Umgebung finden Sie unter Anwenden von Exchange 2007-Updaterollups auf Postfachclusterserver.
Wenn Wartungsarbeiten auf dem aktiven Knoten ausgeführt werden müssen, muss der Postfachclusterserver zuerst mithilfe des Cmdlets Move-ClusteredMailboxServer auf einen passiven Knoten verschoben werden. Nachdem der Postfachclusterserver verschoben wurde, wird der zuvor aktive Knoten zum passiven Knoten, und der zuvor passive Knoten ist nun der aktive Knoten. Anschließend kann die Wartung durchgeführt und eine Übergabe vorgenommen werden, die den Postfachclusterserver in die Gegenrichtung verschiebt.
In CCR-Umgebungen können Sie einen Systemausfall eines bestimmten Knotens ohne einen Ausfall des Postfachclusterservers planen. In einer CCR-Lösung kann jeweils nur ein Knoten im Offlinemodus ausgeführt werden. Wird mehr als ein Knoten in den Offlinestatus versetzt, führt dies zur einer Dienstunterbrechung.
Ein geplanter Ausfall wird über das Cmdlet Move-ClusteredMailboxServer der Exchange-Verwaltungsshell initiiert. Unter dem Thema Verschieben eines Postfachclusterservers in einer CCR-Umgebung finden Sie ein Verfahren zur Durchführung eines geplanten Ausfalls.
Überprüfen Sie vor dem Beenden oder Neustarten eines beliebigen Knotens in einer CCR-Umgebung, welcher Knoten den Postfachclusterserver aktuell hostet. Die entsprechenden Informationen können mit dem Cmdlet Get-ClusteredMailboxServerStatus abgerufen werden.
Ausführen des Wartungsprozesses auf dem Cluster
Die Wartung sollte immer auf dem passiven Knoten im Cluster erfolgen. Updates, Hotfixes und andere Anwendungen sollten generell nicht auf dem aktiven Knoten (dem Knoten, der aktuell Besitzer des Postfachclusterservers ist) installiert werden. Ausführliche Anleitungen zum Installieren von Exchange-Updaterollups in einer CCR-Umgebung finden Sie unter Anwenden von Exchange 2007-Updaterollups auf Postfachclusterserver.
Wenn Wartungsarbeiten auf dem aktiven Knoten ausgeführt werden müssen, muss der Postfachclusterserver zuerst mithilfe des Cmdlets Move-ClusteredMailboxServer auf den passiven Knoten verschoben werden. Nachdem der Postfachclusterserver verschoben wurde, wird der zuvor aktive Knoten zum passiven Knoten, und der zuvor passive Knoten ist nun der aktive Knoten. Anschließend kann die Wartung durchgeführt und eine Übergabe vorgenommen werden, die den Postfachclusterserver in die Gegenrichtung verschiebt.
Herunterfahren von Knoten im Cluster
Wenn alle Knoten im Cluster einschließlich des aktiven Knotens heruntergefahren werden müssen, müssen Sie den Postfachclusterserver zuerst beenden. Der Windows-Shutdownprozess ist nicht Exchange-gestützt. Aus diesem Grund wird empfohlen, nur die passiven Knoten herunterzufahren. Wenn ein aktiver Knoten heruntergefahren oder neu gestartet werden muss, wird empfohlen, den Postfachclusterserver auf einen anderen verfügbaren Knoten zu verschieben. Ausführliche Informationen zum Verschieben eines Postfachclusterservers auf einen anderen Knoten finden Sie unter Verschieben eines Postfachclusterservers in einer CCR-Umgebung.
Wenn der Postfachclusterserver nicht auf den passiven Knoten verschoben werden kann (beispielsweise, weil der passive Knoten bereits heruntergefahren wurde), muss er angehalten werden, bevor der aktive Knoten heruntergefahren werden kann.
Wenn Sie den aktiven Knoten neu starten oder herunterfahren möchten und der Postfachclusterserver nicht auf den passiven Knoten verschoben werden kann, wird empfohlen, die Gruppenrichtlinie zu verwenden, damit sichergestellt wird, dass der Postfachclusterserver beendet wird, bevor ein aktiver Knoten neu gestartet oder heruntergefahren wird. Windows Server stellt eine Sammlung richtliniengesteuerter Skripts für das Herunterfahren von Computern zur Verfügung, die Sie mithilfe des Gruppenrichtlinien-Snap-Ins verwalten können. Das Gruppenrichtlinien-Snap-In umfasst Erweiterungen, die das Angeben eines Skripts ermöglichen, das beim Herunterfahren des Computers ausgeführt wird.
Sie können z. B. ein Skript zum Herunterfahren erstellen, das das Cmdlet Move-ClusteredMailboxServer oder das Cmdlet Stop-ClusteredMailboxServer mit den entsprechenden Parametern ausführt. Die Verwendung eines Skripts zum Herunterfahren wird außerdem empfohlen, da dies die Gefahr verringert, dass ein Administrator das System herunterfährt oder neu startet, weil er sich nicht bewusst ist, dass der Postfachclusterserver vor dem Herunterfahren des aktiven Knotens verschoben und beendet werden muss.
Wichtig
Diese Skripts werden unter dem lokalen Systemkonto ausgeführt. Bevor diese Skripts erfolgreich ausgeführt werden können, müssen Sie dem lokalen Systemkonto (dem Computerkonto des lokalen Knotens) die Berechtigung zum Verwalten des Postfachclusterservers erteilen.
Verwalten der Replikation und der Wiedergabe von Protokolldateien
Das Verwalten der Replikation in einer CCR-Umgebung umfasst die folgenden Hauptaktivitäten:
Behandeln von Failovervorgängen, wenn die Replikation angehalten wurde
Anhalten und Neustarten der Replikation in Speichergruppenkopien
Konfigurieren mindestens eines redundanten Netzwerks für die Replikation
Behandeln von Failovervorgängen, wenn die Replikation angehalten wurde
Wird die Replikation beendet, werden für den Zeitraum der Unterbrechung keine Änderungen von der aktiven Speichergruppe an die Kopie übermittelt. Erfolgt in dieser Zeit ein Failover, verfügt die Speichergruppenkopie nicht über die letzten Änderungen. Abhängig von der Menge der am aktiven Knoten durchgeführten Änderungen ist es wahrscheinlich, dass das System aufgrund der fehlenden letzten Änderungen daran gehindert wird, die Kopie auf dem passiven Computer bereitzustellen. Sie können dann entweder die verfügbare Version der Speichergruppe auf dem passiven Knoten verwenden oder warten, bis der ursprüngliche Server wiederhergestellt ist. Die Replikation sollte daher nur möglichst kurz angehalten werden, um dieses Risiko zu minimieren.
Wenn Sie nicht die Version der Daten auf dem passiven Knoten bereitstellen, kopiert das Replikationssystem die fehlenden Protokolle, sobald der ursprüngliche Computer wieder verfügbar ist, und stellt die Kopie der Datenbank automatisch auf dem neuen aktiven Knoten bereit.
Ein Failover nach der Wiederaufnahme der Replikation kann erfolgen, bevor die passive Kopie über alle Protokolle verfügt oder nachdem alle Protokolle verfügbar sind, in diesem Fall jedoch vor der Wiedergabe dieser Protokolle. Werden die Protokolle kopiert aber nicht wiedergegeben, löst ein Failover die Wiedergabe der ausstehenden Protokolle in die Datenbank aus. Für diese Speichergruppe fällt daher eine längere Wiederherstellungszeit beim Failover an; andere Speichergruppen sind davon jedoch nicht betroffen. Wenn jedoch ausreichend Protokolle verfügbar sind, um die konfigurierten automatischen Bereitstellungskriterien zu erfüllen, stellt das System die Datenbank schließlich mit den neuesten verfügbaren Daten bereit. Bei diesem Verfahren besteht jedoch ein Risiko: Es kann vorkommen, dass eines der wiederzugebenden Protokolle beschädigt ist und keine erfolgreiche Wiedergabe möglich ist. In diesem Fall resultiert die Wiedergabe in einem Fehler, und die weitere Wiedergabeaktivität wird blockiert. Wenn dies geschieht, wechselt die Speichergruppenkopie in einen Fehlerzustand. In diesem Fehlerzustand können Sie die Version der Datenbank möglicherweise bis zu diesem Punkt wiederherstellen. Andernfalls müssen Sie warten, bis der ursprüngliche Server wieder verfügbar ist und das nicht beschädigte Protokoll erneut kopiert wurde.
Anhalten und Neustarten der Replikation in Speichergruppenkopien
Gelegentlich kann es erforderlich sein, die Aktivitäten der passiven Kopie zu steuern. Es kann notwendig sein, die Replikationsaktivitäten anzuhalten und erneut zu starten. Die Replikation wird auf Speichergruppenebene gesteuert. Da eine Speichergruppe nur eine Datenbank enthalten kann, ist die Replikation auf eine Datenbank begrenzt.
Die Replikation erfolgt, wenn beide Knoten im Cluster in Betrieb sind, der Microsoft Exchange-Replikationsdienst auf dem Zielknoten ausgeführt wird und das Kopieren für die Speichergruppenkopie aktiviert ist. Wenn der Quell- oder Zielspeicherort für die fortlaufende Clusterreplikation nicht mehr verfügbar ist, müssen Sie die Replikation beenden. Für einige CCR-Verwaltungsaufgaben, z. B. Seeding, das Ausführen von Integritätsprüfungen oder die Speicherneukonfiguration, ist es zudem erforderlich, die Replikation für eine Speichergruppenkopie anzuhalten. Wenn es erforderlich ist, den gesamten Zugriff auf die Protokolldateien und das Protokollverzeichnis des Ziels zu beenden, müssen Sie die Replikation anhalten.
In Exchange 2007 ist es erforderlich, alle Replikationsaktivitäten anzuhalten, wenn der Speicherort der Speichergruppe oder Datenbank geändert wird.
Weitere Informationen zum Anhalten von Datenbankkopieaktualisierungen finden Sie unter Anhalten der Replikation auf einer einer fortlaufenden Clusterreplikationskopie. Weitere Informationen zum Neustarten von Datenbankkopieaktualisierungen finden Sie unter Neustart der Replikation in einer fortlaufenden Clusterreplikationskopie.
Weitere Informationen zum Ausführen einer Integritätsüberprüfung bei CCR-Transaktionsprotokollen und -Datenbankdateien finden Sie unter Überprüfen einer Kopie der fortlaufenden Clusterreplikation mithilfe von ESEUTIL.
Konfigurieren mindestens eines redundanten Netzwerks für die Replikation
Exchange 2007 SP1 ermöglicht die Konfiguration redundanter Clusternetzwerke, die für den Protokollversand und das Seeding in einer CCR-Umgebung verwendet werden können. Das redundante Netzwerk muss als gemischtes Clusternetzwerk konfiguriert werden. Bei einem gemischten Clusternetzwerk handelt es sich um ein beliebiges Clusternetzwerk, das sowohl für Cluster- (Taktintervall) als auch für Clientzugriffsverkehr konfiguriert ist.
Wenn ein gemischtes Clusternetzwerk mit Hostnamen und IP-Adressen für die fortlaufende Replikation konfiguriert wurde, verwendet Exchange 2007 dieses Netzwerk für den Protokollversand. Darüber hinaus steht das konfigurierte Netzwerk für vom Administrator initiiertes Seeding mit dem Cmdlet Update-StorageGroupCopy zur Verfügung. Es können mehrere gemischte Netzwerke festgelegt werden. Sind mehrere Netzwerke verfügbar, trifft Exchange 2007 eine Zufallsauswahl unter den Netzwerken. Steht das aktuell verwendete Netzwerk nicht mehr zur Verfügung, wählt Exchange 2007 automatisch ein anderes Netzwerk aus.
Die Unterstützung für den Protokollversand über ein gemischtes Netzwerk wird mithilfe des Cmdlets Enable-ContinuousReplicationHostName konfiguriert. Ähnlich erzielen Sie die Deaktivierung dieses Features durch Verwendung des Cmdlets Disable-ContinuousReplicationHostName. Nachdem sich in der CCR-Umgebung ein Postfachclusterserver befindet, kann der Administrator das Cmdlet Enable-ContinuousReplicationHostName auf beiden Knoten des Clusters ausführen und zwei IP-Adressen und Hostnamen angeben. Anschließend wählt das System nach der erfolgreichen Konfiguration und bei Bestätigung, dass das gemischte Netzwerk betriebsbereit ist, nach dem Zufallsprinzip ein gemischtes Netzwerk für den Protokollkopiervorgang aus.
Das Seeding und erneute Seeding in einer CCR-Umgebung wird mithilfe des Cmdlets Update-StorageGroupCopy durchgeführt. In Exchange 2007 SP1 enthält dieses Cmdlet zusätzlich den neuen Parameter DataHostNames. Dieser Parameter legt das Netzwerk fest, das für das Seeding und erneute Seeding verwendet werden soll. Bei dem Wert handelt es sich um eine mehrwertige Liste aus zwei Namen: entweder ein vollqualifizierter Domänenname (FQDN) oder ein Hostname. Einer dieser Namen muss den passiven Knoten angeben.
Weitere Informationen zum Konfigurieren redundanter Netzwerke für den Protokollversand und das Seeding finden Sie unter den folgenden Themen:
CCR mit Windows Server 2008:
CCR mit Windows Server 2003:
Aufgaben im Zusammenhang mit Speichergruppen und Datenbanken in einem Postfachclusterserver
Die administrativen Aufgaben im Zusammenhang mit Speichergruppen und Datenbanken in einem Postfachclusterserver in einer CCR-Umgebung umfassen Folgendes:
Verschieben des Speicherorts von Speichergruppendateien oder einer Datenbank.
Anzeigen des Status von Speichergruppenkopien.
Bereitstellen und Aufheben der Bereitstellung von Datenbanken.
Überprüfen der Integrität der Speichergruppenkopie.
Wiederherstellen nach einem Fehler in einer Produktionsspeichergruppe oder einer Speichergruppenkopie.
Wiederherstellen der fortlaufenden Clusterreplikation nach einem Ausfall oder dem Auftreten von Datenfehlern.
Mit Ausnahme der Speichergruppe für die Wiederherstellung, die eine besondere Form von Speichergruppe ist, werden alle Speichergruppen und Datenbanken in einer CCR-Umgebung automatisch für die fortlaufende Replikation aktiviert. Obwohl Replikation und Wiedergabe angehalten werden können, ist es nicht möglich, die fortlaufende Replikation für eine oder mehrere Speichergruppen in einer CCR-Umgebung zu deaktivieren, da dies den Zugriff auf bestimmte Datenbanken im Falle eines Ausfalls verhindern könnte.
Wenn Sie eine neue Speichergruppe in einer CCR-Umgebung erstellen, sollte das Seeding der Datenbankkopie auf dem passiven Knoten automatisch erfolgen. Sollte das Seeding nicht automatisch erfolgen, müssen Sie das Seeding der Datenbankkopie manuell vornehmen. Ausführliche Anweisungen zum Seeding einer Datenbankkopie finden Sie unter Seeding einer fortlaufenden Clusterreplikationskopie.
Verschieben des Speicherorts von Speichergruppendateien oder einer Datenbank
Gelegentlich kann es erforderlich sein, den Speicherort für Speichergruppendateien oder für eine Datenbank in einer CCR-Umgebung zu verschieben. Wie lange das Verschieben der Dateien dauert, richtet sich nach der Größe der zu verschiebenden Datenbank, der Anzahl der zu verschiebenden Transaktionsprotokolldateien und den Leistungsmerkmalen des Speichers. Bei jeder Verschiebung wird die Bereitstellung der Datenbank aufgehoben.
In einer CCR-Umgebung müssen beim Ändern des Speicherorts einer Speichergruppe die Speicherorte beider Kopien konsistent geändert werden, da die Dateispeicherorte auf dem aktiven und dem passiven Knoten identisch sein müssen. Bevor eine Speichergruppe oder ihre Datenbank verschoben werden kann, müssen Sie die Bereitstellung der Datenbank aufheben und die Replikation anhalten. Für die aktive Kopie können Sie dazu das Cmdlet Dismount-Database in der Exchange-Verwaltungsshell verwenden. Für den Microsoft Exchange-Replikationsdienst verwenden Sie die Cmdlets Suspend-StorageGroupCopy und Resume-StorageGroupCopy.
Hinweis
Der Microsoft Exchange-Replikationsdienst überwacht ständig sowohl die Dateien am Speicherort der Kopie als auch die Protokolle auf dem aktiven Knoten. Wenn aktive Protokolle geändert werden, müssen Sie daher die Aktivitäten dieser Speichergruppe mit dem Cmdlet Suspend-StorageGroupCopy anhalten, wodurch die Replikation angehalten wird.
Ausführliche Anweisungen zum Verschieben des Speicherorts von Speichergruppendateien in einer CCR-Umgebung finden Sie unter Verschieben einer Speichergruppe in einer CCR-Umgebung. Ausführliche Anweisungen zum Verschieben des Speicherorts einer Datenbank in einer CCR-Umgebung finden Sie unter Verschieben einer Datenbank in einer CCR-Umgebung.
Anzeigen des Status von Speichergruppenkopien
In der RTM-Version (Release To Manufacturing) von Exchange 2007 können Sie die CCR-Statusinformationen nur mithilfe der Exchange-Verwaltungsshell anzeigen. In Exchange 2007 SP1 können einige der in der folgenden Tabelle aufgelisteten Statusinformationen in der Exchange-Verwaltungskonsole angezeigt werden.
Exchange 2007 gibt eine Reihe von Statusinformationen für Speichergruppenkopien aus. Die folgende Tabelle beschreibt die verfügbaren Statusinformationen. In der folgenden Tabelle werden die Attribute in der Reihenfolge aufgeführt, in der sie in der vollständigen Ausgabe des Cmdlets Get-StorageGroupCopyStatus angezeigt werden. Ausführliche Anweisungen zum Anzeigen von Statusinformationen finden Sie unter Anzeigen des Status einer fortlaufenden Clusterreplikationskopie mithilfe der Exchange-Verwaltungsshell.
Verfügbare Statusinformationen für CCR-aktivierte Speichergruppen
| Attribut | Beschreibung |
|---|---|
Identity |
Identität der abgefragten Speichergruppe. Dieses Attribut liefert die Information <Servername>\<Speichergruppenname>. |
StorageGroupName |
Name der abgefragten Speichergruppe. Dieses Attribut liefert den Namen der Speichergruppe. |
SummaryCopyStatus |
Aktueller Gesamtstatus der passiven Kopie. Die folgenden Werte sind möglich:
Exchange 2007 SP1 stellt zusätzlich folgende Statuswerte zur Verfügung:
|
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 |
Zeigt an, dass das Seeding ausgeführt wird. Mögliche Werte sind True und False. |
Suspend |
Zeigt an, dass die Replikation für die passive Kopie angehalten wurde. Dieser Zustand verhindert, dass die Datenbank aktualisiert wird und Protokolle kopiert werden. Mögliche Werte sind True und False. |
SuspendComment |
Optionaler Kommentar, mit dem ein Administrator erläutern kann, warum die Replikationsaktivitäten angehalten wurden. |
CopySuspend |
Zeigt an, dass das Kopieren des Protokolls für die passive Kopie angehalten wurde. Hierdurch wird verhindert, dass das Verzeichnis für die Protokollkopie überschrieben wird. Mögliche Werte sind True und False. |
CopySuspendComment |
Optionaler Administratorkommentar, der erläutert, warum die Protokollkopieraktivitäten angehalten wurden. |
CopyQueueLength |
Die Anzahl der Transaktionsprotokolldateien, die auf den Kopiervorgang in den Protokolldateiordner der passiven Kopie warten. Eine Kopie wird erst als vollständig betrachtet, nachdem sie auf Fehler überprüft wurde. |
ReplayQueueLength |
Die Anzahl der 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 Datenbank wiedergegeben wurde. |
LatestFullBackupTime |
Der Zeitpunkt der letzten vollständigen Sicherung. |
LastestIncrementalBackupTime |
Der Zeitpunkt der letzten inkrementellen Sicherung. |
SnapshotBackup |
Gibt an, ob die letzte vorgenommene vollständige Sicherung eine Legacystreamingsicherung oder ein Sicherungssnapshot des Volumeschattenkopie-Diensts (Volume Shadow Copy Service, VSS) war. |
SnapshotLatestFullBackup |
Der Zeitpunkt der letzten vollständigen Snapshotsicherung. |
SnapshotLatestIncrementalBackup |
Der Zeitpunkt der letzten inkrementellen Snapshotsicherung. |
SnapshotLatestDifferentialBackup |
Der Zeitpunkt der letzten differenziellen Snapshotsicherung. |
SnapshotLatestCopyBackup |
Der Zeitpunkt der letzten Snapshotkopiesicherung. |
OutstandingDumpsterRequests |
Ausstehende Anforderungen und der Zeitraum (niedrig – hoch) für die ausstehenden Anforderungen. |
DumpsterStatistics |
Transportpapierkorbstatistiken von allen Hub-Transport-Servern, auf die zugegriffen werden kann. Dieser Wert wird nur angezeigt, wenn der Parameter DumpsterStatistics mit dem Befehl Get-StorageGroupCopyStatus verwendet wird. |
DumpsterStatisticsNotAvailable |
Liste der Hub-Transport-Server, auf die nicht zugegriffen werden kann. |
Der Zustand einer Speichergruppenkopie lässt sich schnell durch Prüfen der Werte von SummaryCopyStatus, CopyQueueLength, ReplayQueueLength und LastInspectedLogTime einschätzen. Diese Attribute zeigen an, ob die Speichergruppenkopie ordnungsgemäß funktioniert und ob die Speichergruppenkopie 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 nicht in einem fehlerfreien Zustand.
Die Länge der Kopiewarteschlange ist größer als 5.
Die Länge der Wiedergabewarteschlange ist größer als 20.
Der Zeitpunkt der letzten Protokolluntersuchung liegt länger zurück. Dies kann durch Inaktivität in der Speichergruppe verursacht werden, es kann jedoch auch darauf hinweisen, dass der Microsoft Exchange-Replikationsdienst beendet wurde.
Die beiden Warteschlangenwerte lassen sich in Zeiteinheiten wie folgt berechnen:
Kopiewarteschlange in Zeiteinheiten = LatestAvailableLogTime – LastCopiedLogTime
Wiedergabewarteschlange in Zeiteinheiten = LatestCopiedLogTime – LastInspectedLogTime
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 Microsoft Exchange-Replikationsdienst-Leistungsobjekts.
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.
Hinweis
In Exchange 2007 SP1 können Sie auch das neue Cmdlet Test-ReplicationHealth verwenden, um den Zustand und den Status von Speichergruppen zu überprüfen, die für die fortlaufende Replikation aktiviert sind. Weitere Informationen zum Cmdlet Test-ReplicationHealth finden Sie unter Test-ReplicationHealth.
Bereitstellen und Aufheben der Bereitstellung von Datenbanken
Gelegentlich kann es notwendig sein, Datenbanken in einer CCR-Umgebung bereitzustellen oder ihre Bereitstellung aufzuheben. 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 wird diese fixiert; es können keine weiteren Änderungen vorgenommen werden. Weder die Datenbank noch die Protokolldateien werden während dieser Zeit geändert.
Weitere Informationen zum Bereitstellen von Datenbanken in einer CCR-Umgebung finden Sie unter Bereitstellen einer Datenbank in einer Umgebung mit fortlaufender Clusterreplikation. Weitere Informationen über das Aufheben der Bereitstellung von Datenbanken in einer CCR-Umgebung finden Sie unter Aufheben der Bereitstellung einer Datenbank in einer Umgebung mit fortlaufender Clusterreplikation.
Überprüfen der Integrität der Speichergruppenkopie
Wenn Sie CCR verwenden, wird empfohlen, die Integrität der passiven Kopie 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. Sie können die Überprüfung mithilfe der Datenbankdienstprogramme für Exchange Server (Eseutil.exe) ausführen. Ausführliche Anweisungen zum Verwenden von Eseutil zum Überprüfen der Transaktionsprotokolle und Datenbankdateien auf physikalische Beschädigungen finden Sie unter Überprüfen einer Kopie der fortlaufenden Clusterreplikation mithilfe von ESEUTIL.
Hinweis
Bevor Sie eine physikalische Konsistenzprüfung für eine Datenbank ausführen, müssen Sie vorübergehend alle Replikationsaktivitäten für die Speichergruppenkopie anhalten. Sie können die Wiedergabeaktivitäten von Transaktionsprotokollen 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.
Wiederherstellen nach Fehlern in einer CCR-Umgebung
Mithilfe der fortlaufenden Clusterreplikation können Sie Beschädigungen oder Datenfehler einer Produktionsspeichergruppe durch Einleiten eines geplanten Ausfalls wiederherstellen. Wenn die Protokolldateien nicht beschädigt sind, sollte durch die Wiederherstellung kein Datenverlust auftreten. Wenn die Protokolldateien jedoch nicht zur Verfügung stehen, kann die Speichergruppe nur bis zu einem Zeitpunkt wiederhergestellt werden, der dem letzten nicht beschädigten Satz von Änderungen entspricht, die die Kopie erreicht haben. Eine weitere Bedingung ist, dass fehlende oder fehlerhafte Änderungsdaten vor diesem Zeitpunkt nicht vorliegen dürfen.
Ausführliche Schritte, in denen erläutert wird, wie Beschädigungen oder Datenfehler in einer CCR-Umgebung wiederhergestellt werden, finden Sie unter den folgenden Themen:
Wiederherstellen des Zugriffs auf Produktionsdatenbanken nach dem Ausfall einer einzelnen Datenbank
Wiederherstellen des Zugriffs auf Produktionsdatenbanken nach einem Serverausfall
Wiederherstellen der fortlaufenden Clusterreplikation nach einem Fehler oder einer Beschädigung
Die fortlaufende Clusterreplikation stellt Funktionen zur Verfügung, die die automatische Wiederherstellung nach Auftreten eines Fehlers ermöglichen. In bestimmten Situationen ist jedoch eine manuelle Wiederherstellung erforderlich. Hierzu zählen folgende Situationen:
Fehler der Datenbankdatei auf der passiven Kopie. Ausführliche Anweisungen zum Wiederherstellen der fortlaufenden Clusterreplikation nach Auftreten eines Datenbankfehlers finden Sie unter Wiederherstellen nach Datenbankbeschädigung.
Fehler der Datenbankdatei oder eine Protokollvolumes auf der passiven Kopie. Ausführliche Anweisungen zum Wiederherstellen der fortlaufenden Clusterreplikation nach Auftreten eines Volumefehlers finden Sie unter Wiederherstellung nach einem Volumefehler.
Datenbankfehler oder -abweichung. Die fortlaufende Clusterreplikation erkennt und meldet Abweichungen, die als Folge eines Datenbankfehlers aufgetreten sind. Normalerweise treten diese Abweichungen auf, wenn eine Datenbankkopie verfügbar gemacht wird und die fehlerhafte Datenbankkopie mehr Änderungen aufweist, als in den Kriterien für die automatische Bereitstellung zugelassen werden. Ausführliche Anweisungen zum Wiederherstellen der fortlaufenden Clusterreplikation nach einem Datenbankfehler oder einer Abweichung finden Sie unter Wiederherstellen der CCR-Funktion nach Ausfall oder Abweichung.