Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
GILT FÜR:
2016 2019 Subscription Edition
Microsoft Exchange Server verwendet das Konzept der inkrementellen Bereitstellung für Hochverfügbarkeit und Standortresilienz. Sie installieren 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 den einzelnen organization 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:
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.
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.If you're deploying a DAG without an administrative access point using Mailbox servers running Windows Server 2012 R2, you don't need to stage a CNO. 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.
Fügen Sie der DAG mindestens zwei Postfachserver hinzu. Weitere Informationen finden Sie unter Verwalten der Mitgliedschaft in DAGs.
Konfigurieren Sie die Eigenschaften der DAG nach Bedarf:
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.
Aktivieren Sie den DAC-Modus (Datacenter Activation Coordination) für die DAG. Diese Aktion hat die folgenden Vorteile:
- Schützt die DAG vor geteilten Gehirnbedingungen auf Datenbankebene während des Wechsels zum primären Rechenzentrum nach einem Wechsel des Rechenzentrums.
- Ermöglicht die Verwendung der integrierten DAG-Wiederherstellungs-Cmdlets.
Weitere Informationen finden Sie unter Datencenter-Aktivierungsmodus.
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 Contoso, Ltd. eine DAG mit vier Mitgliedern konfiguriert und bereitstellt, die über zwei physische Standorte erweitert wurde: 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). Nur das MAPI-Netzwerk bietet Konnektivität mit Active Directory, DNS-Diensten, anderen Exchange-Servern und Clients. 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.
| Name | IPv4-Adresse | Subnetzmaske | Standardgateway |
|---|---|---|---|
| MBX1 (MAPI) | 192.168.1.4 | 255.255.255.0 | 192.168.1.1 |
| MBX2 (MAPI) | 192.168.1.5 | 255.255.255.0 | 192.168.1.1 |
| MBX3 (MAPI) | 192.168.2.4 | 255.255.255.0 | 192.168.2.1 |
| MBX4 (MAPI) | 192.168.2.5 | 255.255.255.0 | 192.168.2.1 |
| MBX1 (Replikation) | 10.0.1.4 | 255.255.255.0 | Keine |
| MBX2 (Replikation) | 10.0.1.5 | 255.255.255.0 | Keine |
| MBX3 (Replikation) | 10.0.2.4 | 255.255.255.0 | Keine |
| MBX4 (Replikation) | 10.0.2.5 | 255.255.255.0 | Keine |
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
Die folgenden Netzwerkeinstellungen werden ebenfalls 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.
Contoso verwendet die Windows-Firewall nicht, sodass sie auf ihren Servern deaktiviert wurde.
Nachdem die Netzwerkadapter konfiguriert wurden, ist Contoso bereit, eine DAG zu erstellen und die Postfachserver der DAG hinzuzufügen.
Erstellen und Konfigurieren einer Database Availability Group (DAG)
Der Administrator hat beschlossen, ein Windows PowerShell Skript für die Befehlszeilenschnittstelle zu erstellen, das mehrere Aufgaben ausführt:
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 mit den folgenden Einstellungen:
- Verwenden Sie MBX10 als alternativen Zeugenserver.
- Verwenden Sie ein alternatives Zeugenverzeichnis auf MBX10 mit demselben Pfad wie MBX5.
Tipp
Die Verwendung desselben Pfads ist nicht erforderlich. Contoso verwendet denselben Pfad, um die Konfiguration zu standardisieren.
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX3
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX4
Die vorherigen Befehle führen die folgenden Aktionen aus:
- Fügen Sie jeden Postfachserver einzeln zur DAG hinzu.
- Installieren Sie die Komponente Windows-Failoverclustering auf jedem Postfachserver (sofern noch nicht installiert).
- Erstellen Sie einen Failovercluster.
- Verbinden Sie jeden Postfachserver mit dem neu erstellten Cluster.
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. Die verzögerte Kopie weist eine konfigurierte Protokollwiedergabeverzögerung von drei Tagen auf.
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 obigen Add-MailboxDatabaseCopy-Beispielen haben wir den Parameter ActivationPreference nicht verwendet, da die Aufgabe die Aktivierungseinstellungsnummer automatisch erhöht, wenn jede Kopie hinzugefügt wird:
- Die Originaldatenbank hat immer die Einstellungsnummer 1.
- Der ersten hinzugefügten Kopie wird automatisch die Einstellungsnummer 2 zugewiesen.
- Wenn keine Kopien entfernt werden, wird der nächsten hinzugefügten Kopie automatisch die Einstellungsnummer 3 zugewiesen usw.
In den obigen Add-MailboxDatabaseCopy-Beispielen :
- Die passive Kopie im selben Rechenzentrum wie die aktive Kopie hat die Aktivierungspräferenznummer 2.
- Die nicht verzögerte passive Kopie im Remoterechenzentrum hat die Aktivierungspräferenznummer 3.
- Die verzögerte passive Kopie im Remoterechenzentrum hat die Aktivierungspräferenznummer 4.
Obwohl es zwei Kopien von jeder aktiven Datenbank im WAN (Wide Area Network, Fernnetz) am anderen Standort gibt, erfolgte der Seedingvorgang nur einmal. Contoso nutzt die Exchange Server Möglichkeit, 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.
- Der Administrator kann die kopie ohne Seeding anhalten.
- 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.
Hinweis
Im vorherigen Beispiel wird die nicht verzögerte Datenbankkopie über das WAN als Seeding ausgeführt. Diese Kopie wird verwendet, um ein Seeding für die verzögerte Kopie der Datenbank im selben Rechenzentrum wie die nicht verzögerte Kopie durchzuführen.
Contoso hat eine der passiven Kopien jeder Postfachdatenbank als verzögerte Datenbankkopie konfiguriert, um Schutz vor dem äußerst seltenen, aber katastrophalen Fall logischer Datenbankbeschädigungen zu bieten. Daher konfiguriert der Administrator die verzögerten Kopien mithilfe des Suspend-MailboxDatabaseCopy-Cmdlets mit dem Parameter ActivationOnly als blockiert für die Aktivierung. Diese Konfiguration stellt sicher, dass die verzögerten Datenbankkopien bei einem Datenbank- oder Serverfailover nicht aktiviert werden.
Überprüfen der Lösung
Nachdem die Lösung bereitgestellt und konfiguriert wurde, führt der Administrator mehrere Aufgaben aus, die die Bereitschaft der Lösung überprüfen, 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 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. Wenn diese Aufgaben erfolgreich abgeschlossen wurden, verwendet der Administrator dasselbe Cmdlet, um die aktiven Datenbankkopien wieder an ihre ursprünglichen Speicherorte zu verschieben.
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:
Trennen Sie das Netzkabel von MBX1, 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.
Trennen Sie das Netzwerkkabel für den MAPI-Netzwerkadapter auf MBX2, 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.
Schalten Sie den Datenträger, der von der aktiven Kopie von DB3 verwendet wird, offline, 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.
Ein organization kann basierend auf den geschäftsbezogenen Anforderungen andere Fehlerszenarien testen. Nach der Simulation eines einzelnen Fehlers (z. B. durch Ziehen des Netzsteckers) und dem Überprüfen des Wiederherstellungsverhaltens der Lösung kann der Administrator die Lösung wieder auf die ursprüngliche Konfiguration rückgängig machen. In einigen Fällen kann die Lösung auf mehrere gleichzeitige Fehler getestet werden. Letztendlich bestimmt Ihr Lösungstestplan, ob die Lösung nach jeder Fehlersimulation auf ihre ursprüngliche Konfiguration zurückgesetzt wird.
Darüber hinaus kann ein Administrator entscheiden, die Netzwerkverbindung zwischen den beiden Rechenzentren zu trennen, wodurch ein Standortausfall simuliert wird. 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 mithilfe der inkrementellen Bereitstellung weiter 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.