Bereitstellen von Hochverfügbarkeit und Standortresilienz in Exchange Server

Microsoft Exchange Server verwendet das Konzept der inkrementellen Bereitstellung für Hochverfügbarkeit und Standortresilienz. Sie installieren einfach zwei oder mehr Exchange-Postfachserver als eigenständige Server und konfigurieren sie dann nach Bedarf inkrementell und Postfachdatenbanken für Hochverfügbarkeit und Standortresilienz.

Übersicht über den Bereitstellungsprozess

Während die tatsächlichen Schritte, die von jeder Organisation verwendet werden, geringfügig variieren können, ist der Allgemeine Prozess für die Bereitstellung von Exchange Server in einer hochverfügbaren oder standortresilienten Konfiguration im Allgemeinen identisch. Nachdem Sie die notwendigen Planungs- und Entwicklungsaufgaben zum Erstellen und Bereitstellen einer Database Availability Group (DAG) ausgeführt und Postfachdatenbankkopien erstellt haben, gehen Sie wie folgt vor:

1. Erstellen Sie eine DAG. Weitere Informationen finden Sie unter Erstellen einer Datenbankverfügbarkeitsgruppe. Es ist wichtig zu beachten, dass auf allen Servern innerhalb einer DAG dieselbe Version von Exchange ausgeführt werden muss. Beispielsweise können Sie Exchange 2013- und Exchange 2016-Server nicht in derselben DAG kombinieren.

2. Stellen Sie bei Bedarf das Clusternamenobjekt (Cluster Name Object, CNO) vorab bereit. Beim Bereitstellen einer DAG mit Postfachservern, die Windows Server 2012 ausgeführt werden, ist das Vorab-Staging des CNO erforderlich. Wenn Sie eine DAG ohne Administratorzugriffspunkt mithilfe von Postfachservern bereitstellen, die Windows Server 2012 R2 ausgeführt werden, müssen Sie keinen CNO vorab bereitstellen. Pre-Staging ist auch in Umgebungen erforderlich, in denen die Erstellung von Computerkonten eingeschränkt ist oder in denen Computerkonten in einem anderen Container als dem Standardcomputercontainer erstellt werden. Genaue Anweisungen finden Sie unter Provisorische Bereitstellung des Clusternamenobjekts für eine Database Availability Group.

3. Fügen Sie der DAG mindestens zwei Postfachserver hinzu. Weitere Informationen finden Sie unter Verwalten der Mitgliedschaft in DAGs.

4. Konfigurieren Sie die Eigenschaften der DAG nach Bedarf:

5. Konfigurieren Sie optional Verschlüsselung und Komprimierung, Replikationsport, IP-Adressen und sonstige Eigenschaften für die DAG. Weitere Informationen finden Sie unter Konfigurieren der Eigenschaften einer DAG.

6. Aktivieren Sie den DAC-Modus (Datacenter Activation Coordination) für die DAG. Dies schützt die DAG vor Split Brain-Bedingungen auf Datenbankebene, wenn ein Datencenterswitchover durchgeführt und die Verwendung der integrierten Cmdlets zur DAG-Wiederherstellung aktiviert wurde. Weitere Informationen finden Sie unter Datencenter-Aktivierungsmodus.

7. Fügen Sie den Postfachservern in der DAG Postfachdatenbankkopien hinzu. Weitere Informationen finden Sie unter Hinzufügen einer Kopie einer Postfachdatenbank.

Bereitstellungsbeispiel: DAG mit vier Mitgliedern in zwei Datencentern

In diesem Beispiel wird erläutert, wie eine Organisation, Contoso, Ltd., eine DAG mit vier Mitgliedern konfiguriert und bereitstellt, die auf zwei physische Standorte erweitert wird: Boston und Oklahoma City.

Basisinfrastruktur

Jeder Standort enthält die Infrastrukturelemente, die erforderlich sind, um eine Messaginginfrastruktur basierend auf Exchange Server zu betreiben, nämlich:

• Verzeichnisdienste (Active Directory oder Active Directory-Domänendienste (Active Directory Domain Services, AD DS))

• DNS-Namensauflösung (Domain Name System)

• Mehrere Exchange-Server, auf denen Clientzugriffsdienste ausgeführt werden

• Mehrere Exchange-Postfachserver

In der folgenden Abbildung wird die Contoso-Konfiguration dargestellt.

Netzwerkkonfiguration

Wie aus der obigen Abbildung hervorgeht, beinhaltet die Lösung mehrere Subnetze und mehrere Netzwerke. Jeder Postfachserver in der DAG verfügt über zwei Netzwerkkarten in separaten Subnetzen. Auf jedem Postfachserver wird ein Netzwerkadapter für das MAPI-Netzwerk verwendet (192.168. x. x) und ein Netzwerkadapter wird für das Replikationsnetzwerk (10.0) verwendet. x. x). Die Verbindung zu Active Directory, DNS-Diensten sowie sonstigen Exchange-Servern und -Clients wird nur über das MAPI-Netzwerk hergestellt. Der Adapter, der bei jedem Mitglied der DAG für das Replikationsnetzwerk verwendet wird, stellt nur die Verbindung zu den Replikationsnetzwerkadaptern der anderen Mitglieder bereit.

Die Einstellungen für die einzelnen Netzwerkadapter in jedem Knoten gehen aus der folgenden Tabelle hervor.

Wie aus der obigen Tabelle hervorgeht, werden bei den für die Replikationsnetzwerke verwendeten Adaptern keine Standardgateways verwendet. Für die Netzwerkverbindung zwischen den einzelnen Replikationsnetzwerkkarten verwendet Contoso ein dauerhaftes statisches Routing, das mithilfe des Tools "Netsh.exe" konfiguriert wird.

Für die Routingkonfiguration für die Replikationsnetzwerkkarte auf "MBX1" und "MBX2" wurde auf jedem Server der folgende Befehl ausgeführt.

netsh interface ipv4 add route 10.0.2.0/24 <NetworkName> 10.0.1.254

Für die Routingkonfiguration für die Replikationsnetzwerkkarte auf "MBX3" und "MBX4" wurde auf jedem Server der folgende Befehl ausgeführt.

netsh interface ipv4 add route 10.0.1.0/24 <NetworkName> 10.0.2.254

Außerdem wurden die folgenden weiteren Netzwerkeinstellungen konfiguriert:

• Das Kontrollkästchen Adressen dieser Verbindung in DNS registrieren wurde bei den MAPI-Netzwerkadaptern aller DAG-Mitglieder aktiviert und bei allen Replikationsnetzwerkadaptern deaktiviert.

• Mindestens eine DNS-Serveradresse ist für den MAPI-Netzwerkadapter jedes DAG-Mitglieds konfiguriert, und keine für die Replikationsnetzwerkadapter. Aus Redundanzgründen verwendet Contoso mehrere DNS-Serveradressen für seine MAPI-Netzwerkadapter.

• Die Windows-Firewall wird von Contoso nicht verwendet. Sie wurde auf den Servern deaktiviert.

Nach der Konfiguration der Netzwerkadapter kann Contoso jetzt eine DAG erstellen und ihr Postfachserver hinzufügen.

Erstellen und Konfigurieren einer Database Availability Group (DAG)

Der Administrator hat sich für die Erstellung eines Windows PowerShell-Befehlszeilenskripts entschieden, mit dem mehrere Aufgaben ausgeführt werden:

• Mithilfe des Cmdlets New-DatabaseAvailabilityGroup wird die DAG erstellt. Da BOSTON als primäres Rechenzentrum gilt, hat sich Contoso für die Verwendung eines Zeugenservers im selben Rechenzentrum entschieden, nämlich MBX5.

• Mithilfe des Cmdlets Set-DatabaseAvailabilityGroup werden ein alternativer Zeugenserver und ein alternatives Zeugenverzeichnis vorkonfiguriert, die bei einem evtl. erforderlichen Datencenterswitchover zum Einsatz kommen.

• Mithilfe des Cmdlets Add-DatabaseAvailabilityGroupServer werden der DAG alle vier Postfachserver hinzugefügt.

• Mithilfe des Cmdlets Set-DatabaseAvailabilityGroup wird die DAG für den DAC-Modus konfiguriert. Weitere Informationen zum DAC-Modus finden Sie unter Datencenter-Aktivierungsmodus.

Die folgenden Befehle werden im Skript verwendet:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer MBX5 -WitnessDirectory C:\DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8

Der obige Befehl erstellt das DAG DAG1, konfiguriert MBX5 als Zeugenserver, konfiguriert ein bestimmtes Zeugenverzeichnis (C:\DAGWitness\DAG1.contoso.com) und zwei IP-Adressen für die DAG (eine für jedes Subnetz im MAPI-Netzwerk).

Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer MBX10

Der obige Befehl konfiguriert DAG1 für die Verwendung eines alternativen Zeugenservers von MBX10 und eines alternativen Zeugenverzeichnisses auf MBX10, das denselben Pfad verwendet, der für MBX5 konfiguriert wurde.

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX3
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX4

Mit den obigen Befehlen wird der DAG jeweils ein Postfachserver hinzugefügt. Mit diesen Befehlen wird auch die Failoverclusteringkomponente von Windows auf jedem Postfachserver installiert (falls noch nicht geschehen), ein Failovercluster erstellt und jeder Postfachserver mit dem neu erstellten Cluster verbunden.

Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

Mit dem obigen Befehl wird für die DAG der DAC-Modus aktiviert.

Postfachdatenbanken und Postfachdatenbankkopien

Nachdem Contoso die DAG erstellt und ihr die Postfachserver hinzugefügt hat, wird die Erstellung der Postfachdatenbanken und Postfachdatenbankkopien vorbereitet. Damit die internen Kriterien für die Ausfallsicherheit erfüllt werden, plant Contoso, jede Postfachdatenbank mit drei unverzögerten Datenbankkopien und einer verzögerten Datenbankkopie zu konfigurieren. Für die verzögerte Kopie soll eine Protokollwiedergabeverzögerung von drei Tagen konfiguriert werden.

Mit dieser Konfiguration werden für jede Datenbank insgesamt vier Kopien (eine aktive, zwei unverzögerte passive und eine verzögerte passive Kopie) bereitgestellt. Contoso hat pro Server vier aktive Datenbanken vorgesehen. Daher enthält die Contoso-Lösung insgesamt 16 Datenbankkopien.

Wie aus der folgenden Abbildung hervorgeht, hat sich Contoso hinsichtlich des Datenbanklayouts für einen ausgewogenen Ansatz entschieden.

Datenbankkopien - Layout für Contoso, Ltd

Auf jedem Postfachserver befinden sich eine aktive Postfachdatenbankkopie, zwei unverzögerte passive Datenbankkopien und eine verzögerte passive Datenbankkopie. Die verzögerten Kopien der aktiven Postfachdatenbanken werden auf einem Postfachserver am anderen Standort gehostet.

Zum Erstellen dieser Konfiguration muss der Administrator mehrere Befehle ausführen.

Auf "MBX1":

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -SuspendComment "Seed from MBX4" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX3 -SourceServer MBX4
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -ActivationOnly

Auf "MBX2":

Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX4 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -SuspendComment "Seed from MBX3" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX4 -SourceServer MBX3
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -ActivationOnly

Auf "MBX3":

Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -SuspendComment "Seed from MBX2" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1 -SourceServer MBX2
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -ActivationOnly

Auf "MBX4":

Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -SuspendComment "Seed from MBX1" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2 -SourceServer MBX1
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -ActivationOnly

In den vorherigen Beispielen für das Cmdlet Add-MailboxDatabaseCopy wurde der Parameter ActivationPreference nicht angegeben. Der Task inkrementiert automatisch bei jeder hinzugefügten Kopie die Aktivierungseinstellungsnummer. Die Originaldatenbank hat immer die Einstellungsnummer 1. Die erste mithilfe des Cmdlets Add-MailboxDatabaseCopy hinzugefügte Kopie erhält automatisch die Einstellungsnummer 2. Unter der Annahme, dass keine Kopien entfernt wurden, wird der nächsten hinzugefügten Kopie automatisch die Einstellungsnummer 3 zugeordnet usw. Daher hat in den obigen Beispielen die passive Kopie, die sich im selben Datencenter wie die aktive Kopie befindet, die Aktivierungseinstellungsnummer 2; die unverzögerte passive Kopie im Remotedatencenter hat die Aktivierungseinstellungsnummer 3 und die verzögerte passive Kopie im Remotedatencenter die Aktivierungseinstellungsnummer 4.

Obwohl es zwei Kopien von jeder aktiven Datenbank im WAN (Wide Area Network, Fernnetz) am anderen Standort gibt, erfolgte der Seedingvorgang nur einmal. Dies liegt daran, dass Contoso die Exchange Server Möglichkeit nutzt, eine passive Kopie einer Datenbank als Quelle für das Seeding zu verwenden. Die Verwendung des Cmdlets Add-MailboxDatabaseCopy mit dem Parameter SeedingPostponed verhindert, dass der Task automatisch ein Seeding für die neue Datenbankkopie erstellt. Anschließend kann der Administrator die Kopie ohne Seeding anhalten, und mithilfe des Cmdlets Update-MailboxDatabaseCopy mit dem SourceServer-Parameter kann der Administrator die lokale Kopie der Datenbank als Quelle des Seedingvorgangs angeben. Dadurch erfolgt der Seedingvorgang für die zweite Datenbankkopie, die jedem Standort hinzugefügt wird, lokal und nicht über das WAN.

Zum Schutz vor einer äußerst selten vorkommenden Beschädigung der Datenbanklogik, die katastrophale Folgen haben kann, hat Contoso eine passive Kopie jeder Postfachdatenbank als verzögerte Datenbankkopie konfiguriert. Daher konfiguriert der Administrator die verzögerten Kopien mithilfe des Suspend-MailboxDatabaseCopy-Cmdlets mit dem Parameter ActivationOnly als blockiert für die Aktivierung. Dadurch wird sichergestellt, dass die verzögerten Datenbankkopien bei einem Datenbank- oder Serverfailover nicht aktiviert werden.

Überprüfen der Lösung

Nach Bereitstellung und Konfiguration der Lösung führt der Administrator mehrere Aufgaben aus, anhand denen er die Lösung auf ihre Funktionsfähigkeit überprüft, bevor Produktionspostfächer in die Datenbanken in der DAG verschoben werden. Die Lösung sollte anhand mehrerer Methoden, einschließlich Fehlersimulationen, getestet und überprüft werden. Zum Überprüfen der Lösung führt der Administrator verschiedene Aufgaben aus.

Der Administrator führt das Cmdlet Test-ReplicationHealth aus, um den allgemeinen Status der DAG zu überprüfen. Mit diesem Cmdlet werden Replikations- und Wiedergabestatus unter verschiedenen Aspekten überprüft und Informationen zu jedem Postfachserver und jeder Datenbankkopie in der DAG bereitgestellt.

Zum Überprüfen von Replikations- und Wiedergabeaktivität führt der Administrator das Cmdlet Get-MailboxDatabaseCopyStatus aus. Dieses Cmdlet stellt Statusinformationen in Echtzeit zu einer bestimmten Postfachdatenbankkopie oder zu allen Postfachdatenbankkopien auf einem bestimmten Server bereit. Weitere Informationen zum Überwachen der Integrität und des Status replizierter Datenbanken in einer DAG finden Sie unter Überwachen von Datenbankverfügbarkeitsgruppen.

Zum Überprüfen, ob Switchover erwartungsgemäß funktionieren, führt der Administrator mithilfe des Cmdlets Move-ActiveMailboxDatabase eine Reihe von Datenbank- und Serverswitchovern durch. Nachdem diese Aufgaben erfolgreich durchgeführt wurden, verschiebt der Administrator mithilfe desselben Cmdlets die aktiven Datenbankkopien wieder an ihre ursprünglichen Speicherorte.

Zum Überprüfen des erwartungsgemäßen Verhaltens in verschiedenen Fehlerszenarien führt der Administrator mehrere Aufgaben aus, mit denen entweder Fehler simuliert oder tatsächlich verursacht werden. Der Administrator kann beispielsweise Folgendes tun:

• "MBX1" vom Stromnetz trennen (Stecker ziehen), wodurch ein Serverfailover ausgelöst wird. Der Administrator kann dann überprüfen, ob "DB1" auf einem anderen Server (vorzugsweise "MBX2" gemäß den Aktivierungseinstellungsnummern) aktiviert wird.

• Den MAPI-Netzwerkadapter auf "MBX2" vom Stromnetz trennen (Stecker ziehen), wodurch ein Serverfailover ausgelöst wird. Der Administrator kann dann überprüfen, ob "DB2" auf einem anderen Server (vorzugsweise "MBX1" gemäß den Aktivierungseinstellungsnummern) aktiviert wird.

• Die von der aktiven Kopie von DB3 verwendete Festplatte offline schalten, wodurch ein Datenbankfailover ausgelöst wird. Der Administrator kann dann überprüfen, ob "DB3" auf einem anderen Server (vorzugsweise "MBX4" gemäß den Aktivierungseinstellungsnummern) aktiviert wird.

Je nach den geschäftlichen Anforderungen kann es noch weitere Fehlerszenarien geben, die in einer Organisation getestet werden. Nach der Simulation eines einzelnen Fehlers (z. B. Stecker ziehen) und der Überprüfung des Wiederherstellungsverhaltens der Lösung kann der Administrator die Lösung auf die ursprüngliche Konfiguration zurücksetzen. In einigen Fällen kann die Lösung auf mehrere gleichzeitige Fehler getestet werden. Letztlich gibt der Lösungsprüfplan vor, ob die Lösung nach jeder Fehlersimulation auf die ursprüngliche Konfiguration zurückgesetzt wird.

Außerdem kann der Administrator auch die Netzwerkverbindung zwischen den beiden Datencentern trennen und so den Ausfall eines Standorts simulieren. Ein Datencenterswitchover ist ein Prozess, der sehr viel mehr Überlegungen und Koordination verlangt; er wird jedoch empfohlen, wenn die bereitgestellte Lösung Ausfallsicherheit von Standorten für Messagingdienste und Daten bieten soll.

Inbetriebnahme

Nachdem die Lösung bereitgestellt wurde, kann sie über die inkrementelle Bereitstellung erweitert werden. An diesem Punkt erfolgt auch hinsichtlich der Verwaltung der Lösung eine Umstellung auf die Betriebsprozesse, bei denen die folgenden Aufgaben ausgeführt werden:

• Überwachen des Status der DAGs und Postfachdatenbankkopien. Weitere Informationen finden Sie unter Überwachen von Datenbankverfügbarkeitsgruppen.

• Führen Sie nach Bedarf Datenbankswitchover durch. Genaue Anweisungen zum Durchführen eines Datenbankswitchovers finden Sie unter Aktivieren einer Kopie einer Postfachdatenbank.

Weitere Informationen zum Verwalten der Lösung finden Sie unter Verwalten von hoher Verfügbarkeit und Ausfallsicherheit für Standorte.