Switchover und Failover

Artikel
11/28/2016

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

Switchover und Failover sind die beiden Arten von Ausfällen in Microsoft Exchange Server 2010. Ein Switchover ist ein geplanter Ausfall einer Datenbank oder eines Servers, der explizit von einem Administrator initiiert wird, im Allgemeinen im Rahmen der Vorbereitung auf die Durchführung eines Wartungsvorgangs. Für einen Switchover muss ein Administrator die aktive Kopie der Postfachdatenbank auf einen anderen Server in der Database Availability Group (DAG) verschieben.

Als Failover werden unerwartete Ereignisse bezeichnet, aufgrund derer Dienste, Daten oder beides nicht zur Verfügung stehen. Bei einem Failover erfolgt eine automatische Wiederherstellung des Systems nach dem Ausfall, indem eine passive Kopie der Postfachdatenbank zur aktiven Kopie gemacht wird.

Die Plattform für die hohe Verfügbarkeit in Exchange 2010 ist für die Verarbeitung von Switchover- und Failoversituationen konzipiert.

Möchten Sie wissen, welche anderen Verwaltungsaufgaben es im Zusammenhang mit der hohen Verfügbarkeit und der Standortflexibilität gibt? Informationen hierzu finden Sie unter Verwalten von hoher Verfügbarkeit und Ausfallsicherheit für Standorte.

Switchover

Es gibt drei Arten von Switchovern in Exchange 2010:

Datenbankswitchover
Serverswitchover
Datencenterswitchover

Datenbankswitchover

Ein Datenbankswitchover ist der Vorgang, bei dem für eine einzelne aktive Datenbank auf eine andere Datenbankkopie (eine passive Kopie) gewechselt wird, wobei diese andere Datenbankkopie zur neuen aktiven Datenbankkopie wird. Datenbankswitchover können sowohl innerhalb eines Datencenters als auch zwischen Datencentern auftreten. Ein Datenbankswitchover kann mithilfe der Exchange-Verwaltungskonsole (EMC) oder der Exchange-Verwaltungsshell durchgeführt werden. Unabhängig davon, welche Schnittstelle verwendet wird, ist der Switchovervorgang immer gleich:

Der Administrator initiiert einen Datenbankswitchover, um die aktuell aktive Kopie der Postfachdatenbank auf einen anderen Server zu verschieben. Der Switchover kann mit dem Cmdlet Move-ActiveMailboxDatabase oder mit dem Assistenten zum Aktivieren einer Datenbankkopie initiiert werden.
Der für den Task verwendete Client sendet einen Remoteprozeduraufruf (RPC) an den Microsoft Exchange-Replikationsdienst auf einem DAG-Mitglied.
Wenn das DAG-Mitglied nicht die Rolle "Primary Active Manager" innehat, übergibt das DAG-Mitglied den Task an den Primary Active Manager (PAM).
Der Task sendet einen Remoteprozeduraufruf an den Microsoft Exchange-Replikationsdienst auf dem PAM.
Der PAM liest und aktualisiert die Informationen zu Datenbankpfaden, die in der Clusterdatenbank für die DAG gespeichert sind.
Der PAM kontaktiert den Microsoft Exchange-Replikationsdienst auf dem DAG-Mitglied, dessen passive Kopie als neue aktive Kopie der Postfachdatenbank aktiviert wird.
Der Microsoft Exchange-Replikationsdienst auf dem Zielserver fragt die Microsoft Exchange-Replikationsdienste auf allen anderen DAG-Mitgliedern ab, um die beste Protokollquelle für die Datenbankkopie zu bestimmen.
Die Einbindung der Datenbank wird vom aktuellen Server entfernt, und der Microsoft Exchange-Replikationsdienst auf dem Zielserver kopiert die verbleibenden Protokolle auf den Zielserver.
Der Microsoft Exchange-Replikationsdienst auf dem Zielserver fordert eine Datenbankeinbindung an.
Der Microsoft Exchange-Informationsspeicherdienst auf dem Zielserver gibt die Protokolldateien wieder und bindet die Datenbank ein.
Alle etwaigen Fehlercodes werden an den Microsoft Exchange-Replikationsdienst auf dem Zielserver zurückgegeben.
Der PAM aktualisiert die Statusinformationen für Datenbankkopien in der Clusterdatenbank für die DAG.
Alle etwaigen Fehlercodes werden vom Microsoft Exchange-Replikationsdienst auf dem Zielserver an den Microsoft Exchange-Replikationsdienst auf dem PAM zurückgegeben.
Der Microsoft Exchange-Replikationsdienst auf dem PAM gibt alle etwaigen Fehler an die Verwaltungsschnittstelle zurück, über die der Task aufgerufen wurde.
Die Remote-PowerShell gibt die Ergebnisse des Vorgangs an die aufrufende Verwaltungsschnittstelle zurück.

Genaue Anweisungen zum Durchführen eines Datenbankswitchovers finden Sie unter Aktivieren einer Kopie einer Postfachdatenbank.

Serverswitchover

Ein Serverswitchover ist der Vorgang, bei dem alle aktiven Datenbanken auf einem DAG-Mitglied auf mindestens einem anderen DAG-Mitglied aktiviert werden. Wie ein Datenbankswitchover kann ein Serverswitchover innerhalb eines Datencenters und zwischen Datencentern auftreten, und er kann mithilfe der Exchange-Verwaltungskonsole oder der Shell initiiert werden. Unabhängig davon, welche Schnittstelle verwendet wird, ist der Switchovervorgang immer gleich:

Der Administrator initiiert einen Serverswitchover, um alle aktuell aktiven Kopien von Postfachdatenbanken auf mindestens einen anderen Server zu verschieben. Der Switchover kann mit dem Cmdlet Move-ActiveMailboxDatabase oder mit der Benutzeroberfläche für den Serverswitchover initiiert werden.
Der Task führt für jede aktive Datenbank auf dem aktuellen Server die Schritte aus, die weiter oben in diesem Thema für Datenbankswitchover beschrieben wurden (Schritte 2 bis 4) .
Der PAM liest und aktualisiert die Informationen zu Datenbankpfaden, die in der Clusterdatenbank für die DAG gespeichert sind.
Der PAM kontaktiert den Microsoft Exchange-Replikationsdienst auf jedem DAG-Mitglied, auf dem eine passive Kopie aktiviert wird.
Der Microsoft Exchange-Replikationsdienst auf den Zielservern fragt die Microsoft Exchange-Replikationsdienste auf allen anderen DAG-Mitgliedern ab, um die beste Protokollquelle für die Datenbankkopie zu bestimmen.
Die Einbindung der Datenbank wird vom aktuellen Server entfernt, und der Microsoft Exchange-Replikationsdienst auf jedem Zielserver kopiert die verbleibenden Protokolle auf den Zielserver.
Der Microsoft Exchange-Replikationsdienst auf jedem Zielserver fordert eine Datenbankeinbindung an.
Der Microsoft Exchange-Informationsspeicherdienst auf jedem Zielserver gibt die Protokolldateien wieder und bindet die Datenbank ein.
Alle etwaigen Fehlercodes werden an den Microsoft Exchange-Replikationsdienst auf dem Zielserver zurückgegeben.
Der PAM aktualisiert die Statusinformationen für Datenbankkopien in der Clusterdatenbank für die DAG.
Alle etwaigen Fehlercodes werden vom Microsoft Exchange-Replikationsdienst auf dem Zielserver an den Microsoft Exchange-Replikationsdienst auf dem PAM zurückgegeben.
Der Microsoft Exchange-Replikationsdienst auf dem PAM gibt alle etwaigen Fehler an die Verwaltungsschnittstelle zurück, über die der Task aufgerufen wurde.
Die Remote-PowerShell gibt die Ergebnisse des Vorgangs an die aufrufende Verwaltungsschnittstelle zurück.

Genaue Anweisungen zum Durchführen eines Serverswitchovers finden Sie unter Ausführen eines Serverswitchovers.

Datencenterswitchover

Ein Datencenter- oder Standortausfall wird anders verwaltet als die Arten von Ausfällen, die einen Server- oder Datenbankfailover verursachen können. In einer Konfiguration mit hoher Verfügbarkeit wird die automatische Wiederherstellung vom System initiiert, und nach dem Ausfall weist das Messagingsystem im Allgemeinen eine vollständig funktionsfähigen Status auf. Hingegen wird ein Datencenterausfall als Ereignis der Notfallwiederherstellung betrachtet, und die Wiederherstellung muss daher manuell durchgeführt und abgeschlossen werden, damit der Clientdienst wiederhergestellt und der Ausfall beendet werden kann. Der Vorgang, den Sie durchführen, wird als Datencenterswitchover bezeichnet. Wie bei vielen Szenarien der Notfallwiederherstellung kann eine vorherige Planung und Vorbereitung eines Datencenterswitchovers den Wiederherstellungsvorgang vereinfachen und die Dauer des Ausfalls verringern.

Weitere Informationen zu Datencenterswitchovern, einschließlich detaillierter Schritte für ihre Durchführung, finden Sie unter Datencenterswitchover.

Hinweise zum Ausführen eines Datencenterswitchovers finden Sie unter Schritt-für-Schritt-Anleitung: Datencenterswitchover einer Datenbankverfügbarkeitsgruppe in Exchange Server 2010.

Failover

Ein Failover ist ein automatischer Aktivierungsvorgang, der auf Datenbank- oder Serverebene auftreten kann. Failover treten als Reaktion auf einen Ausfall auf, der sich auf eine einzelne Datenbank auswirkt (wie z. B. einen isolierten Speicherverlust) oder auf einen gesamten Server (wie z. B. einen Ausfall der Hauptplatine oder einen Stromausfall).

DAGs und Kopien von Postfachdatenbanken stellen vollständige Redundanz (und daher schnelle Wiederherstellung) der Daten und Dienste bereit, die den Zugriff auf die Daten bereitstellen. In der folgenden Tabelle werden die erwarteten Wiederherstellungsaktionen für verschiedene Ausfälle aufgeführt. Einige Ausfälle erfordern, dass der Administrator die Wiederherstellung startet. Andere Ausfälle werden automatisch vom System behandelt.

Beschreibung	Automatische Aktivierung	Automatische Reparaturaktion	Zustand während der Reparatur: Aktiv	Zustand während der Reparatur: Passiv	Reparaturaktionen	Kommentare
Soft-Datenbankausfall von Extensible Storage Engine (ESE): Die Laufwerke, auf denen die Datenbank gespeichert ist, geben bei einigen Lesevorgängen Fehler zurück (beispielsweise Fehler -1018).	Kurze Ausfallzeit möglich. Automatischer Failover möglich.	Automatische Patchen einer defekten Seite.	Manueller Switchover, automatischer Failover oder Onlinereparatur.	Fehler	Neuerstellung des RAID-Systems, Reparatur von Datenbank und Datenbankkopien, Wiederherstellung und Patchen von Seiten oder Patchen von Seiten von einer Kopie.	Möglicherweise sind weitere Soft-Ausfallcodes für Datenbanken vorhanden. Schließt keine Ausfälle von Blöcken des NTFS-Dateisystems ein. Wenn ein Failover oder Switchover durchgeführt wird, wird der Hostserver aktualisiert.
"Semi-Soft"-Datenbankausfall von ESE: Die Laufwerke, auf denen die Datenbank gespeichert ist, geben für einige Schreibvorgänge Fehler zurück.	Kurze Ausfallzeit während automatischem Failover.	Automatische Neuerstellung des Volumes bzw. Datenträgers nach einer möglichen Laufwerkersetzung.	Die Einbindung wird aufgehoben, wenn keine Wiederherstellung möglich ist.	Fehler	Eine RAID-Neuerstellung löst möglicherweise das Problem. Kopieren und Reparieren, Ausführen der Wiederherstellung oder Neuerstellung von Volume/Datenträger nach möglicher Ersetzung.	Ein Semi-Soft-Schreibzugriffsfehler bei ESE bedeutet, dass einige Schreibvorgänge erfolgreich sind. Schließt keine Ausfälle von Blöcken des NTFS-Dateisystems ein.
"Semi-Soft"-Protokollausfall von ESE: Die Laufwerke, auf denen die Protokolldaten gespeichert sind, geben für einige Lese- oder Schreibvorgänge Fehler ohne entsprechende Wiederherstellung zurück.	Kurze Ausfallzeit während automatischem Failover.	Automatische Neuerstellung des Volumes bzw. Datenträgers nach einer möglichen Laufwerkersetzung.	Die Einbindung wird aufgehoben, wenn keine Wiederherstellung möglich ist.	Fehler	Eine RAID-Neuerstellung löst möglicherweise das Problem. Kopieren und Reparieren, Ausführen der Wiederherstellung oder Neuerstellung von Volume/Datenträger nach möglicher Ersetzung.	Ein Semi-Soft-Lese-/Schreibzugriffsfehler bei ESE bedeutet, dass einige Lese-/Schreibvorgänge erfolgreich sind. Wenn die Datenbank ausfällt, tritt die automatisierte Wiederherstellung auf, bevor die Verarbeitung der Protokolldatenwiederherstellung gestartet wird.
ESE-Softwarefehler oder Ressourcenauslastung: Ein Fehler, bei dem ESE die Instanz terminiert (z. B. Ereignis-ID 1022, Prüfpunkttiefe zu groß).	Kurze Ausfallzeit während automatischem Failover.	Keine.	Die Einbindung wird aufgehoben, wenn keine Wiederherstellung möglich ist.	Fehler	Behebung des zugrunde liegenden Ressourcenproblems.	Dieser Ausfall kann der sichtbare Fehler anderer Fälle sein.
Ausfälle von NTFS-Blöcken: Auf den Laufwerken, auf denen die Datenbank oder die Protokolle gespeichert sind, tritt ein Lese- oder Schreibfehler für eine NTFS-Kontrollstruktur auf.	Kurze Ausfallzeit während automatischem Failover.	Vollständige Neuerstellung des Volumes nach einer möglichen Laufwerkersetzung.	Die Einbindung wird aufgehoben, wenn keine Wiederherstellung möglich ist.	Fehler	Eine RAID-Neuerstellung löst möglicherweise das Problem. NTFS-Dienstprogramme lösen möglicherweise die NTFS-Probleme. Eine Exchange-Wiederherstellung kann erforderlich sein.	Dies ist wahrscheinlicher, wenn RAID nicht verwendet wird. Wenn dies Auswirkungen auf das aktive Protokollvolume hat, gehen einige aktuelle Protokolldateien verloren. Schließt keine Fehler ein, die von NTFS oder dem zugrunde liegenden Software- oder Hardwarestack automatisch korrigiert werden.
Ausfall des Datenbank- oder Protokolllaufwerks: Ein Laufwerk, auf dem Datenbank oder Protokolle gespeichert sind, ist vollständig ausgefallen, und es kann nicht darauf zugegriffen werden.	Kurze Ausfallzeit während automatischem Failover.	Das Laufwerk wird neu formatiert oder ersetzt, gefolgt von einer vollständigen Neuerstellung des Volumes.	Die Einbindung wird aufgehoben, wenn keine Wiederherstellung möglich ist.	Fehler	Laufwerkersetzung, gefolgt von möglicher RAID-Neuerstellung. Laufwerkersetzung, gefolgt von vollständiger Neuerstellung des Volumes. Vollständige Neuerstellung des Volumes.	Nicht verfügbar.
Ausfall des Datenbank- oder Protokolldateivolumes: Das Volume fällt aufgrund von Volumeproblemen bei NTFS oder auf niedrigerer Ebene aus.	Kurze Ausfallzeit während automatischem Failover.	Laufwerk neu formatiert oder ersetzt.	Die Einbindung wird aufgehoben, wenn keine Wiederherstellung möglich ist.	Fehler	Laufwerkersetzung, gefolgt von möglicher RAID-Neuerstellung. Laufwerkersetzung, gefolgt von vollständiger Neuerstellung des Volumes. Vollständige Neuerstellung des Volumes.	Nicht anwendbar.
Nicht genügend Speicherplatz auf dem Datenbank- oder Protokollvolume: Das NTFS-Dateisystem mit den Datenbank- oder Protokolldateien hat nicht genügend Speicherplatz.	Automatischer Failover, wenn die andere Kopie keinen ähnlichen Status aufweist.	Keine	Einbindung aufgehoben.	Fehler	Vollständige oder inkrementelle Sicherungen ausführen, Protokolle manuell löschen, Zeit vergehen lassen, Datenbankkopie fortsetzen oder ausgefallene Datenbankkopie reparieren.	Nicht anwendbar.
Administrator hebt die Einbindung der falschen Datenbank auf.	Wenn der Administrator den automatischen Failover nicht gesperrt hat, tritt ein kurzer Ausfall auf. Wenn der automatische Failover verhindert wird, tritt bis zur Einbindung der Datenbank ein Ausfall auf.	Keine	Einbindung aufgehoben.	Nicht verfügbar	Administrator korrigiert den Fehler.	Nicht anwendbar.
Administrator hält die falsche Datenbankkopie an.	Je nach Konfiguration und betroffener Kopie ist möglicherweise keine automatische Wiederherstellung möglich.	Keine	Nicht anwendbar.	Angehalten	Administrator korrigiert den Fehler.	Nicht anwendbar.
Administrator hebt die Einbindung einer Datenbank für Speicherung, NTFS oder Volumewartung auf.	Wenn der Administrator den automatischen Failover nicht gesperrt hat, tritt ein kurzer Ausfall auf. Wenn der automatische Failover gesperrt ist, tritt ein Ausfall auf, bis der Administrator die Aufgabe abschließt.	Keine	Einbindung aufgehoben.	Nicht zutreffend	Administrator schließt die Aufgabe ab.	Nicht anwendbar.
Administrator hält eine Datenbankkopie für Speicher-, NTFS oder Volumewartung an.	Je nach Konfiguration und betroffener Kopie ist möglicherweise keine automatische Wiederherstellung möglich.	Keine	Nicht anwendbar.	Angehalten	Administrator schließt die Aktionen ab.	Nicht anwendbar.
Administrator hebt die Einbindung einer Datenbank für die Offline-Datenbankwartung auf.	Ausfall bis Abschluss der Reparatur.	Keine	Einbindung aufgehoben.	Angehalten	Administrator schließt die Aktionen ab.	Aktive und passive Datenbankkopien weichen voneinander ab. Administrator muss Kopien anhalten.
Ausfall des Storage Area Network (SAN), Datenträger oder Speichercontrollers.	Kurze Ausfallzeit während automatischem Failover.	Keine	Einbindung aufgehoben.	Beliebig	Hardware reparieren.	Eine passive Datenbankkopie weist den Status auf, der zum Zeitpunkt des Systemausfalls vorhanden war.
Serverhardwarewartung.	Kurze Ausfallzeit während automatischem Failover (außer wenn vom Administrator blockiert).	Keine	Einbindung aufgehoben.	Beliebig	Aktionen abschließen.	Eine passive Datenbankkopie weist den Status auf, der zum Zeitpunkt des Herunterfahrens des Systems vorhanden war.
Serversoftwarewartung.	Kurze Ausfallzeit während automatischem Failover (außer wenn vom Administrator blockiert).	Keine	Einbindung aufgehoben.	Beliebig	Aktionen abschließen.	Eine passive Datenbankkopie weist den Status auf, der zum Zeitpunkt des Herunterfahrens des Systems vorhanden war.
Der Microsoft Exchange-Informationsspeicherdienst wurde durch einen Administrator beendet oder angehalten.	Keine	Keine	Einbindung aufgehoben.	Beliebig	Starten Sie den Microsoft Exchange-Informationsspeicherdienst neu.	Eine passive Datenbankkopie weist den Status auf, der zum Zeitpunkt der Dienstbeendigung vorhanden war.
Microsoft Exchange-Informationsspeicherdienst schlägt fehl; Betriebssystem wird noch ausgeführt.	Kurze Ausfallzeit während automatischem Failover.	Dienststeuerungs-Manager startet den Microsoft Exchange-Informationsspeicherdienst neu.	Einbindung aufgehoben.	Beliebig	Microsoft Exchange-Informationsspeicherdienst manuell oder automatisch neu starten.	Eine passive Datenbankkopie weist den Status auf, der zum Ausfallzeitpunkt des Microsoft Exchange-Informationsspeichers vorhanden war.
Teilweiser Ausfall des Microsoft Exchange-Informationsspeicherdiensts. Ein Teil des Exchange-Speichers arbeitet nicht mehr, aber er wird nicht als vollständig ausgefallen identifiziert.	Mögliche kurze Ausfallzeit während automatischem Failover.	Keine	Eingebunden und teilweise funktionsfähig.	Beliebig, aber möglicherweise nur teilweise funktionsfähig	Starten Sie Server, Betriebssystem oder Microsoft Exchange-Informationsspeicherdienst neu.	Nicht anwendbar.
Serverausfall: Der Server fällt aus einem der folgenden Gründe aus: Vollständiger Stromausfall Ausfall des Prozessorchips, der Hauptplatine oder der Rückwandplatine ohne Wiederherstellung Betriebssystem-Abbruchfehler Das Betriebssystem reagiert nicht mehr. Vollständiger Kommunikationsausfall	Kurze Ausfallzeit während automatischem Failover.	Computer neu starten.	Einbindung aufgehoben.	Beliebig	Strom wieder bereitstellen, Betriebssystemeinstellungen ändern, Hardwareeinstellungen ändern, Hardware ersetzen, Betriebssystem neu starten, Betriebssystem warten, Hardware warten oder Kommunikationsprobleme beheben.	Nicht anwendbar.
Quorumausfall bei DAG.	Ausfall bis Abschluss der Reparatur.	Keine	Einbindung aufgehoben.	Beliebig	Fehlerhaftes Quorum reparieren, neues Quorum zuweisen oder das Netzwerk wiederherstellen, das den Quorumausfall verursacht.	Eine passive Datenbankkopie weist den Status auf, der zum Zeitpunkt des Systemausfalls vorhanden war.
MAPI-Kommunikationsausfall im Netzwerk: Der Server ist nicht mehr im MAPI-Netzwerk verfügbar.	Kurze Ausfallzeit während automatischem Failover; muss verlustfrei sein.	Keine Kommunikation wird weiterhin versucht.	Einbindung aufgehoben.	Beliebig	Beheben des Kommunikationsproblems durch Korrigieren von Hardware- oder Softwareproblemen.	Nicht anwendbar.
Replikations-Kommunikationsausfall im Netzwerk: Der Server kann Takt, Protokollkopien oder Seed über das ausgefallene Replikationsnetzwerk nicht empfangen.	Möglicherweise kurzer Ausfall beim Kopieren oder Seeding, während die Arbeitsauslastung in ein anderes Netzwerk gewechselt wird.	Keine Kommunikation wird weiterhin versucht.	Keine	Beliebig	Beheben des Kommunikationsproblems durch Korrigieren von Hardware- oder Softwareproblemen.	Flexibilität durch Ausfall beeinträchtigt.
Mehrfacher Netzwerk-Kommunikationsausfall: Der Server kann keine Takte, Protokollkopien oder Seeds über mehrere Netzwerke empfangen.	Kurze Ausfallzeit während automatischem Failover; muss verlustfrei sein.	Keine Kommunikation wird weiterhin versucht.	Einbindung aufgehoben.	Beliebig	Beheben des Kommunikationsproblems durch Korrigieren von Hardware- oder Softwareproblemen.	Mindestens ein Netzwerk ist weiterhin funktionsfähig.
Partieller Ausfall mindestens eines Netzwerks: Hohe Fehlerraten bei Netzwerken.	Fehler nicht erkannt; keine Aktion.	Keine	Eingebunden, aber mögliche Leistungsprobleme.	Beliebig	Beheben des Kommunikationsproblems durch Korrigieren von Hardware- oder Softwareproblemen.	Höhere Fehlerraten im Netzwerk als normal.
Nicht erkanntes Hängen des Betriebssystems: Betriebssystem reagiert nicht mehr, aber dies wird nicht durch Überwachung oder Clustering erkannt.	Keine	Keine	Beliebig.	Beliebig	Nicht mehr reagierende Ressourcen neu starten oder beenden.	Hängen wird nicht erkannt; daher wird keine Aktion ausgeführt. Einige Funktionen sind möglicherweise betriebsbereit.
Ausfall eines Betriebssystemlaufwerks.	Kurze Ausfallzeit während automatischem Failover.	Keine	Einbindung aufgehoben.	Beliebig	Laufwerk ersetzen und Server neu erstellen oder Volume mit RAID neu erstellen.	Nicht anwendbar.
Nicht genügend Speicherplatz auf dem Betriebssystemlaufwerk.	Kurze Ausfallzeit während automatischem Failover.	Keine	Einbindung aufgehoben.	Beliebig	Manuell Speicherplatz auf dem Volume freigeben.	Nicht anwendbar.
Volume- oder Laufwerkfehler bei Laufwerk mit Exchange-Binärdateien.	Kurze Ausfallzeit während automatischem Failover.	Keine	Einbindung aufgehoben.	Beliebig	Laufwerk ersetzen und Anwendung neu installieren oder Volume mit RAID neu erstellen.	Nicht anwendbar.
Nicht genügend Speicherplatz auf Laufwerk mit Exchange-Binärdateien.	Kurze Ausfallzeit während automatischem Failover.	Keine	Einbindung aufgehoben.	Beliebig	Manuell Speicherplatz auf dem Volume freigeben.	Nicht anwendbar.
Ungültiges neues Protokoll erkannt: Die Protokollsequenz wird durch eine vorhandene Datei unterbrochen.	Kurze Ausfallzeit während automatischem Failover, sofern das Problem nicht auch andere Kopien betrifft.	Keine	Einbindung aufgehoben.	Fehler	Störende Protokolle nach Ermittlung der Ursache entfernen.	Störende Protokolle sollten nicht repliziert werden.
Fortlaufende Replikation erkennt ungültige Protokoll: Wiedergabe erkennt ungeeignetes Protokoll beim Kopieren oder Wiedergeben.	Nicht anwendbar.	Protokoll verwerfen.	Nicht anwendbar.	Fehler	Ungültiges Protokoll verwerfen; störenden Protokollstream verschieben.	Nicht anwendbar.

Datenbankfailover

Ein Datenbankfailover tritt auf, wenn eine aktive Datenbankkopie nicht mehr aktiv bleiben kann. Die folgenden Aktionen treten bei einem Datenbankfailover auf:

Der Datenbankausfall wird durch den Microsoft Exchange-Informationsspeicherdienst erkannt.
Der Microsoft Exchange-Informationsspeicherdienst schreibt Ausfallereignisse in das Windows Vista-Ereignisprotokoll (Codename: Crimson).
Der Active Manager auf dem Server, der die ausgefallene Datenbank enthält, erkennt die Ausfallereignisse.
Der Active Manager fordert den Datenbankkopiestatus von den anderen Servern an, die eine Kopie der Datenbank enthalten.
Die anderen Server geben den angeforderten Datenbankkopiestatus an den anfordernden Active Manager zurück.
Der PAM initiiert eine Verschiebung der aktiven Datenbank auf einen anderen Server in der DAG mithilfe eines Algorithmus zum Auswählen der besten Kopie.
Der PAM aktualisiert den Datenbankeinbindungspfad in der Clusterdatenbank so, dass er auf den ausgewählten Server verweist.
Der PAM sendet eine Anforderung, Datenbankmaster zu werden, an den Active Manager auf dem ausgewählten Server.
Der Active Manager auf dem ausgewählten Server fordert an, dass der Microsoft Exchange-Replikationsdienst die letzten Protokolle vom vorigen Server kopiert und die Datenbank als einbindbar kennzeichnet.
Der Microsoft Exchange-Replikationsdienst kopiert die Protokolle von dem Server, der zuvor über eine aktive Kopie der Datenbank verfügte.
Der Active Manager liest die maximale Protokollgenerierungsnummer aus der Clusterdatenbank.
Der Microsoft Exchange-Informationsspeicherdienst bindet die neue Kopie der aktiven Datenbank ein.

Serverfailover

Ein Serverfailover tritt auf, wenn das DAG-Mitglied das MAPI-Netzwerk nicht mehr bedienen kann oder wenn der Clusterdienst auf einem DAG-Mitglied die übrigen DAG-Mitglieder nicht mehr kontaktieren kann. Folgendes tritt im Rahmen eines Serverfailovers auf:

Der Clusterdienst auf dem PAM sendet eine Benachrichtigung über eine der beiden folgenden Bedingungen an den PAM:
1. Knoten ausgefallen Der Server ist erreichbar, aber kann nicht an DAG-Vorgängen teilnehmen.
2. MAPI-Netzwerk ausgefallen Der Server kann nicht über das MAPI-Netzwerk kontaktiert werden und kann daher nicht an DAG-Vorgängen teilnehmen.
Wenn der Server erreichbar ist, kontaktiert der PAM den Active Manager auf dem betroffenen Server und fordert die sofortige Aufhebung der Einbindung aller Datenbanken an.
Für jede betroffene Datenbankkopie wird Folgendes ausgeführt:
1. Der PAM fordert den Status der Datenbankkopie von allen Servern in der DAG an.
2. Der PAM empfängt eine Antwort von allen erreichbaren und aktiven DAG-Elementen.
3. Der PAM bestimmt unter den antwortenden Servern die beste Protokollquelle, indem er von jedem die aktuelle Protokollgenerierungsnummer abfragt.
4. Jeder der Server antwortet mit der Protokollgenerierungsnummer.
Der PAM ruft den aktuellen Suchindex-Katalogstatus aus der Clusterdatenbank ab.
Basierend auf der Protokollgenerierungsnummer und dem Katalogstatus jeder Datenbankkopie wählt der PAM die besten Kopien für die Aktivierung aus.
Der PAM aktualisiert den Einbindungspfad der Datenbank in der Clusterdatenbank.
Der PAM initiiert den Datenbankfailover durch Kommunikation mit dem Active Manager auf mindestens einem anderen Server.
Der Active Manager auf dem ausgewählten Server fordert an, dass der Microsoft Exchange-Replikationsdienst die letzten Protokolle vom vorigen Server kopiert und die Datenbank als einbindbar kennzeichnet.
Wenn die Datenbank einbindbar ist, bindet der Active Manager auf den Servern die Datenbanken ein.

Weitere Informationen zum Auswahlvorgang der besten Kopie durch den Active Manager finden Sie unter Grundlegendes zu Active Manager.

Freigeben über