Switchover und Failover

Gilt für: Exchange Server 2013 SP1

Switchover und Failover sind die beiden Arten von Ausfällen in Microsoft Exchange Server 2013:

• Ein Switchover ist ein geplanter Ausfall einer Datenbank oder eines Servers, der explizit von einem Cmdlet oder dem verwalteten Verfügbarkeitssystem in Exchange 2013 initiiert wird. Switchover erfolgen im Allgemeinen im Rahmen der Vorbereitung auf die Durchführung eines Wartungsvorgangs. Für einen Switchover muss die aktive Kopie der Postfachdatenbank auf einen anderen Server in der Database Availability Group (DAG) verschoben werden. Wenn während eines Switchovers kein fehlerfreies Ziel gefunden wird, erhalten Administratoren eine Fehlermeldung, und die Postfachdatenbank wird weiterhin bereitgestellt oder eingebunden.

• 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. Wenn während eines Failovers kein fehlerfreies Ziel gefunden wird, wird die Bereitstellung der Postfachdatenbank aufgehoben.

Exchange 2013 ist für die Verarbeitung von Switchovers und Failovern 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.

Es gibt drei Arten von Switchovervorgängen in Exchange 2013:

• Datenbankswitchover
• Serverswitchover
• Datencenterswitchover

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 Datenbankwechsel kann über das Exchange Admin Center (EAC) oder die Shell durchgeführt werden. Unabhängig davon, welche Schnittstelle verwendet wird, läuft der Switchovervorgang folgendermaßen ab:

1. Der Administrator initiiert einen Datenbankswitchover, um die aktuell aktive Kopie der Postfachdatenbank auf einen anderen Server zu verschieben.

2. Der für den Task verwendete Client sendet einen Remoteprozeduraufruf (RPC) an den Microsoft Exchange-Replikationsdienst auf einem DAG-Mitglied.

3. Wenn das DAG-Mitglied nicht die Rolle "Primary Active Manager" innehat, übergibt das DAG-Mitglied den Task an den Server mit der PAM-Rolle.

4. Der Task sendet einen Remoteprozeduraufruf an den Microsoft Exchange-Replikationsdienst auf dem Server mit der PAM-Rolle.

5. Der PAM liest und aktualisiert die Informationen zu Datenbankpfaden, die in der Clusterdatenbank für die DAG gespeichert sind.

6. Der PAM kontaktiert den Microsoft Exchange-Replikationsdienst auf dem DAG-Mitglied, dessen passive Kopie als neue aktive Kopie der Postfachdatenbank aktiviert wird.

7. 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.

8. Die Einbindung der Datenbank wird vom aktuellen Server entfernt, und der Microsoft Exchange-Replikationsdienst auf dem Zielserver kopiert die verbleibenden Protokolle auf den Zielserver.

9. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver fordert eine Datenbankeinbindung an.

10. Der Microsoft Exchange-Informationsspeicherdienst auf dem Zielserver gibt die Protokolldateien wieder und bindet die Datenbank ein.

11. Alle etwaigen Fehlercodes werden an den Microsoft Exchange-Replikationsdienst auf dem Zielserver zurückgegeben.

12. Der PAM aktualisiert die Statusinformationen für Datenbankkopien in der Clusterdatenbank für die DAG.

13. Alle etwaigen Fehlercodes werden vom Microsoft Exchange-Replikationsdienst auf dem Zielserver an den Microsoft Exchange-Replikationsdienst auf dem PAM zurückgegeben.

14. Der Microsoft Exchange-Replikationsdienst auf dem PAM gibt alle etwaigen Fehler an die Verwaltungsschnittstelle zurück, über die der Task aufgerufen wurde.

15. 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.

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 des EAC oder der Shell initiiert werden. Unabhängig davon, welche Schnittstelle verwendet wird, läuft der Serverswitchover-Vorgang folgendermaßen ab:

1. Der Administrator initiiert einen Serverswitchover, um alle aktuell aktiven Kopien von Postfachdatenbanken auf mindestens einen anderen Server zu verschieben.

2. 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) .

3. Der PAM liest und aktualisiert die Informationen zu Datenbankpfaden, die in der Clusterdatenbank für die DAG gespeichert sind.

4. Der PAM kontaktiert den Microsoft Exchange-Replikationsdienst auf jedem DAG-Mitglied, auf dem eine passive Kopie aktiviert wird.

5. 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.

6. Die Einbindung der Datenbank wird vom aktuellen Server entfernt, und der Microsoft Exchange-Replikationsdienst auf jedem Zielserver kopiert die verbleibenden Protokolle auf den Zielserver.

7. Der Microsoft Exchange-Replikationsdienst auf jedem Zielserver fordert eine Datenbankeinbindung an.

8. Der Microsoft Exchange-Informationsspeicherdienst auf jedem Zielserver gibt die Protokolldateien wieder und bindet die Datenbank ein.

9. Alle etwaigen Fehlercodes werden an den Microsoft Exchange-Replikationsdienst auf dem Zielserver zurückgegeben.

10. Der PAM aktualisiert die Statusinformationen für Datenbankkopien in der Clusterdatenbank für die DAG.

11. Alle etwaigen Fehlercodes werden vom Microsoft Exchange-Replikationsdienst auf dem Zielserver an den Microsoft Exchange-Replikationsdienst auf dem PAM zurückgegeben.

12. Der Microsoft Exchange-Replikationsdienst auf dem PAM gibt alle etwaigen Fehler an die Verwaltungsschnittstelle zurück, über die der Task aufgerufen wurde.

13. 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.

In einer Konfiguration mit Ausfallsicherheit für Standorte kann in einer DAG in Reaktion auf einen Ausfall auf Standortebene eine automatische Wiederherstellung erfolgen, sodass das Messaging-System weiterhin funktioniert. Für diese Konfiguration sind mindestens drei Standorte erforderlich, da dafür DAG-Mitglieder an zwei Standoirten und der Zeugenserver der DAG an einem dritten Standort bereitgestellt werden müssen.

Wenn Sie nicht über drei Standorte oder sogar über drei Standorte verfügen, aber Wiederherstellungsaktionen auf Rechenzentrumsebene steuern möchten, können Sie eine DAG für die manuelle Wiederherstellung konfigurieren, wenn ein Ausfall auf Standortebene auftritt. In diesem Fall würden Sie einen Prozess mit der Bezeichung Datencenterswitchover durchführen. Wie bei vielen Szenarien der Notfallwiederherstellung kann eine vorherige Planung und Vorbereitung eines Datencenterswitchovers den Wiederherstellungsvorgang vereinfachen und die Dauer des Ausfalls verringern.

Aufgrund der zahlreichen Architekturänderungen in Exchange 2013, einschließlich der Konsolidierung von Serverrollen, ist die Durchführung eines Rechenzentrumswechsels in Exchange 2013 einfacher als in Exchange 2010. Ausführliche Schritte zur Durchführung eines Datencenterswitchovers finden Sie unter Datencenterswitchover.

Ein Failover ist ein automatischer Aktivierungsvorgang, der auf Datenbank-, Server- oder Datencenterebene auftreten kann. Failover treten als Reaktion auf einen Ausfall auf, der sich auf eine einzelne Datenbank (wie z. B. einen isolierten Speicherverlust), auf einen gesamten Server (wie z. B. einen Ausfall der Hauptplatine oder einen Stromausfall) oder auf einen gesamten Standort (wie z. B. den Verlust aller DAG-Mitglieder an einem Standort) auswirkt.

DAGs und Postfachdatenbankkopien bieten vollständige Redundanz und schnelle Wiederherstellung sowohl der Daten als auch der Dienste, die zugriff auf die Daten ermöglichen. In der folgenden Tabelle sind die erwarteten Wiederherstellungsaktionen für verschiedene Fehler aufgeführt. Einige Fehler erfordern, dass der Administrator die Wiederherstellung initiiert, und andere Fehler werden automatisch vom System behandelt.

Ein Datenbankfailover tritt auf, wenn eine aktive Datenbankkopie nicht mehr aktiv bleiben kann. Die folgenden Vorkommen sind Teil eines Datenbankfailovers:

1. Der Datenbankausfall wird durch den Microsoft Exchange-Informationsspeicherdienst erkannt.

2. Der Microsoft Exchange-Informationsspeicherdienst schreibt Ausfallereignisse in das Windows Vista-Ereignisprotokoll (Codename: Crimson).

3. Der Active Manager auf dem Server, der die ausgefallene Datenbank enthält, erkennt die Ausfallereignisse.

4. Der Active Manager fordert den Datenbankkopiestatus von den anderen Servern an, die eine Kopie der Datenbank enthalten.

5. Die anderen Server geben den angeforderten Datenbankkopiestatus an den anfordernden Active Manager zurück.

6. Der PAM initiiert eine Verschiebung der aktiven Datenbank auf einen anderen Server in der DAG mithilfe eines Algorithmus zum Auswählen der besten Kopie.

7. Der PAM aktualisiert den Datenbankeinbindungspfad in der Clusterdatenbank so, dass er auf den ausgewählten Server verweist.

8. Der PAM sendet eine Anforderung, Datenbankmaster zu werden, an den Active Manager auf dem ausgewählten Server.

9. 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.

10. Der Microsoft Exchange-Replikationsdienst kopiert die Protokolle von dem Server, der zuvor über eine aktive Kopie der Datenbank verfügte.

11. Der Active Manager liest die maximale Protokollgenerierungsnummer aus der Clusterdatenbank.

12. Der Microsoft Exchange-Informationsspeicherdienst bindet die neue Kopie der aktiven Datenbank ein.

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. Die folgenden Vorkommen sind Teil eines Serverfailovers:

1. Der Clusterdienst auf dem PAM sendet eine Benachrichtigung über eine der beiden folgenden Bedingungen an den PAM:

   1. Knoten ausgefallen: Der Server ist erreichbar, kann aber 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.

2. 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.

3. 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.

4. Der PAM ruft den aktuellen Suchindex-Katalogstatus aus der Clusterdatenbank ab.

5. Basierend auf der Protokollgenerierungsnummer und dem Katalogstatus jeder Datenbankkopie wählt der PAM die besten Kopien für die Aktivierung aus.

6. Der PAM aktualisiert den Einbindungspfad der Datenbank in der Clusterdatenbank.

7. Der PAM initiiert den Datenbankfailover durch Kommunikation mit dem Active Manager auf mindestens einem anderen Server.

8. 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.

9. 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 Active Manager.

In Exchange 2013 wurden bedeutende Änderungen vorgenommen, die die Herausforderungen einer Exchange 2010-Standortresilienzkonfiguration bewältigen. Mit der Namespacevereinfachung, der Konsolidierung von Serverrollen, der Trennung von Clientzugriffsserver und DAG-Wiederherstellung (in Exchange 2013 muss der Namespace nicht mit der DAG verschoben werden) und den Änderungen am Lastenausgleich bietet Exchange 2013 neue Optionen für die Standortresilienz, z. B. die Möglichkeit, einen einzelnen globalen Namespace zu verwenden. Darüber hinaus ermöglicht Exchange 2013, wenn Sie über mehr als zwei Standorte zum Bereitstellen von Messagingdienstkomponenten verfügen, auch die Konfiguration des Messagingdiensts für ein automatisches Failover als Reaktion auf Fehler, die einen manuellen Eingriff in Exchange 2010 erforderten.

Die Konfiguration der Ausfallsicherheit von Standorten wurde in Exchange 2013 vereinfacht. Exchange wendet die in den Namespace integrierte Fehlertoleranz über mehrere IP-Adressen, einen Lastenausgleich (und bei Bedarf die Möglichkeit an, Server außer Betrieb zu nehmen). Eine der wichtigsten Änderungen, die wir in Exchange 2013 vorgenommen haben, bestand darin, die Fähigkeit der Clients zu nutzen, mehrere IP-Adressen zwischenzuspeichern, die von einem DNS-Server als Reaktion auf eine Namensauflösungsanforderung zurückgegeben wurden. Die Tatsache, dass der Client mehrere IP-Adressen zwischenspeichern kann (was fast alle HTTP-Clients können, und da fast alle Clientzugriffsprotokolle in Exchange 2013 HTTP-basiert sind (Outlook, Outlook Anywhere, EAS, EWS, OWA, EAC, RPS usw.), können alle unterstützten HTTP-Clients mehrere IP-Adressen verwenden), ermöglicht ein Failover auf Clientseite. Sie können DNS so konfigurieren, dass einem Client während der Namensauflösung mehrere IP-Adressen übergeben werden. Der Client fragt "mail.contoso.com" an und erhält beispielsweise zwei oder vier IP-Adressen. Viele IP-Adressen, die der Client zurückerlangt, werden vom Client jedoch zuverlässig verwendet. Diese optimale Auslastung macht den Client deutlich besser, denn wenn eine der IP-Adressen ausfällt, muss der Client eine oder mehrere andere stellen, um eine Verbindung herzustellen. Wenn beim Versuch einer Verbindungsherstellung durch den Client ein Fehler auftritt, wartet der Client für etwa 20 Sekunden und versucht es dann mit der nächsten Adresse in der Liste. Wenn Sie die Verbindung zu Ihrem primären CAS-Array verlieren und Sie eine zweite veröffentliche IP-Adresse für ein zweites CAS-Array haben, erfolgt die Wiederherstellung für die Clients automatisch (und in ca. 21 Sekunden).

Moderne HTTP-Clients (Betriebssysteme und Webbrowser, die maximal zehn Jahre alt sind) arbeiten automatisch mit dieser Redundanz. Der HTTP-Stapel kann mehrere IP-Adressen für einen FQDN akzeptieren. Wenn bei der ersten versuchten IP-Adresse ein Fehler auftritt (z. B. keine Verbindung hergestellt werden kann), versucht er die nächste IP-Adresse in der Liste. Bei einem soften Fehler (Verbindungsverlust nach einrichtung der Sitzung aufgrund eines zeitweiligen Fehlers im Dienst, bei dem z. B. ein Gerät Pakete abwirft und außer Betrieb genommen werden muss), muss der Benutzer möglicherweise seinen Browser aktualisieren.

Bei der richtigen Konfiguration kann ein Failover auf Clientebene erfolgen, und Clients werden automatisch an ein zweites Rechenzentrum umgeleitet, in dem Clientzugriffsserver ausgeführt werden, und diejenigen, die Clientzugriffsserver betreiben, stellen die Kommunikation per Proxy an den Postfachserver des Benutzers zurück, der vom Ausfall nicht betroffen ist (da Sie keinen Wechsel durchführen). Anstatt an der Wiederherstellung des Diensts zu arbeiten, wird der Dienst von selbst wiederhergestellt, und Sie können sich auf die Behebung des Kernproblems konzentrieren (z. B. das Ersetzen eines fehlerhaften Lastenausgleichs).

Da Sie ein Failover für den Namespace zwischen Rechenzentren durchführen können, ist nur ein Mechanismus für ein rechenzentrumsübergreifendes Failover der Postfachrolle erforderlich. Um ein automatisches Failover für die DAG zu erhalten, erstellen Sie eine Lösung, bei der die DAG gleichmäßig auf zwei Rechenzentren aufgeteilt wird, und platzieren den Zeugenserver dann an einem dritten Speicherort, sodass er von DAG-Mitgliedern in einem der beiden Rechenzentren unabhängig vom Zustand des Netzwerks zwischen den Rechenzentren, die die DAG-Mitglieder enthalten, vermittelt werden kann. Der Schlüssel besteht darin, dass der dritte Standort von Netzwerkausfällen isoliert ist, die sich auf die Standorte auswirken, die die DAG-Mitglieder enthalten.

Wenn Sie nur zwei Rechenzentren haben und automatisches Failover konfigurieren möchten, können Sie Microsoft Azure als dritten Standort nutzen. Sie müssen ein virtuelles Azure-Netzwerk erstellen und dieses über ein Multipunkt-VPN mit Ihren zwei Rechenzentren verbinden. Dann können Sie den Zeugenserver auf einen virtuellen Microsoft Azure-Computer platzieren. Weitere Informationen finden Sie unter Verwenden einer Microsoft Azure-VM als DAG-Zeugenserver.