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 verfügen oder sogar über drei Standorte verfügen, aber Wiederherstellungsaktionen auf Datencenterebene steuern möchten, können Sie eine DAG für die manuelle Wiederherstellung im Falle eines Ausfalls auf Standortebene konfigurieren. 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.

Zwischen der Entscheidung, ein zweites Datencenter zu aktivieren, und dem Ausführen eines Datencenterswitchovers liegen vier grundlegende Schritte:

1. Beenden eines teilweise ausgeführten Rechenzentrums: Dieser Schritt umfasst das Beenden von Exchange-Diensten im primären Rechenzentrum, falls noch Dienste ausgeführt werden. Dies ist vor allem für die Postfachserverrolle wichtig, da diese ein Aktiv/Passiv-Modell für hohe Verfügbarkeit verwendet. Wenn Dienste in einem teilweise ausgefallenen Datencenter nicht angehalten werden, wirken sich die Probleme dieses Datencenters bei einem Switchover zurück zum primären Datencenter möglicherweise negativ auf die Dienste aus.

   Wichtig

   Wenn die Zuverlässigkeit eines Netzwerks oder einer Active Directory-Infrastruktur durch den Ausfall des primären Datencenters beeinträchtigt wurde, wird empfohlen, alle Messagingdienste zu deaktivieren, bis diese Abhängigkeiten wieder fehlerfrei ausgeführt werden können.

2. Überprüfen und bestätigen Sie die Voraussetzungen für das zweite Rechenzentrum: Dieser Schritt kann parallel zu Schritt 1 ausgeführt werden, da die Überprüfung der Integrität der Infrastruktur im zweiten Rechenzentrum weitgehend unabhängig vom ersten Rechenzentrum ist. Jede Organisation wendet in der Regel eine eigene Methode für die Ausführung dieses Schritts an. So können Sie beispielsweise die von einer Anwendung zur Infrastrukturüberwachung erfassten und gefilterten Integritätsinformationen prüfen oder ein speziell in Ihrer Organisationsstruktur genutztes Tool verwenden. Dies ist ein wichtiger Schritt, da Sie das zweite Rechenzentrum nicht aktivieren möchten, wenn seine Infrastruktur fehlerhaft und instabil ist.

3. Aktivieren der Postfachserver: Dieser Schritt beginnt mit der Aktivierung des zweiten Rechenzentrums. Dieser Schritt kann zeitgleich mit Schritt 4 ausgeführt werden, da die Microsoft Exchange-Dienste Datenbankausfälle und -wiederherstellungen verarbeiten können. Das Aktivieren der Postfachserver umfasst das Kennzeichnen der ausgefallenen Server im primären Datencenter als nicht verfügbar sowie das anschließende Aktivieren der Server im zweiten Datencenter. Der Aktivierungsprozess für Postfachserver hängt davon ab, ob sich die Database Availability Group (DAG) im Aktivierungsmodus der Datenbank befindet. Weitere Informationen finden Sie unter Koordinationsmodus für die Rechenzentrumsaktivierung .

   Wenn sich die DAG im DAC-Modus befindet, können Sie die Exchange-Standortresilienz-Cmdlets verwenden, um ein teilweise ausgefallenes Rechenzentrum (falls erforderlich) zu beenden und die Postfachserver zu aktivieren. Im DAC-Modus wird dieser Schritt beispielsweise mit dem Cmdlet Stop-DatabaseAvailabilityGroup ausgeführt. In einigen Fällen müssen die Server zweimal als nicht verfügbar gekennzeichnet werden (einmal in jedem Rechenzentrum). Als Nächstes wird das Cmdlet Restore-DatabaseAvailabilityGroup ausgeführt, um die verbleibenden Mitglieder der Datenbankverfügbarkeitsgruppe (DAG) im zweiten Rechenzentrum wiederherzustellen, indem die DAG-Mitglieder auf die mitglieder reduziert werden, die noch betriebsbereit sind, wodurch das Quorum wiederhergestellt wird. Wenn sich die DAG nicht im DAC-Modus befindet, müssen Sie die Windows-Failoverclustertools verwenden, um die Postfachserver zu aktivieren. Nach Abschluss eines der beiden Prozesse können die Datenbankkopien, die zuvor im zweiten Rechenzentrum passiv waren, aktiv werden und eingebunden werden. An diesem Punkt ist die Wiederherstellung des Postfachservers abgeschlossen.

4. Aktivieren von Clientzugriffsdiensten: Dies umfasst die Verwendung der URL-Zuordnungsinformationen und der DNS-Änderungsmethodik (Domain Name System), um alle erforderlichen DNS-Updates durchzuführen. Die Zuordnungsinformationen beschreiben, welche DNS-Änderungen vorgenommen werden sollen. Der Zeitraum für das Fertigstellen der Updates hängt von der verwendeten Methode und den Einstellungen für die Gültigkeitsdauer (Time to Live, TTL) im DNS-Datensatz ab (und davon, ob bei der Bereitstellung der Infrastruktur die TTL berücksichtigt wurde).

Benutzer sollten im Regelfall im Anschluss an Schritt 3 oder 4 Zugriff auf die Messagingdienste haben. Die Schritte 3 und 4 werden weiter unten in diesem Thema ausführlich beschrieben.

Beenden eines teilweise ausgefallenen Datencenters

Im ausgefallenen Datencenter noch ausgeführte Mitglieder einer Database Availability Group müssen beendet werden.

Wenn sich die Exchange-DAG im DAC-Modus befindet, können Sie die Server in einem fehlerhaften Rechenzentrum mit einem einzigen Befehl deaktivieren. Dadurch können Sie die Datenbanken auch dann in einem anderen Rechenzentrum einbinden, wenn die DAG kein Quorum aufweist (mehr als die Hälfte der verfügbaren Dag-Mitglieder).

Wenn sich die Database Availability Group im Aktivierungsmodus der Datenbank befindet, müssen folgende Aktionen ausgeführt werden, um noch ausgeführte Mitglieder einer DAG im primären Datencenter zu beenden:

1. Die DAG-Mitglieder im primären Rechenzentrum müssen im primären Rechenzentrum als beendet markiert werden. Beendet ist ein Status von Active Manager, der verhindert, dass Datenbanken eingebunden werden, und Active Manager auf jedem Server im fehlerhaften Rechenzentrum wird mithilfe des Cmdlets Stop-DatabaseAvailabilityGroup in diesen Zustand versetzt. Der ActiveDirectorySite-Parameter dieses Cmdlets kann verwendet werden, um alle Server im primären Rechenzentrum mit einem einzigen Befehl als beendet zu kennzeichnen. Dieser Schritt ist je nach Fehler möglicherweise nicht möglich. Dieser Schritt sollte ausgeführt werden, wenn der Zustand des Rechenzentrums dies zulässt. Das Cmdlet Stop-DatabaseAvailabilityGroup sollte für alle Server im primären Rechenzentrum ausgeführt werden. Wenn der Postfachserver nicht verfügbar ist, Active Directory aber im primären Rechenzentrum ausgeführt wird, muss der Befehl Stop-DatabaseAvailabilityGroup mit dem ConfigurationOnly-Parameter für alle Server in diesem Zustand im primären Rechenzentrum ausgeführt werden, andernfalls muss der Postfachserver deaktiviert werden. Wenn sie entweder die Postfachserver im ausgefallenen Rechenzentrum nicht deaktivieren oder den Befehl Stop-DatabaseAvailabilityGroup erfolgreich für die Server ausführen, kann das Split-Brain-Syndrom in den beiden Rechenzentren auftreten. Möglicherweise müssen Sie Computer über Energieverwaltungsgeräte einzeln ausschalten, um diese Anforderung zu erfüllen.

2. Das zweite Datencenter muss nun aktualisiert werden, um anzuzeigen, welche Server des primären Datencenters beendet wurden. Dies erfolgt durch Ausführen desselben Stop-DatabaseAvailabilityGroup-Befehls mit dem ConfigurationOnly-Parameter unter Verwendung desselben ActiveDirectorySite-Parameters und Angeben des Namens des Active Directory-Standorts im fehlerhaften primären Rechenzentrum. Zweck dieses Schritts ist das Benachrichtigen der Server im zweiten Datencenter hinsichtlich der Postfachserver, die beim Wiederherstellen des Diensts verwendet werden können.

Wenn sich die Database Availability Group nicht im Aktivierungsmodus der Datenbank befindet, müssen folgende Aktionen ausgeführt werden, um noch ausgeführte Mitglieder einer Database Availability Group im primären Datencenter zu beenden:

1. Für DAG-Mitglieder im primären Datencenter muss das Entfernen aus dem zugrunde liegenden Cluster der Database Availability Group erzwungen werden, indem für jedes Mitglied die folgenden Befehle ausgeführt werden:

   net stop clussvc
   

   cluster <DAGName> node <DAGMemberName> /forcecleanup
   

2. Die Mitglieder der Database Availability Group im zweiten Datencenter müssen nun neu gestartet und anschließend zum Abschließen des Entfernungsprozesses aus dem zweiten Datencenter verwendet werden. Halten Sie den Clusterdienst für jedes Mitglied der Database Availability Group im zweiten Datencenter an, indem Sie für jedes Mitglied den folgenden Befehl ausführen:

   net stop clussvc
   

3. Erzwingen Sie auf einem DAG-Mitglied im zweiten Datencenter mithilfe des folgenden Befehls einen Quorumstart des Clusterdiensts:

   net start clussvc /forcequorum
   

4. Öffnen Sie die das Tool für die Failoverclusterverwaltung, und stellen Sie die Verbindung mit dem zugrunde liegenden Cluster der Database Availability Group her. Erweitern Sie den Clusterknoten, und erweitern Sie dann Knoten. Klicken Sie mit der rechten Maustaste auf jeden Knoten im primären Datencenter, wählen Sie Weitere Aktionen, und wählen Sie dann Zwangslöschen. Schließen Sie nach dem Entfernen der DAG-Mitglieder im primären Datencenter die Tools zur Failoverclusterverwaltung.

Wenn Unified Messaging-Dienste im fehlerhaften Rechenzentrum verwendet werden, müssen diese deaktiviert werden, um das Anrufweiterleitung an das ausgefallene Rechenzentrum zu verhindern. Sie können Unified Messaging-Dienste mithilfe des Cmdlets Disable-UMService (z. B Disable-UMService EX1. ) deaktivieren. Wenn Sie ein VoIP-Gateway (Voice over IP) verwenden, können Sie alternativ auch die Servereinträge aus dem VoIP-Gateway entfernen oder die DNS-Einträge für die fehlerhaften Server so ändern, dass sie auf die IP-Adresse der Server im zweiten Rechenzentrum verweisen, wenn Ihr VoIP-Gateway für die Weiterleitung von Anrufen mithilfe von DNS konfiguriert ist.

Hinweis

Unified Messaging ist in Exchange 2019 nicht verfügbar

Aktivieren von Postfachservern

Die erforderlichen Schritte zum Aktivieren von Postfachservern während eines Datencenterswitchovers hängen ebenfalls davon ab, ob sich die Database Availability Group im Aktivierungsmodus der Datenbank befindet. Vor der Aktivierung von DAG-Mitgliedern im zweiten Datencenter sollten Sie überprüfen, ob die Infrastrukturdienste im zweiten Datencenter für die Aktivierung des Messagingdiensts bereit sind.

Wenn sich die Database Availability Group im Aktivierungsmodus der Datenbank befindet, müssen die folgenden Schritte ausgeführt werden, um die Aktivierung von Postfachservern im zweiten Datencenter abzuschließen:

1. Der Clusterdienst muss auf jedem DAG-Mitglied im zweiten Datencenter beendet werden. Sie können das Cmdlet Stop-Service verwenden, Stop-Service ClusSvcum den Dienst zu beenden (z. B. ), oder sie können an einer Eingabeaufforderung mit erhöhten Rechten verwenden net stop clussvc .

2. Die Postfachserver im Standbydatencenter werden dann mithilfe des Cmdlets Restore-DatabaseAvailabilityGroup aktiviert. Der Active Directory-Standort des Standbydatencenters wird an das Cmdlet Restore-DatabaseAvailabilityGroup weitergeleitet, damit die für die Wiederherstellung des Diensts zu verwendenden Server identifiziert und die Datenverfügbarkeitsgruppe zur Verwendung eines alternativen Zeugenservers konfiguriert werden. Wenn der alternative Zeugenserver noch nicht konfiguriert wurde, können Sie ihn mit den Parametern AlternateWitnessServer und AlternateWitnessDirectory des Cmdlets Restore-DatabaseAvailabilityGroup konfigurieren. Wird dieser Befehl erfolgreich ausgeführt, berücksichtigen die Quorumkriterien nur noch die Server im Ersatzdatencenter. Wenn in diesem Datencenter eine gerade Anzahl von Servern vorhanden ist, verwendet die DAG den alternativen Zeugenserver, der in der Einstellung für das DAG-Objekt angegeben ist.

3. Die Datenbanken können nun aktiviert werden. Abhängig von der in der Organisation verwendeten Konfiguration geschieht dies möglicherweise nicht automatisch. Wenn in den Einstellungen der Server im Ersatzdatencenter die Aktivierung blockiert ist, führt das System kein automatisches Failover vom primären Datencenter zum Ersatzdatencenter einer beliebigen Datenbank aus. Falls für keine der Datenbankkopien im Ersatzdatencenter Failovereinschränkungen vorhanden sind, aktiviert das System Kopien im zweiten Datencenter, in der Annahme, dass diese sich in einem fehlerfreien Zustand befinden. Wenn die Aktivierung in den Datenbankeinstellungen blockiert ist, die explizit das Ausführen einer manuellen Aktion erfordern, gibt es zwei Möglichkeiten:

4. Deaktivieren Sie die Einstellung, die die Aktivierung blockiert. Dadurch kehrt das System zu seinem Standardverhalten zurück, d. h., es aktiviert jede verfügbare Kopie.

5. Lassen Sie die Einstellungen unverändert, und verwenden Sie das Cmdlet Move-ActiveMailboxDatabase, um die Datenbankaktivierung im zweiten Datencenter abzuschließen. Wenn die Aktivierung in den Einstellungen blockiert ist, müssen Sie das Ziel des Verschiebevorgangs explizit angeben, um diesen Schritt mithilfe des Cmdlets Move-ActiveMailboxDatabase abzuschließen.

6. Im letzten Schritt werden alle während der einzelnen Tasks ausgegebenen Fehler und Warnmeldungen geprüft. Alle angezeigten Warnungen sollten nachverfolgt und korrigiert werden. Das Taskdesignmodell für diese Befehle sieht vor, dass nur dann Fehler ausgegeben werden, wenn die vorgesehenen Mindestziele nicht erreicht werden. Beispielsweise gibt das Cmdlet Restore-DatabaseAvailabilityGroup einen Fehler aus, wenn das Quorum der DAG nicht soweit reduziert werden kann, dass ein Server im zweiten Datencenter zur Bereitstellungen von Diensten neu gestartet werden kann, ohne einen Quorumausfall zu verursachen. Jede Taskausgabe wird auch zur Identifizierung von Problemen genutzt, die einen Administratoreingriff erfordern. Es wird dringend empfohlen, alle Taskausgaben zu speichern und auf möglicherweise erforderliche Aktionen zu prüfen.

Wenn sich die Database Availability Group nicht im Aktivierungsmodus der Datenbank befindet, müssen die folgenden Schritte ausgeführt werden, um die Aktivierung von Postfachservern im zweiten Datencenter abzuschließen:

1. Das Quorum muss basierend auf der Anzahl von DAG-Mitgliedern im zweiten Datencenter geändert werden.

2. Wenn eine ungerade Anzahl von DAG-Mitgliedern vorhanden ist, ändern Sie das DAG-Modell mithilfe des folgenden Befehls von einem Quorum des Typs Knoten- und Dateifreigabemehrheit in ein Knotenmehrheitsquorum:

   cluster <DAGName> /quorum /nodemajority
   

3. Wenn eine gerade Anzahl von DAG-Mitgliedern vorhanden ist, konfigurieren Sie den Zeugenserver und das Verzeichnis neu, indem Sie in der Exchange-Verwaltungsshell den folgenden Befehl ausführen:

   Set-DatabaseAvailabilityGroup <DAGName> -WitnessServer <ServerName>
   

4. Starten Sie den Clusterdienst für alle verbleibenden DAG-Mitglieder im zweiten Datencenter mithilfe des folgenden Befehls:

   net start clussvc
   

5. Führen Sie zum Aktivieren der Postfachdatenbanken in der Database Availability Group einen Serverswitchover aus, indem Sie für jedes DAG-Mitglied den folgenden Befehl ausführen:

   Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
   

6. Binden Sie die Postfachdatenbanken für jedes DAG-Mitglied im zweiten Standort über den folgenden Befehl ein:

   Get-MailboxDatabase <DAGMemberinSecondSite> | Mount-Database
   

Aktivieren von Clientzugriffsdiensten

Clients stellen eine Verbindung mit Dienstendpunkten (z. B. Outlook im Web, AutoErmittlung, Exchange ActiveSync, Outlook Anywhere, POP3, IMAP4 und dem RPC-Clientzugriffsdienste-Array) her, um auf Exchange-Dienste und -Daten zuzugreifen. Die Aktivierung von Clientzugriffsdiensten umfasst daher eine Änderung der Zuordnung der DNS-Einträge für diese Dienstendpunkte von IP-Adressen im primären Rechenzentrum zu den IP-Adressen im zweiten Rechenzentrum, die als neue Dienstendpunkte konfiguriert sind. Je nach DNS-Konfiguration können sich die zu ändernden DNS-Einträge in derselben oder in unterschiedlichen DNS-Zonen befinden.

Aktivieren von Clientzugriffsdiensten

Clients stellen dann auf zweierlei Art automatisch eine Verbindung mit den neuen Dienstendpunkten her:

• Clients versuchen in regelmäßigen Abständen, eine Verbindung herzustellen, und sollten automatisch verbunden werden, nachdem die Gültigkeitsdauer für den ursprünglichen DNS-Eintrag abgelaufen ist und der Eintrag aus dem DNS-Cache des Clients entfernt wurde. Benutzer können den ipconfig /flushdns Befehl auch an einer Eingabeaufforderung ausführen, um ihren DNS-Cache manuell zu löschen.

• Clients, die gestartet oder neu gestartet werden, führen beim Start eine DNS-Suche durch und erhalten die neue IP-Adresse für den Dienstendpunkt, bei dem es sich um einen Exchange-Server handelt, auf dem Clientzugriffsdienste ausgeführt werden, oder ein Clientzugriffsdienstearray im zweiten Rechenzentrum.

Unter der Annahme, dass alle geeigneten Konfigurationsänderungen abgeschlossen wurden, um die Dienste im zweiten Rechenzentrum so zu definieren und zu konfigurieren, dass sie wie im primären Rechenzentrum funktionieren, und unter der Annahme, dass die eingerichtete DNS-Konfiguration korrekt ist, sollten keine weiteren Änderungen erforderlich sein, um Clientzugriffsdienste zu aktivieren.

Aktivieren von Transportdiensten

Clients und sonstige Server, die Nachrichten übermitteln, identifizieren diese Server in der Regel mithilfe von DNS. Das Aktivieren von Transportdiensten im zweiten Datencenter umfasst das Ändern von DNS-Datensätzen in einer Weise, dass diese auf die IP-Adressen der Postfachserver im zweiten Datencenter verweisen. Clients und weitere sendende Server stellen dann auf zweierlei Art automatisch eine Verbindung mit den Servern im zweiten Datencenter her:

• Clients versuchen in regelmäßigen Abständen, eine Verbindung herzustellen, und sollten automatisch verbunden werden, nachdem die Gültigkeitsdauer für den ursprünglichen DNS-Eintrag abgelaufen ist und der Eintrag aus dem DNS-Cache des Clients entfernt wurde. Benutzer können den ipconfig /flushdns Befehl auch an einer Eingabeaufforderung ausführen, um ihren DNS-Cache manuell zu löschen.

• Clients führen beim Starten und Neustarten einen DNS-Suchvorgang aus und erhalten die neue IP-Adresse für den SMTP-Endpunkt (Simple Mail Transfer Protocol), der ein Postfachserver im zweiten Datencenter ist.

Wenn alle entsprechenden Konfigurationsänderungen durchgeführt wurden, um die Dienste im zweiten Datencenter so zu definieren und konfigurieren, dass sie wie im primären Datencenter ausgeführt werden, und wenn die eingerichtete DNS-Konfiguration korrekt ist, dann sollten keine weiteren Änderungen für die Aktivierung von Transportdiensten erforderlich sein.

Aktivieren von Unified Messaging-Diensten in Exchange 2016

Hinweis

Unified Messaging ist in Exchange 2019 nicht verfügbar.

Unified Messaging-Dienste (UM) in Exchange 2016 stellen eine Verbindung mit dem PBX-System und den Telefonleitungen einer Organisation her. Die logische Verbindung zwischen dem PBX-System und dem Unified Messaging-Dienst wird über ein IP-Gateway bereitgestellt. IP-Gateways bieten Funktionen für hohe Verfügbarkeit und können bei Auftreten eines Fehlers zwischen mehreren Unified Messaging-Diensten wechseln.

Wenn im zweiten Rechenzentrum Unified Messaging-Dienste vorhanden sind, die sich in einem deaktivierten Zustand befanden, Enable-UMService EX4da sie für die Standortresilienzlösung bestimmt sind, können sie mithilfe des Cmdlets Enable-UMService aktiviert werden (z. B. ).

Wenn die IP-Gateways mithilfe von DNS-Servern Unified Messaging-Dienste zugeordnet sind, müssen beim Aktivieren von Unified Messaging-Diensten DNS-Datensätze so geändert werden, dass diese auf die neuen IP-Adressen verweisen, die für die Unified Messaging-Dienst im zweiten Datencenter konfiguriert werden. Wenn alle entsprechenden Konfigurationsänderungen durchgeführt wurden, um die Dienste im zweiten Datencenter so zu definieren und konfigurieren, dass sie wie im primären Datencenter ausgeführt werden, und wenn die eingerichtete DNS-Konfiguration korrekt ist, dann sollten keine weiteren Änderungen für die Aktivierung von Unified Messaging-Diensten erforderlich sein.

Wenn das aktive IP-Gateway die Verwendung von DNS-Namen zum Auflösen der Unified Messaging-Dienste nicht unterstützt, sind zusätzliche manuelle Konfigurationsschritte erforderlich, damit das IP-Gateway auf die IP-Adressen der Unified Messaging-Dienste im zweiten Datencenter verweist.

Aktivieren von Edge-Transport-Servern

Die Schritte zum Aktivieren der Edge-Transport-Serverrolle variieren in Abhängigkeit von der jeweiligen Konfiguration. Edge-Transport-Server in zwei Datencentern können entweder in einer Aktiv/Passiv- oder einer Aktiv/Aktiv-Konfiguration konfiguriert werden. In einer Aktiv/Passiv-Konfiguration befindet sich der Edge-Transport-Server im zweiten Datencenter bis zur Aktivierung des zweiten Datencenters im Leerlauf. In einer Aktiv/Aktiv-Konfiguration stellen Edge-Transport-Server in beiden Datencentern jederzeit Mail zu.

In einer Aktiv/Aktiv-Konfiguration sind keine Schritte erforderlich, um die Edge-Transport-Server des zweiten Rechenzentrums zu aktivieren, da sie bereits ausgeführt werden. In einer Aktiv/Passiv-Konfiguration muss der DNS-MX-Ressourceneintrag für jede SMTP-Domäne im Rahmen des Wechsels vom primären Datencenter zum Standbyrechenzentrum aktualisiert werden. Obwohl die Aktiv/Aktiv-Konfiguration eine einfache Rechenzentrums-Switchover-Lösung bietet, hat sie den Nachteil, dass eine sorgfältige Lastüberwachung erforderlich ist, um sicherzustellen, dass die Edge-Transport-Server im zweiten Rechenzentrum genügend Kapazität bereitstellen können, um die erhöhte Last zu unterstützen, die jetzt durch das Rechenzentrum fließt, da die Edge-Transport-Server im primären Rechenzentrum nicht verfügbar sind.

Selbst bei einer Aktiv/Aktiv-Konfiguration ist es ratsam, die MX-Ressourcendatensätze für die Edge-Transport-Server während eines Datencenterswitchovers zu aktualisieren. Wenn der MX-Ressourcendatensatz für das ausgefallene Datencenter weiterhin auf das ausgefallene Datencenter verweist, könnte dieses bei der Wiederherstellung versuchen, eine Verbindung mit den zugeordneten Edge-Transport-Servern herzustellen. Dieser Fall kann eintreten, während Edge-Transport-Dienste instabil sind (z. B. weil die abhängigen Dienste im Datencenter wiederhergestellt werden).

Wenn die DNS-Datensätze der Kontrolle der Organisation unterliegen, muss beim Aktivieren der Edge-Transport-Server der MX-Ressourcendatensatz für jede SMTP-Domäne aktualisiert werden, die von dem Server gehostet wird.

Hinweis

Wenn der von Ihrer Organisation verwendete MX-Ressourcendatensatz nicht von einem der Kontrolle Ihrer Organisation unterliegenden DNS-Server gehostet wird, können Sie möglicherweise auf einen CNAME-Datensatz im MX-Ressourcendatensatz verweisen und dabei einen der Kontrolle Ihrer Organisation unterliegenden CNAME-Datensatz verwenden, der dann aktualisiert werden kann.

DNS-Updates lassen eingehenden Datenverkehr zu, und der ausgehende Datenverkehr wird über die Aktivierung von Postfachdatenbanken an einem Standort verwaltet, der über funktionsfähige Edge-Transport-Server verfügt:

• Wenn eingehende SMTP-Verbindungen mithilfe der aktualisierten Informationen zur Namensauflösung initiiert werden, stellen SMTP-Clients eine Verbindung mit den Edge-Transport-Servern im zweiten Datencenter her. Der Datenverkehr wird von den Edge-Transport-Servern entsprechend weitergeleitet, und es sind keine weiteren Änderungen erforderlich.

• Wenn ausgehende SMTP-Verbindungen initiiert werden, werden Verbindungsversuche mit dem lokal verfügbaren Edge-Transport-Server gestartet. Diese Nachrichten werden je nach Status des empfangenden Servers in der Warteschlange platziert oder sofort gesendet.

Wiederherstellen von Diensten im primären Datencenter

Im Allgemeinen sind Datencenterausfälle entweder temporär oder permanent. Bei einem permanenten Ausfall, z. B. einem Ereignis, das zu einer unwiderruflichen Zerstörung eines primären Datencenters geführt hat, sind die Chancen gering, dass das primäre Datencenter wieder aktiviert werden kann. Bei einem temporären Ausfall dagegen, z. B. einem längerfristigen Stromausfall oder weitreichenden, jedoch reparablen Schäden, ist die Möglichkeit einer vollständigen Wiederherstellung gegeben.

Der Prozess der Dienstwiederherstellung eines zuvor ausgefallenen Datencenters wird auch als Switchback bezeichnet. Die Schritte zur Ausführung eines Datencenterswitchbacks entsprechen den Schritten zur Ausführung eines Datencenterswitchovers. Ein bedeutender Unterschied besteht darin, dass Datencenterswitchbacks geplant sind und die Dauer des Ausfalls häufig deutlich kürzer ist.

Es ist wichtig, dass ein Switchback erst dann ausgeführt wird, wenn die Infrastrukturabhängigkeiten für Exchange reaktiviert wurden, stabil ausgeführt werden und überprüft wurden. Wenn diese Abhängigkeiten nicht verfügbar oder nicht fehlerfrei sind, ist die Wahrscheinlichkeit groß, dass der Switchbackprozess zu einem längeren Ausfall als notwendig führt, und es kann sein, dass der gesamte Vorgang fehlschlägt.

Switchback der Postfachserverrolle

Die Postfachserverrolle sollte die erste Rolle sein, für die ein Switchback zum primären Datencenter ausgeführt wird. Die folgenden Schritte erläutern ausführlich den Switchbackprozess der Postfachserverrolle:

1. Als Teil des Datencenterswitchovers wurden die Postfachserver im primären Datencenter beendet. Wenn die Umgebung (z. B. primäres Rechenzentrum, Exchange-Abhängigkeiten und WAN-Konnektivität) bereit ist, besteht der erste Schritt darin, die Postfachserver im wiederhergestellten primären Rechenzentrum in den Startzustand zu versetzen und in die DAG zu integrieren. Die für diesen Schritt erforderlichen Aktionen hängen davon ab, ob sich die Database Availability Group im Aktivierungsmodus der Datenbank befindet oder nicht.

   1. Wenn sich die Database Availability Group im Aktivierungsmodus der Datenbank befindet, können Sie die DAG-Mitglieder am primären Standort mithilfe des Cmdlets Start-DatabaseAvailabilityGroup erneut einbinden. Um sicherzustellen, dass das geeignete Quorummodell von der Database Availability Group verwendet wird, müssen Sie anschließend das Cmdlet Set-DatabaseAvailabilityGroup für die Database Availability Group ausführen, ohne hierbei Parameter anzugeben.

   2. Wenn sich die Database Availability Group nicht im Aktivierungsmodus der Datenbank befindet, können Sie die DAG-Mitglieder mithilfe des Cmdlets Add-DatabaseAvailabilityGroupServer erneut einbinden.

2. Nach der Integration der Postfachserver im primären Datencenter in die Database Availability Group wird die Synchronisierung der Datenbankkopien gestartet; dies kann einige Zeit dauern. In Abhängigkeit von der Art und Länge des Ausfalls und den vom Administrator während des Ausfalls getroffenen Maßnahmen kann ein erneutes Seeding der Datenbankkopien erforderlich sein. Wenn z. B. während des Ausfalls die Datenbankkopien aus dem ausgefallenen primären Datencenter entfernt wurden, um das Abschneiden der Protokolldateien für die noch aktiven Kopien im zweiten Datencenter zuzulassen, ist ein erneutes Seeding erforderlich. Jede Datenbank kann ab diesem Zeitpunkt einzeln fortgesetzt werden. Wenn eine replizierte Datenbankkopie im primären Datencenter fehlerfrei läuft, kann der nächste Schritt ausgeführt werden.

   Hinweis

   Dieser Prozess erfordert nicht, dass alle Datenbanken gleichzeitig verschoben werden. Es wird empfohlen, den Großteil der Datenbanken Ihrer Organisation gleichzeitig zu verschieben, aber einige Datenbanken verbleiben im zweiten Rechenzentrum, wenn Probleme im Zusammenhang mit den Datenbankkopien im primären Rechenzentrum auftreten.

3. Sobald die meisten Datenbanken im primären Datencenter fehlerfrei ausgeführt werden, kann der durch das Switchback bedingte Ausfall geplant werden. Tritt der geplante Zeitpunkt ein, müssen die folgenden Schritte ausgeführt werden:

   1. Während des Rechenzentrumswechselvorgangs wurde die DAG für die Verwendung eines alternativen Zeugenservers konfiguriert. Die DAG muss neu konfiguriert werden, um einen Zeugenserver im primären Rechenzentrum zu verwenden. Wenn Sie denselben Zeugenserver und dasselbe Zeugenverzeichnis verwenden, das vor dem Ausfall des primären Rechenzentrums verwendet wurde, können Sie den Set-DatabaseAvailabilityGroup -Identity DAGName Befehl ausführen. Wenn Sie planen, einen Zeugenserver oder ein Zeugenverzeichnis zu verwenden, das sich vom ursprünglichen Zeugenserver und -verzeichnis unterscheidet, verwenden Sie den Befehl Set-DatabaseAvailabilityGroup , um den Zeugenserver und die Zeugenverzeichnisparameter mit den entsprechenden Werten zu konfigurieren.

   2. Die Einbindung der im primären Datencenter reaktivierten Datenbanken muss im zweiten Datencenter aufgehoben werden. Mithilfe des Cmdlets Dismount-Database können Sie die Einbindung der Datenbanken aufheben.

   3. Nachdem die Bereitstellung der Datenbanken aufgehoben wurde, sollten die URLs der Server, auf denen Clientzugriffsdienste ausgeführt werden, vom zweiten Rechenzentrum in das primäre Rechenzentrum verschoben werden. Dies wird erreicht, indem der DNS-Eintrag für die URLs so geändert wird, dass er auf den Server oder das Array der Clientzugriffsdienste im primären Rechenzentrum verweist. Das System verhält sich so, als ob ein Datenbankfailover für jede verschobene Datenbank aufgetreten ist.

   Wichtig

   Fahren Sie erst mit dem nächsten Schritt fort, wenn die URLs für die Server, auf denen Clientzugriffsdienste ausgeführt werden, verschoben wurden und die DNS-TTL- und Cacheeinträge abgelaufen sind. Das Aktivieren der Datenbanken im primären Rechenzentrum vor dem Verschieben der URLs in das primäre Rechenzentrum führt zu einer ungültigen Konfiguration (z. B. zu einer eingebundenen Datenbank ohne Clientzugriffsdienste, die an ihrem Active Directory-Standort ausgeführt werden).

4. Da sich jede Datenbank im primären Datencenter in einem fehlerfreien Zustand befindet, kann sie im primären Datencenter durch das Ausführen von Datenbankswitchovern aktiviert werden. Verwenden Sie dazu das Cmdlet Move-ActiveMailboxDatabase für jede zu aktivierende Datenbank.

5. Nach dem Verschieben der Datenbanken in das primäre Datencenter können diese mithilfe des Cmdlets Mount-Database eingebunden werden.

Wenn mindestens eine Datenbank aktiv ist und im primären Datencenter bereitgestellt wird, kann der Switchbackvorgang für die weiteren Serverrollen ausgeführt werden.

Switchback für Clientzugriffsdienste

Im Rahmen des Umstellungsprozesses wurden die internen und externen DNS-Einträge, die von Clients, anderen Servern und IP-Gateways zum Auflösen der Dienstendpunkte für Clientzugriffsdienste, Transport- und Unified Messaging-Dienste und Edge-Transport-Server verwendet werden, so geändert, dass sie auf die entsprechenden Endpunkte im zweiten Rechenzentrum verweisen. Der Switchbackvorgang für die weiteren Serverrollen umfasst das Ändern dieser Datensätze dahin gehend, dass diese auf die wiederhergestellten Dienstendpunkte im primären Datencenter verweisen.

Ebenso wie bei den DNS-Änderungen, die während des Switchovers zum zweiten Datencenter vorgenommen wurden, versuchen Clients, Server und IP-Gateways weiterhin, eine Verbindung herzustellen. Diese Verbindung sollte automatisch bestehen, sobald die Gültigkeitsdauer des ursprünglichen DNS-Eintrags abgelaufen ist und sobald der Eintrag aus dem DNS-Cache entfernt wurde.

Wiederherstellen der Ausfallsicherheit

Nach dem erfolgreichen Switchback zum primären Datencenter können Sie dessen Ausfallsicherheit wiederherstellen, indem Sie die Integrität und den Status jeder Postfachdatenbankkopie im zweiten Datencenter überprüfen. Wenn Datenbankkopien im zweiten Datencenter ursprünglich nicht aktiviert werden konnten, können Sie diese Einstellungen nun wieder konfigurieren.