Hochverfügbarkeit und Standortresilienz in Exchange Server

Sie können Ihre Exchange Server Postfachdatenbanken und die darin enthaltenen Daten schützen, indem Sie Ihre Exchange-Server und -Datenbanken für Hochverfügbarkeit und Standortresilienz konfigurieren. Exchange Server minimiert die Kosten und Die Komplexität der Bereitstellung einer hochverfügbaren und resilienten Messaginglösung und bietet gleichzeitig ein hohes Maß an Dienst- und Datenverfügbarkeit und Unterstützung für sehr große Postfächer.

Exchange Server ermöglicht Kunden aller Größen und in allen Segmenten die wirtschaftliche Bereitstellung eines Messagingkontinuitätsdiensts in ihrer Organisation, indem sie auf den nativen Replikationsfunktionen und der Hochverfügbarkeitsarchitektur aufbauen, die in Exchange 2010 eingeführt wurden. Eine Liste der Änderungen seit Exchange 2010 finden Sie unter Änderungen bei hoher Verfügbarkeit und Ausfallsicherheit im Vergleich zu früheren Versionen.

Wichtige Terminologie

Nachfolgend werden die wichtigsten Begriffe zum Verständnis von Hochverfügbarkeit und Ausfallsicherheit von Standorten erläutert:

Active Manager

Eine interne Exchange-Komponente, die im Microsoft Exchange-Replikationsdienst ausgeführt wird. Sie überwacht die Umgebung auf Ausfälle und führt Korrekturmaßnahmen aus, indem ein Failover innerhalb einer Database Availability Group (DAG) durchgeführt wird.

AutoDatabaseMountDial

Eine Eigenschafteneinstellung eines Postfachservers, die basierend auf der Anzahl von fehlenden Protokolldateien für die einzubindende Kopie festlegt, ob eine passive Datenbankkopie automatisch als neue aktive Kopie eingebunden wird.

Fortlaufende Replikation – Blockmodus

Im Blockmodus wird beim Schreiben jeder Aktualisierung in den aktiven Protokollpuffer der aktiven Datenbankkopie diese auch in einen Protokollpuffer aller passiven Postfachkopien übertragen. Sobald der Protokollpuffer voll ist, führt jede Datenbankkopie eine Überprüfung durch und erstellt dann die nächste Protokolldatei in der Generierungssequenz.

Fortlaufende Replikation – Dateimodus

Im Dateimodus werden geschlossene Transaktionsprotokolldateien von der aktiven Datenbankkopie per Pushvorgang in eine oder mehrere passive Datenbankkopien kopiert.

Database Availability Group (DAG)

Eine Gruppe von bis zu 16 Exchange-Servern, die eine Gruppe replizierter Datenbanken hosten.

Datenbankmobilität

Die Möglichkeit eines Exchange Server Postfachdatenbank, auf anderen Exchange-Servern repliziert und eingebunden zu werden.

Datacenter

In der Regel bezieht sich dieser Begriff auf einen Active Directory-Standort, es kann jedoch auch ein physischer Standort gemeint sein. Im Rahmen dieser Dokumentation entspricht ein Datencenter einem Active Directory-Standort.

Datencenter-Aktivierungsmodus

Eine Eigenschaft der DAG-Einstellung, die bei Aktivierung erzwingt, dass der Microsoft Exchange-Replikationsdienst Berechtigungen zum Einbinden von Datenbanken beim Start erwirbt.

Notfallwiederherstellung

Jeder Prozess zur manuellen Wiederherstellung nach einem Ausfall. Dies kann ein Ausfall sein, der ein einzelnes Element betrifft, oder ein Ausfall, der sich auf einen gesamten physischen Standort auswirkt.

Exchange-API für die Drittanbieterreplikation

Eine mit Exchange bereitgestellte API, welche die Verwendung von Drittanbieterprodukten für die synchrone Replikation von DAGs anstelle einer fortlaufenden Replikation ermöglicht.

Hohe Verfügbarkeit

Eine Lösung, die Dienstverfügbarkeit, Datenverfügbarkeit und eine automatische Wiederherstellung nach Ausfällen sicherstellt, die sich auf den Dienst oder Daten auswirken (z. B. Netzwerk-, Speicher- oder Serverausfall).

Inkrementelle Bereitstellung

Die Möglichkeit, Hochverfügbarkeit und Standortresilienz bereitzustellen, nachdem Exchange Server installiert wurde.

Verzögerte Postfachdatenbankkopie

Eine passive Postfachdatenbankkopie, für die eine Wiedergabeverzögerung größer null festgelegt ist.

Postfachdatenbankkopie

Eine Postfachdatenbank (EDB-Datei und Protokolle), die entweder aktiv oder passiv ist.

Ausfallsicherheit von Postfächern

Der Name einer einheitlichen Lösung für Hochverfügbarkeit und Standortresilienz in Exchange Server.

Verwaltete Verfügbarkeit

Ein Satz interner Prozesse bestehend aus Tests, Monitoren und Antwortdiensten, die Überwachung und Hochverfügbarkeit für alle Serverrollen und sämtliche Protokolle bereitstellen.

*over (ausgesprochen "star over")

Abkürzung für Switchover und Failover. Ein Switchover ist die manuelle Aktivierung einer oder mehrerer Datenbankkopien. Ein Failover ist die automatische Aktivierung einer oder mehrerer Datenbankkopien nach einem Ausfall.

Sicherheitsnetz

Früher als Transportspeicherspeicher bezeichnet, ist dies ein Feature des Transportdiensts, der eine Kopie aller Nachrichten für X Tage speichert. Die Standardeinstellung beträgt 2 Tage.

Shadow-Redundanz

Ein Transportserverfeature, das Redundanz für Nachrichten bietet, während diese übertragen werden.

Ausfallsicherheit von Standorten

Eine Konfiguration, mit der die Messaginginfrastruktur auf mehrere Active Directory-Standorte ausgeweitet wird, um bei einem Ausfall einer der Standorte einen unterbrechungsfreien Betrieb für das Messagingsystem zu gewährleisten.

Database Availability Groups (DAGs)

Eine DAG ist die Basiskomponente des Frameworks für Hochverfügbarkeit und Standortresilienz, das in Exchange Server integriert ist. Eine DAG ist eine Gruppe von bis zu 16 Exchange-Servern, die eine Gruppe von Datenbanken hosten und eine automatische Wiederherstellung auf Datenbankebene nach Fehlern ermöglicht, die sich auf einzelne Datenbanken, Netzwerke oder Server auswirken. Jeder Server in einer DAG kann als Host für eine Kopie einer Postfachdatenbank eines beliebigen anderen Servers in der DAG fungieren. Wenn ein Server einer DAG hinzugefügt wird, wird dieser mit den anderen Servern in der DAG eingesetzt, um eine automatische Wiederherstellung nach Fehlern zu bieten, die Postfachdatenbanken betreffen, z. B. Datenträger- oder Serverfehler. Weitere Informationen zu DAGs finden Sie unter Database availability groups.

Postfachdatenbankkopien

Die in Exchange 2010 eingeführten Features für Hochverfügbarkeit und Standortresilienz werden in Exchange Server zum Erstellen und Verwalten von Datenbankkopien verwendet. Exchange Server nutzt auch das Konzept der Datenbankmobilität, bei dem es sich um Von Exchange verwaltete Failover auf Datenbankebene handelt.

Im Rahmen der Datenbankmobilität werden Datenbanken von Servern getrennt und Unterstützung für bis zu 16 Kopien einer einzelnen Datenbank hinzugefügt. Zudem wird eine systemeigene Umgebung für das Erstellen von Kopien einer Datenbank bereitgestellt.

Das Festlegen einer Datenbankkopie als aktive Postfachdatenbank wird als Switchover bezeichnet. Wenn ein Fehler auftritt, der eine Datenbank oder den Zugriff auf eine Datenbank beeinträchtigt, und eine neue Datenbank als aktive Kopie festgelegt wird, wird dieser Vorgang als Failover bezeichnet. Dieser Vorgang bezieht sich auch auf einen Serverausfall, bei dem ein oder mehrere Server die Datenbank online schalten, die sich zuvor auf dem ausgefallenen Server befunden hat. Wenn entweder ein Switchover oder ein Failover erfolgt, werden andere Exchange-Server fast sofort auf die Umstellung aufmerksam und leiten Client- und Messagingdatenverkehr an die neue aktive Datenbank um.

Wenn beispielsweise eine aktive Datenbank in einer DAG aufgrund eines zugrunde liegenden Speicherfehlers fehlschlägt, wird Active Manager automatisch wiederhergestellt, indem ein Failover auf eine Datenbankkopie auf einem anderen Server in der DAG ausgeführt wird. In Exchange Server bietet die verwaltete Verfügbarkeit Verhalten zur Wiederherstellung nach dem Verlust des Protokollzugriffs auf eine Datenbank, einschließlich Wiederverwendung von Anwendungs-Workerpools, Neustarten von Diensten und Servern und Initiieren von Datenbankfailovern.

Weitere Informationen zu Postfachdatenbankkopien finden Sie unter Postfachdatenbankkopien.

Active Manager

Exchange Server nutzt Active Manager, um die Integrität, den Status, die fortlaufende Replikation und andere Aspekte der Hochverfügbarkeit von Datenbank- und Datenbankkopien zu verwalten. Weitere Informationen zu Active Manager finden Sie in Active Manager.

Ausfallsicherheit von Standorten

In Exchange 2010 konnten Sie eine DAG über zwei Datencenter hinweg bereitstellen, den Zeugenserver in einem dritten Datencenter hosten und ein Failover für die Postfachserverrolle für beide Datencenter aktivieren. Sie haben jedoch kein Failover für die Lösung selbst erhalten, da der Namespace für die Nicht-Postfachserverrollen noch manuell geändert werden musste.

In Exchange 2016 und Exchange 2019 muss der Namespace nicht mit der DAG verschoben werden. Exchange nutzt die integrierte Fehlertoleranz des Namespace über mehrere IP-Adressen, Lastenausgleich (und, sofern erforderlich, die Fähigkeit zur Inbetriebnahme und Außerbetriebnahme von Servern). Moderne HTTP-Clients arbeiten automatisch mit dieser Redundanz. Der HTTP-Stack kann mehrere IP-Adressen für einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) akzeptieren, und wenn die erste IP-Adresse dauerhaft ausfällt (d. h. eine Verbindung nicht möglich ist), wird die nächste IP-Adresse in der Liste verwendet. Bei einem temporären Fehler (Verbindungsverlust nach dem Einrichten einer Sitzung, beispielsweise aufgrund eines zeitweiligen Fehlers im Dienst, bei dem ein Gerät Pakete verliert und außer Betrieb genommen werden muss), muss der Benutzer möglicherweise den Browser aktualisieren.

Dies bedeutet, dass der Namespace nicht länger eine einzelne Fehlerquelle ist, wie dies in Exchange 2010 der Fall war. In Exchange 2010 ist die womöglich größte einzelne Fehlerquelle im Messagingsystem der Benutzern zugewiesene FQDN, da er die Zieladresse angibt. Im Exchange 2010-Paradigma ist eine Änderung des FQDN-Ziels nicht einfach, da Sie die DNS-Einstellungen ändern und die DNS-Wartezeit berücksichtigen müssen, die in einigen Teilen der Erde sehr hoch liegt. Außerdem werden in Browsern Namencaches verwendet, die Daten typischerweise für 30 Minuten oder mehr zwischenspeichern, und dieser Tatsache muss Rechnung getragen werden.

In Exchange Server haben Clients mehr als eine Anlaufstelle. Fast alle Clientzugriffsprotokolle in Exchange Server sind HTTP-basiert. Beispiele sind Outlook, EAS, EWS, Outlook im Web und EAC. Alle unterstützten HTTP-Clients können mehrere IP-Adressen verwenden, was ein Failover auf Clientseite ermöglicht. 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 der an den Client zurückgegebenen IP-Adressen können jedoch zuverlässig verwenden werden. Dies verbessert den Clientbetrieb, da dem Client bei einem Ausfall einer der IP-Adressen alternative IP-Adressen zur Verbindungsherstellung zur Verfügung stehen. 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 also die VIP für das Clientzugriffsdienst-Array ausfällt, wird innerhalb von etwa 21 Sekunden eine automatische Clientwiederherstellung durchgeführt.

Hierdurch bieten sich folgende Vorteile:

• Wenn Sie Exchange Server den Lastenausgleich an Ihrem primären Standort verlieren, deaktivieren Sie ihn einfach (oder deaktivieren Sie die VIP), und reparieren oder ersetzen Sie ihn. Clients, die die VIP noch nicht im sekundären Datencenter verwenden, führen automatisch ein Failover auf die sekundäre VIP ohne Änderung des Namespaces und ohne Änderung des DNS aus. Dies bedeutet nicht nur, dass Sie keine Umstellung mehr durchführen müssen, sondern auch, dass die gesamte Zeit, die normalerweise mit einer Rechenzentrums-Switchoverwiederherstellung verbunden ist, nicht aufgewendet wird. In Exchange 2010 mussten Sie die DNS-Latenz verarbeiten (daher die Empfehlung, die Gültigkeitsdauer auf 5 Minuten festzulegen, und die Einführung der Failback-URL). In Exchange 2016 und Exchange 2019 müssen Sie dies nicht tun, da Sie ein schnelles Failover (20 Sekunden) des Namespace zwischen VIPs (Rechenzentren) erhalten.

• Da Sie ein Failover für den Namespace zwischen Rechenzentren ausführen können, ist alles, was für ein Rechenzentrumsfailover erforderlich ist, ein Mechanismus für das Failover der Postfachserverrolle über mehrere Rechenzentren hinweg. Um ein automatisches Failover für die DAG zu erhalten, erstellen Sie einfach 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. Wenn Sie nur über zwei Rechenzentren verfügen und ein dritter physischer Standort nicht verfügbar ist, können Sie den Zeugenserver auf einem virtuellen Microsoft Azure-Computer platzieren. Weitere Informationen finden Sie unter Verwenden einer Microsoft Azure-VM als DAG-Zeugenserver .

• In diesem Szenario beschränken sich die Aufgaben des Administrators darauf, das vorliegende Problem zu lösen, eine Dienstwiederherstellung ist nicht erforderlich. Sie korrigieren lediglich die fehlerhafte Komponente, während der Dienst weiter ausgeführt und die Datenintegrität aufrechterhalten wird. Der Termindruck und der Stress bei der Reparatur eines beschädigten Geräts sind nicht zu vergleichen mit dem Termindruck und dem Stress, der mit der Wiederherstellung eines Diensts einhergeht. Das bedeutet Vorteile für den Endbenutzer und weniger Stress für den Administrator.

Sie können ein Failover durchführen, ohne Switchbacks auszuführen (gelegentlich fälschlich als Failbacks bezeichnet). Wenn Sie Server im primären Datencenter verlieren, was zu einer 20 Sekunden dauernden Dienstunterbrechung für die Clients führt, müssen Sie sich möglicherweise noch nicht einmal Gedanken über ein Failback machen. Zu diesem Zeitpunkt besteht Ihre Hauptsorge darin, das Kernproblem zu lösen (z. B. das ausgefallene Lastenausgleichsmodul zu ersetzen). Nachdem die Komponente wieder online und betriebsbereit ist, beginnen einige Clients damit, die Komponente erneut zu nutzen, und andere Clients nehmen Dienste über das zweite Datencenter in Anspruch.

Exchange Server bietet auch Funktionen, mit denen Administratoren zeitweilige Fehler behandeln können. Ein zeitweiliger Fehler ist beispielsweise eine Situation, in der die anfängliche TCP-Verbindung hergestellt werden kann, dann jedoch ein Stillstand eintritt. Ein zeitweise auftretender Fehler erfordert einigen zusätzlichen Verwaltungsaufwand, da er das Ergebnis der Inbetriebnahme eines Ersatzgeräts sein kann. Während der Reparatur wird das Gerät möglicherweise eingeschaltet und akzeptiert einige Anforderungen, kann jedoch nicht wirklich für die Verarbeitung von Dienstanforderungen durch Clients verwendet werden, bis die erforderlichen Konfigurationsschritte ausgeführt wurden. In diesem Szenario kann der Administrator einen Namespaceswitchover durchführen, indem einfach die VIP für das im Austausch befindliche Gerät aus der DNS-Konfiguration entfernt wird. Dies führt dazu, dass Clients während der Wartungsphase nicht versuchen, eine Verbindung mit dem Gerät herzustellen. Nachdem der Austausch abgeschlossen wurde, kann der Administrator die VIP wieder in die DNS-Konfiguration einfügen, und Clients können das Gerät wieder verwenden.

Ausführliche Informationen zum Planen und Bereitstellen von Standortresilienz finden Sie unter Planen von Hochverfügbarkeit und Standortresilienz und Bereitstellen von Hochverfügbarkeit und Standortresilienz.

API für die Drittanbieterreplikation

Exchange Server enthält eine Replikations-API eines Drittanbieters, mit der Organisationen synchrone Replikationslösungen von Drittanbietern anstelle der integrierten Funktion für die fortlaufende Replikation verwenden können. Microsoft unterstützt Drittanbieterlösungen, die diese API verwenden, sofern die Lösung die benötigte Funktionalität bereitstellt, um sämtliche systemeigene Funktionalität für die fortlaufende Replikation zu ersetzen, die als Ergebnis der Verwendung der API deaktiviert ist. Lösungen werden nur unterstützt, wenn die API in einer DAG zum Verwalten und Aktivieren von Postfachdatenbankkopien verwendet wird. Die Verwendung der API darüber hinaus wird nicht unterstützt. Außerdem muss die Lösung die geltenden Supportanforderungen für Windows-Hardware erfüllen. (Für Support ist keine Testvalidierung erforderlich.)

Beachten Sie beim Bereitstellen einer Lösung, die die integrierte Replikations-API von Drittanbietern verwendet, dass der Lösungsanbieter für die primäre Unterstützung der Lösung verantwortlich ist. Microsoft unterstützt Exchange-Daten sowohl für replizierte als auch für nicht replizierte Lösungen. Lösungen, die die Datenreplikation verwenden, müssen der Microsoft-Supportrichtlinie für die Datenreplikation entsprechen. Darüber hinaus müssen Lösungen, die das Windows-Failoverclusterressourcenmodell verwenden, die Anforderungen an die Unterstützung von Windows-Clustern erfüllen, wie im Microsoft Knowledge Base-Artikel 943984, Die Microsoft-Support-Richtlinie für Windows Server 2008- oder Windows Server 2008 R2-Failovercluster oder die Microsoft-Support-Richtlinie für Windows Server 2012 Failovercluster.

Die Supportrichtlinie für Sicherung und Wiederherstellung von Microsoft für Bereitstellungen mit Replikations-API-basierten Drittanbieterlösungen entspricht der Richtlinie für systemeigene Bereitstellungen der fortlaufenden Replikation.

Wenn Sie ein Partner sind, der nach Informationen zur Drittanbieter-API sucht, wenden Sie sich an Ihren Ansprechpartner bei Microsoft.

Dokumentation zu Hochverfügbarkeit und Ausfallsicherheit für Standorte

Die folgende Tabelle enthält Links zu Themen, die Ihnen helfen, sich über DAGs, Postfachdatenbankkopien und Sicherung und Wiederherstellung für Exchange Server zu informieren und zu verwalten.

Thema	Beschreibung
Database Availability Groups	Hier erhalten Sie Informationen zu DAGs, Active Manager, DAC-Modus (Datacenter Activation Coordination) und Postfachdatenbankkopien.
Planen von Hochverfügbarkeit und Standortresilienz	Hier erhalten Sie Informationen zu den allgemeinen Anforderungen und den Anforderungen für Hardware, Netzwerk, Zeugenserver und zu den bewährten Methoden für DAGs.
Bereitstellen der hohen Verfügbarkeit und Ausfallsicherheit von Standorten	Hier können Sie ein Beispielszenario für die Bereitstellung und Konfiguration von DAGs untersuchen.
Verwalten von hoher Verfügbarkeit und Ausfallsicherheit für Standorte	Hier erhalten Sie Informationen zu Verwaltungsaufgaben in Bezug auf DAGs, zu Switchover- und Failovervorgängen sowie zum Wartungsmodus.
Überwachen von Datenbankverfügbarkeitsgruppen	Hier erhalten Sie Informationen zu den integrierten Cmdlets und Skripts für die Überwachung von DAGs und Datenbankkopien.
Sicherung, Wiederherstellung und Notfallwiederherstellung	Hier erhalten Sie Informationen zur Sicherung und Wiederherstellung von Exchange-Datenbanken und Wiederherstellungsdatenbanken sowie zur Serverwiederherstellung.