Freigeben über

Switchover und Failover

  • Artikel

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.

Switchover

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

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

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

Datencenterswitchover

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.

Failover

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.

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 Bereitstellung wurde aufgehoben, wenn sie nicht wiederhergestellt werden kann. Fehlgeschlagen 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 Bereitstellung wurde aufgehoben, wenn sie nicht wiederhergestellt werden kann. Fehlgeschlagen 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 Bereitstellung wurde aufgehoben, wenn sie nicht wiederhergestellt werden kann. Fehlgeschlagen 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. Volume wird nach einem möglichen Austausch des Laufwerks neu erstellt. Die Bereitstellung wurde aufgehoben, wenn sie nicht wiederhergestellt werden kann. Fehlgeschlagen Eine RAID-Neuerstellung löst möglicherweise das Problem. NTFS-Dienstprogramme lösen möglicherweise die NTFS-Probleme. Eine Exchange-Wiederherstellung kann erforderlich sein. Dieses Ereignis tritt wahrscheinlicher auf, wenn RAID nicht verwendet wird. Wenn sich dieses Ereignis auf das aktive Protokollvolume auswirkt, gehen einige zuletzt verwendete Protokolldateien verloren.

Schließt keine Fehler ein, die von NTFS oder dem zugrunde liegenden Software- oder Hardwarestack automatisch korrigiert werden.
Datenbank- oder Protokolllaufwerkfehler: Auf einem Laufwerk, auf dem die Datenbank oder Protokolle gespeichert werden, ist ein Fehler aufgetreten, auf das nicht zugegriffen werden kann. Kurze Ausfallzeit während automatischem Failover. Das Laufwerk wird neu formatiert oder ersetzt, gefolgt von einer vollständigen Neuerstellung des Volumes. Die Bereitstellung wurde aufgehoben, wenn sie nicht wiederhergestellt werden kann. Fehlgeschlagen Laufwerkersetzung, gefolgt von möglicher RAID-Neuerstellung.

Laufwerkersetzung, gefolgt von vollständiger Neuerstellung des Volumes.

Vollständige Neuerstellung des Volumes.		 Nicht zutreffend.
Datenbank- oder Protokollvolumefehler: Das Volume schlägt aufgrund von NTFS- oder Volumeproblemen auf niedrigerer Ebene fehl. Kurze Ausfallzeit während automatischem Failover. Laufwerk neu formatiert oder ersetzt. Die Bereitstellung wurde aufgehoben, wenn sie nicht wiederhergestellt werden kann. Fehlgeschlagen 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. Fehlgeschlagen 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 zutreffend 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. Suspended 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. Suspended 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. Beliebiger Wert 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. Beliebiger Wert 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. Kurze Ausfallzeit während automatischem Failover. Keine. Einbindung aufgehoben. Beliebiger Wert Starten Sie den Microsoft Exchange-Informationsspeicherdienst neu. Nicht anwendbar.
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. Beliebiger Wert Microsoft Exchange-Informationsspeicherdienst manuell oder automatisch neu starten. Eine passive Datenbankkopie weist den Status auf, der zum Ausfallzeitpunkt des Microsoft Exchange-Informationsspeichers vorhanden war.
Partieller Fehler des Microsoft Exchange-Informationsspeicherdiensts; Ein Teil des Exchange-Speichers funktioniert nicht mehr, wird aber nicht als fehlerhaft erkannt. 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. Beliebiger Wert 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. Beliebiger Wert 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. Beliebiger Wert 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. Beliebiger Wert Beheben des Kommunikationsproblems durch Korrigieren von Hardware- oder Softwareproblemen. Flexibilität durch Ausfall beeinträchtigt.
Mehrere Netzwerkkommunikationsfehler: Der Server kann keine Heartbeats, Protokollkopien oder Seedings über mehrere Netzwerke empfangen. Kurze Ausfallzeit während automatischem Failover; muss verlustfrei sein. Keine. Kommunikation wird weiterhin versucht. Einbindung aufgehoben. Beliebiger Wert 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. Beliebiger Wert Beheben des Kommunikationsproblems durch Korrigieren von Hardware- oder Softwareproblemen. Höhere Fehlerraten im Netzwerk als normal.
Nicht erkannte Betriebssysteme hängen: Das Betriebssystem reagiert nicht mehr, wird aber nicht durch Überwachung oder Clustering erkannt. Keine. Keine. Beliebig. Beliebiger Wert 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. Beliebiger Wert 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. Beliebiger Wert Manuell Speicherplatz auf dem Volume freigeben. Nicht zutreffend.
Bei Laufwerken, die Exchange-Binärdateien enthalten, treten Volume- oder Laufwerksfehler auf. Kurze Ausfallzeit während automatischem Failover. Keine. Einbindung aufgehoben. Beliebiger Wert 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. Beliebiger Wert 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. Fehlgeschlagen 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. Fehlgeschlagen 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 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.

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

Datencenterfailover

In Exchange 2013 wurden erhebliche Ä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 Speicherorte 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 ggf. die Möglichkeit, Server außer Betrieb zu nehmen) an. 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 viel besser, denn wenn eine der IP-Adressen ausfällt, hat der Client eine oder mehrere andere, mit denen er versuchen kann, 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), wird die nächste IP-Adresse in der Liste versucht. Bei einem vorläufigen Fehler (Verbindungsverlust nach der 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.

Mit 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 keine Umstellung 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 ausfü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.