Geplante und ungeplante Ausfälle

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

Letztes Änderungsdatum des Themas: 2007-10-29

In einer Umgebung mit fortlaufender Clusterreplikation (Cluster Continuous Replication, CCR) sind zwei Arten von Ausfällen möglich: geplante und ungeplante Ausfälle. Geplante Ausfälle werden von einem Administrator initiiert, um entweder einen Fehler zu beheben oder eine Wartung durchzuführen. Bei ungeplanten Ausfällen handelt es sich um unerwartete Ereignisse, aufgrund derer Dienste, Daten oder beides nicht zur Verfügung stehen. CCR ist sowohl für die Bearbeitung geplanter als auch ungeplanter Ausfälle konzipiert.

Geplante Ausfälle

Mit CCR können Sie einen umfangreichen Systemausfall eines bestimmten Knotens ohne umfangreichen Ausfall des Postfachclusterservers planen. Mit der CCR-Funktion für geplante Ausfälle können Sie sicherstellen, dass alle Protokolldaten auf dem aktiven Knoten erfolgreich auf den passiven Knoten kopiert werden. Daher erfolgen geplante Ausfälle immer ohne Datenverluste, obwohl die Replikation asynchron erfolgt. Fehler und der sich daraus ergebende Failover können bewirken, dass sehr aktuelle Protokolldaten für den passiven Knoten zu dem Zeitpunkt nicht verfügbar sind, zu dem er online geschaltet wird.

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. Zu einem bestimmten Zeitpunkt kann entweder der Computer, auf dem sich die Dateifreigabe für das MNS-Quorum (Majority Node Set, Hauptknotensatz) mit Dateifreigabezeuge befindet, oder der passive Knoten im Failovercluster für Hardware- und Softwarewartung, Aktualisierungen und Reparaturen im Offlinemodus ausgeführt werden. Es empfiehlt sich, einen Knoten niemals herunterzufahren, ohne zuvor zu prüfen, ob er aktiv ist oder Ressourcen hostet. Sie können mithilfe der Clusterverwaltung ermitteln, ob er Ressourcen hostet. Sie können den Status des Knotens bestimmen, indem Sie das Cmdlet Get-ClusteredMailboxServerStatus in der Exchange-Verwaltungsshell ausführen. Weitere Informationen zum Anzeigen des Status eines Postfachclusterservers finden Sie unter Anzeigen des Status eines Postfachclusterservers.

Verwaltungsaufgaben

Geplante Ausfälle werden von einem Administrator initiiert, um entweder einen Fehler zu beheben oder eine Wartung durchzuführen. Bei einem geplanten Ausfall kann das System den Postfachclusterserver vom aktiven Knoten auf auf den passiven Knoten verschieben (wobei der passive Knoten zum neuen aktiven Knoten wird) und die replizierten Datenbanken und Speichergruppen bereitstellen. Nach ihrer Bereitstellung dienen die Datenbanken als Quelle für alle nachfolgenden Aktualisierungen weiterer Replikationen. Die beiden Kopien wechseln die Replikationsrollen - welche Kopie die Datenbankänderungen produziert und welche die Datenbankänderungen empfängt und anwendet.

Da CCR die asynchrone Replikation verwendet, muss für den Übergang des aktiven Postfachclusterservers von einem Knoten eines Clusters zu einem anderen Knoten im Cluster eine Koordination von Cluster und Replikationsunterstützung erfolgen. Bei CCR ist diese Koordination implementiert. Der Administrator initiiert einen geplanten Ausfall mithilfe des Cmdlets Move-ClusteredMailboxServer in der Exchange-Verwaltungsshell.

Das Cmdlet Move-ClusteredMailboxServer stellt sicher, dass der passive Knoten über eine gültige und fehlerfreie Kopie verfügt. Zusätzlich wird geprüft, ob es sich um eine relativ aktuelle Kopie handelt. Wenn dies nicht der Fall ist, könnte der Ausfall während der Replikation erheblich sein. Wenn diese Prüfungen erfolgreich sind, wird der Übergang initiiert. Erfolgt die Verschiebung fehlerfrei, wird die Aufgabe abgeschlossen, wenn der Postfachclusterserver auf den ausgewählten Knoten ausgeführt wird und alle Datenbanken bereitgestellt sind. Fehler, die während dieses Prozesses auftreten, können den Übergang verhindern oder Einfluss darauf nehmen, ob alle Datenbanken automatisch bereitgestellt werden. Unter diesen Umständen greift dann das Verhalten für ungeplante Ausfälle.

In bestimmten Situationen werden geplante Ausfälle für die Wiederherstellung von Servern mit Teilausfällen eingesetzt. Dies gilt beispielsweise bei einem Server mit einer beschädigten Datenbank oder fehlerhaften Protokolldateien. In diesem Fall sperrt die Logik zum Senden von Protokollen über das Replikationssystem das Cmdlet Move-ClusteredMailboxServer. Der Administrator kann dieses Szenario auf einfache Weise verwalten. Er hebt die Bereitstellung der fehlerhaften Datenbanken auf und führt den Befehl Move-ClusteredMailboxServer mit einer Option aus. Diese versucht, die zu diesen Datenbanken gehörenden Protokolle zu kopieren, das Verschieben schlägt allerdings nicht fehl, wenn nur ein Teil der Protokolle kopiert werden kann. Die Wiederherstellung, auch die einer fehlerhaften Speichergruppe, kann also mithilfe des Cmdlets Move-ClusteredMailboxServer ganz einfach durchgeführt werden.

Mit dem Cmdlet Move-ClusteredMailboxServer kann ein Administrator den Grund für den Verschiebevorgang aufzeichnen. Dieser wird dann im Ereignisprotokoll aufgenommen. Bei diesem Befehl muss der Administrator außerdem den Knoten angeben, auf dem der Postfachclusterserver gehostet werden soll. So wird verhindert, dass Administratoren versehentlich den Postfachclusterserver verschieben, wenn dieser bereits ordnungsgemäß gehostet wird.

Sowohl das Befehlszeilentool Cluster.exe als auch die grafische Benutzeroberfläche der Clusterverwaltung ermöglichen das Verschieben eines Postfachclusterservers. Bei Verwendung diese Methoden wird die Replikationslöschlogik ausgelöst. Sie sollten diese Methoden aus folgenden Gründen jedoch möglichst nicht verwenden:

• Mit diesen Methoden wird der Status der passiven Kopie nicht überprüft. 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.

• Durch diese Methoden wird die Datenbank unter Umständen für unbestimmte Zeit offline gesetzt, da die Replikation fehlerhaft ist.

Wiederherstellen der Replikationsaktivität nach einem geplanten Ausfall

Der Prozess des Wiederherstellens einer CCR-Umgebung nach dem geplanten Ausfall eines aktiven Knotens besteht im erneuten Starten des Knotens. Die Replikation wird automatisch beim Start des Systems gestartet. Es müssen zwei Fälle berücksichtigt werden:

• Der geplante Ausfall wurde erfolgreich abgeschlossen, es wurden keine Fehler während des Übergangs bezüglich des geplanten Ausfalls angezeigt, und alle Datenbanken wurden automatisch auf online gesetzt. In diesem Fall hat der Administrator mit dem geplanten Ausfall sichergestellt, dass beide Knoten konsistente Speichergruppen und Datenbanken aufwiesen. Das Ergebnis ist dann, dass der Knoten hochgefahren werden und die Replikation sofort fortsetzen kann. Die Kopie kann durch die Wiedergabe von Protokollen auf den aktuellen Stand gebracht werden. Es ist keine besondere Aktion erforderlich.

• Der geplante Ausfall war nur teilweise erfolgreich, oder einige Datenbanken wurden vor dem geplanten Ausfall beschädigt. In diesem Fall konnte der geplante Ausfall nicht sicherstellen, dass alle Protokolle auf der Quelle dem Ziel zur Verfügung gestellt wurden, bevor dieses seine Datenbanken bereitgestellt hat. Normalerweise tritt diese Situation infolge eines Fehlers entweder vor dem geplanten Ausfall oder zu einem späten Zeitpunkt im geplanten Ausfallsvorgang ein. Daher sind Quell- und Zieldatenbanken nicht konsistent. In einigen Situationen kann CCR nach Inkonsistenzen automatisch wiederhergestellt werden. In diesem Fall startet und verarbeitet die Replikation die verfügbaren Protokolle. Wenn die Replikation nicht automatisch wiederhergestellt werden kann, wird die Kopie als beschädigt markiert. Außerdem wird ein Ereignis mit entsprechender Problembeschreibung generiert. Wenn der Speicher dies zulässt, wird als erste Wiederherstellungsaktion ein erneutes Seeding der Kopie durchgeführt. Weitere Informationen zu dem Verfahren, mit dem diese Probleme behoben werden können, finden Sie unter Seeding einer fortlaufenden Clusterreplikationskopie.

Ungeplante Ausfälle

Ungeplante Ausfälle sind automatische Systemreaktionen auf bestimmte Arten von Fehlern. CCR legt den Schwerpunkt bei diesen Fehlern auf die automatische Wiederherstellung, wobei davon ausgegangen wird, dass sich die Verfügbarkeit verbessert und die meisten Umgebungen eine automatische Wiederherstellung benötigen.

Bei einem ungeplanten Ausfall kann das System den Postfachserver auf dem passiven Knoten aktivieren, diesen dadurch aktiv setzen und die replizierten Datenbanken und Speichergruppen bereitstellen. Nach ihrer Bereitstellung dienen die Datenbanken als Quelle für alle nachfolgenden Aktualisierungen weiterer Replikationen. Die beiden Kopien wechseln die Replikationsrollen - welche Kopie die Datenbankänderungen produziert und welche die Datenbankänderungen empfängt und anwendet.

Da CCR die asynchrone Replikation verwendet, bedeutet ein ungeplanter Ausfall gleichzeitig einen Datenverlust. Zumindest die vom aktiven Server aktiv geschriebenen Protokolle stehen für die Wiederherstellung nicht zur Verfügung. Zur Behebung dieses Problems bietet CCR die Verwaltungskontrolle über das Failoververhalten sowie ein Feature, mit dem die betroffenen Daten zur Verfügung gestellt werden können.

Wenn ein Failover eintritt, aktiviert CCR stets den Postfachserver auf dem verbleibenden passiven Knoten. Die Systemsteuerelemente richten sich danach, ob auf dem nun aktiven Knoten Datenbanken bereitgestellt sind. CCR stellt Steuerelemente zur Verwaltung zur Verfügung, mit denen festgelegt wird, ob Datenbanken bereitgestellt werden. Standardmäßig wird die Position BesteVerfügbarkeit verwendet. Bei dieser Position stellt das System automatisch alle Datenbanken bereit, die mit der zuvor aktiven Produktionsdatenbank synchronisiert sind. Die Einstellung BesteVerfügbarkeit lässt einen größeren Spielraum bei der Inkonsistenz zwischen den beiden Kopien zu. Die Einstellung GuteVerfügbarkeit versetzt eine Datenbank in den Onlinemodus, wenn während der für das Erzeugen eines neuen Protokolls benötigten Zeit das zuletzt generierte Protokoll repliziert wurde. Die Einstellung Verlustfrei garantiert, dass die Kopie erst dann online geschaltet wird, wenn sichergestellt ist, dass kein Datenverlust zu verzeichnen ist. Bei dieser Einstellung wird die automatische Wiederherstellung erst dann durchgeführt, wenn der ursprüngliche Server wieder in Betrieb ist und alle Protokolldaten verfügbar und nicht beschädigt sind.

Wenn eine oder mehrere Datenbanken sich in einem Zustand befinden, in dem sie von der Einstellung nicht automatisch bereitgestellt werden, kann der Administrator explizit bestimmen, dass die Kopie mit dem verfügbaren Inhalt bereitgestellt wird. Der Administrator muss den Status der Kopie prüfen und dann zwei Befehle ausführen. Der erste Befehl teilt dem Replikationsmodul mit, dass diese Kopie als Replikationsquelle (Änderungsquelle) verwendet werden soll, d. h. dass diese Kopie bereitzustellen ist. Mit dem zweiten Befehl wird die Datenbank bereitgestellt.

Weitere Informationen zur Wiederherstellung nach Fehlern oder Ausfällen bei aktivierter CCR finden Sie unter Verwalten der fortlaufenden Clusterreplikation.

Steuerelemente zur Verwaltung

Steuerelemente zur Verwaltung werden bereitgestellt, um das Verhalten im Fall eines ungeplanten Ausfalls zu steuern. CCR stellt ein Attribut für Postfachserver zur Verfügung, mit dem Sie das Wiederherstellungsverhalten bei ungeplanten Ausfällen steuern können. Das Attribut Get-ClusteredMailboxServerStatus kann einen der folgenden drei Werte aufweisen: Verlustfrei, GuteVerfügbarkeit und BesteVerfügbarkeit.

• Verlustfrei   Verlustfrei bedeutet null verlorene Protokolle. Wenn das Attribut auf den Wert Verlustfrei gesetzt ist, wartet das System in den meisten Fällen, bis der ausgefallene Knoten wieder online geschaltet ist, bevor die Datenbanken bereitgestellt werden. Sogar dann muss das ausgefallene System wieder mit allen verfügbaren Protokollen und ohne Beschädigung ausgeführt werden. Nach dem Ausfall werden der passive Knoten aktiv geschaltet und der Microsoft Exchange-Informationsspeicherdienst auf online gesetzt. Es wird geprüft, ob die Datenbanken ohne Datenverlust bereitgestellt werden können. Wenn dies zutrifft, werden die Datenbanken zur Verfügung gestellt. Andernfalls versucht das System in regelmäßigen Abständen, die Protokolle zu kopieren. Wenn der Server wieder mit intakten Protokollen ausgeführt wird, ist dieser Versuch letztendlich erfolgreich, und die Datenbanken werden bereitgestellt. Wird der Server ohne intakte Protokolle ausgeführt, sind die übrigen Protokolle nicht verfügbar und die betroffenen Datenbanken werden nicht bereitgestellt.

  Hinweis

  Sobald der Failover abgeschlossen ist, kann ein Administrator eingreifen und sich für die Bereitstellung mit den auf dem zuvor passiven Knoten verfügbaren Datenbanken und Protokollen entscheiden. Dazu sind lediglich zwei Schritte erforderlich. Der Administrator entscheidet sich vermutlich für ein Eingreifen, nachdem er zuvor berechnet hat, wie viel Zeit benötigt wird, bis der Originalserver wieder in Betrieb ist. Zu den für diese Berechnung bedeutenden Faktoren zählen die Konsistenz der Replikation zwischen den beiden Knoten zur Ausfallzeit und die Dringlichkeit, mit der Clients wieder Zugriff auf ihre Server benötigen.

• GuteVerfügbarkeit   GuteVerfügbarkeit bedeutet drei verlorene Protokolle. Bei diesem Wert wird eine vollständige automatische Wiederherstellung erzielt, wenn die Replikation normal durchgeführt wird und die Replikation der Protokolle entsprechend der Erzeugungsrate erfolgt.

• BesteVerfügbarkeit   BesteVerfügbarkeit bedeutet sechs verlorene Protokolle (Standardeinstellung). Dieser Wert entspricht weitestgehend dem Wert GuteVerfügbarkeit. Die automatische Wiederherstellung wird hierbei jedoch auch zugelassen, wenn die Wartezeit bei der Replikation etwas höher ist. Der neue aktive Knoten kann in diesem Fall nach dem Failover etwas hinter dem Status des alten aktiven Knotens zurückliegen und auf diese Weise die Wahrscheinlichkeit erhöhen, dass eine Datenbankabweichung auftritt, für deren Behebung ein vollständiges erneutes Seeding erforderlich ist.

Weitere Informationen zum Verwaltungsverhalten bei Ausfällen finden Sie unter Optimieren der Einstellungen für Failover und Bereitstellen für die fortlaufende Clusterreplikation.