Database Availability Groups (DAGs)

  • Artikel

Eine Datenbankverfügbarkeitsgruppe (DAG) ist die Basiskomponente des Hochverfügbarkeits- und Standortresilienzframeworks des Postfachservers, das in Microsoft Exchange Server integriert ist. Eine DAG besteht aus bis zu 16 Postfachservern, die einen Gruppe von Datenbanken hosten und eine automatische Wiederherstellung auf Datenbankebene nach Fehlern bieten, die einzelne Server oder Datenbanken betreffen.

Wichtig

Auf allen Servern innerhalb einer DAG muss dieselbe Version von Exchange ausgeführt werden. Beispielsweise können Sie Exchange 2013-Server und Exchange 2016-Server nicht in derselben DAG kombinieren.

Eine DAG stellt eine Abgrenzung für die Replikation der Postfachdatenbank, für Datenbank- und Serverswitchover und für Failover sowie für eine interne Komponente namens Active Manager dar. Active Manager, der auf jedem Postfachserver ausgeführt wird, verwaltet Switchover und Failover in DAGs. Weitere Informationen zu Active Manager finden Sie in Active Manager.

Jeder Server in einer DAG kann als Host für eine Kopie einer Postfachdatenbank eines beliebigen anderen Servers in der DAG fungieren. Wenn einer DAG ein Server 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-, Server- oder Netzwerkfehler.

Hinweis

Weitere Informationen zum Erstellen von DAGs, zum Verwalten der DAG-Mitgliedschaft, zum Konfigurieren von DAG-Eigenschaften, zum Erstellen und Überwachen von Postfachdatenbankkopien und zum Durchführen eines Switchover finden Sie unter Verwalten von hoher Verfügbarkeit und Ausfallsicherheit für Standorte.

Lebenszyklus einer Database Availability Group

DAGs nutzen das Konzept der inkrementellen Bereitstellung, bei dem die Dienst- und Datenverfügbarkeit für alle Postfachserver und Datenbanken nach der Installation von Exchange bereitgestellt werden kann. Nachdem Sie Exchange Server Postfachserver bereitgestellt haben, können Sie eine DAG erstellen, postfachserver zur DAG hinzufügen und dann Postfachdatenbanken zwischen den DAG-Mitgliedern replizieren.

Hinweis

Es wird unterstützt, eine DAG zu erstellen, die eine Kombination aus physischen Postfachservern und virtualisierten Postfachservern enthält, vorausgesetzt, dass die Server und die Lösung die Exchange Server Systemanforderungen und die anforderungen erfüllen, die in Exchange Server Virtualisierung festgelegt sind. Wie bei allen Exchange-Hochverfügbarkeitskonfigurationen müssen Sie sicherstellen, dass alle Postfachserver in der DAG groß genug sind, um die erforderliche Arbeitslast während geplanter und ungeplanter Ausfälle zu verarbeiten.

Eine DAG wird mithilfe des Cmdlets New-DatabaseAvailabilityGroup erstellt. Eine DAG wird zunächst als leeres Objekt in Active Directory erstellt. Das Verzeichnisobjekt dient zum Speichern relevanter Informationen über die DAG, beispielsweise Servermitgliedschaftsinformationen und einige DAG-Konfigurationseinstellungen. Wenn Sie der DAG den ersten Server hinzufügen, wird automatisch ein Failovercluster für die DAG erstellt. Dieser Failovercluster wird ausschließlich von der DAG verwendet und muss ihr dediziert zugeordnet werden. Die Verwendung des Clusters für andere Zwecke wird nicht unterstützt.

Zusätzlich zur Erstellung eines Failoverclusters wird die Infrastruktur zur Überwachung der Server auf Netzwerk- oder Serverfehler initiiert. Der Failovercluster-Taktmechanismus und die Clusterdatenbank werden dann zum Verfolgen und Verwalten von Informationen zur DAG verwendet, die sich schnell ändern können, wie beispielsweise Datenbankeinbindungsstatus, Replikationsstatus und Standort der letzten Einbindung.

Während der Erstellung erhält die DAG einen eindeutigen Namen und ihr wird mindestens eine statische IP-Adresse zugeordnet, sofern sie nicht für die Verwendung von DHCP (Dynamic Host Configuration Protocol) konfiguriert wird oder ohne Cluster-Administratorzugriffspunkt erstellt wurde. DAGs ohne Administratorzugriffspunkt können nur auf Servern mit Exchange 2019, Exchange 2016 oder Exchange 2013 Service Pack 1 oder höher mit Windows Server 2012 R2 Standard- oder Datacenter-Edition erstellt werden. DAGs ohne Cluster-Administratorzugriffspunkt haben folgende Eigenschaften:

  • Es sind keine IP-Adressen zu Cluster/DAG zugewiesen, und daher befindet sich keine IP-Adressenressource in der Cluster-Hauptressourcengruppe.

  • Es ist kein Netzwerkname zum Cluster zugewiesen, und daher befindet sich keine Netzwerknamensressource in der Cluster-Hauptressourcengruppe

  • Der Name von Cluster/DAG ist nicht in DNS registriert, und kann innerhalb des Netzwerks nicht aufgelöst werden.

  • Ein Clusternamensobjekt (CNO) wird nicht in Active Directory erstellt.

  • Der Cluster kann nicht über die Failoverclusterverwaltung verwaltet werden. Er muss über Windows PowerShell verwaltet werden, und die PowerShell-Cmdlets müssen für die einzelnen Cluster-Mitglieder ausgeführt werden.

In diesem Beispiel wird gezeigt, wie über die Exchange-Verwaltungsshell eine DAG mit Cluster-Administratorzugriffspunkt erstellt werden kann, die drei Server hat. Zwei der Server (EX1 und EX2) befinden sich im selben Subnetz (10.0.0.0), der dritte Server (EX3) befindet sich in einem anderen Subnetz (192.168.0.0).

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

Die Befehle, um eine DAG ohne Cluster-Administratorzugriffspunkt zu erstellen, sind ähnlich:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress])::None
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

Der Cluster für DAG1 wird erstellt, wenn EX1 der DAG hinzugefügt wird. Während der Clustererstellung ruft das Cmdlet Add-DatabaseAvailabilityGroupServer die für die DAG konfigurierten IP-Adressen ab und ignoriert dabei alle Adressen, die nicht mit einem der Subnetze auf EX1 übereinstimmen. Im ersten Beispiel wird der Cluster für DAG1 mit der IP-Adresse 10.0.0.5 erstellt, die Adresse 192.168.0.5 wird ignoriert. Im zweiten Beispiel oben weist der Wert des DatabaseAvailabilityGroupIPAddresses-Parameters die Aufgabe an, ein Failovercluster für die DAG zu erstellen, die keinen Administratorzugriffspunkt hat. Daher wird der Cluster mit einer IP-Adresse oder Netzwerknamensressource in der Cluster-Hauptressourcengruppe erstellt.

Anschließend wird EX2 hinzugefügt, und das Cmdlet Add-DatabaseAvailabilityGroupServer ruft wieder die für die DAG konfigurierten IP-Adressen ab. Es gibt keine Änderungen an den IP-Adressen des Clusters, da EX2 sich im selben Subnetz befindet wie EX1.

Danach wird EX3 hinzugefügt, und das Cmdlet Add-DatabaseAvailabilityGroupServer ruft wieder die für die DAG konfigurierten IP-Adressen ab. Da ein Subnetz mit der Adresse 192.168.0.5 auf EX3 vorliegt, wird 192.168.0.5 als IP-Adressressource in der Clustergruppe hinzugefügt. Zusätzlich wird automatisch eine OR-Abhängigkeit für die Netzwerknamenressource jeder IP-Adressressource konfiguriert. Die Adresse 192.168.0.5 wird vom Cluster verwendet, wenn die Cluster-Hauptressourcengruppe auf EX3 verschoben wird.

für DAGs mit Cluster-Administratorzugriffspunkten werden beim Windows-Failoverclustering die IP-Adressen für den Cluster in DNS (Domain Name System) registriert, sobald die Netzwerknamensressource online geschaltet wird. Zudem wird ein Clusternamensobjekt (CNO) in Active Directory erstellt, wenn EX1 zum Cluster hinzugefügt wird. Netzwerkname, IP-Adresse(n) und CNO für den Cluster werden nicht für DAG-Funktionen verwendet. Administratoren und Endbenutzer müssen keine Verbindung zu dem Namen oder der IP-Adresse von Cluster/DAG herstellen. Einige Anwendungen von Drittanbietern stellen eine Verbindung mit dem Administratorzugriffspunkt des Clusters her, um Verwaltungsaufgaben wie Sicherung oder Überwachung auszuführen. Wenn Sie keine Anwendungen von Drittanbietern verwenden, die einen Administratorzugriffspunkt für Cluster erfordern, und Ihre DAG Exchange 2016 oder Exchange 2019 auf Windows Server 2012 R2 ausführt, empfiehlt es sich, eine DAG ohne Administratorzugriffspunkt zu erstellen. Dies vereinfacht die DAG-Konfiguration, verhindert, dass eine oder mehrere IP-Adressen benötigt werden, und reduziert die Angriffsoberfläche einer DAG.

DAGs sind zudem für die Verwendung eines Zeugenservers und eines Zeugenverzeichnisses konfiguriert. Der Zeugenserver und das Zeugenverzeichnis werden entweder automatisch durch das System konfiguriert oder können manuell vom Administrator konfiguriert werden. In den Beispielen oben wird EX4 (ein Server, der kein Mitglied der DAG ist und dies nicht werden wird) manuell als Zeugenserver der DAG konfiguriert.

Standardmäßig ist eine DAG so konzipiert, dass sie das integrierte Feature für die fortlaufende Replikation verwendet, um Postfachdatenbanken zwischen Servern in der DAG zu replizieren. Wenn Sie die Datenreplikation eines Drittanbieters verwenden, die die Replikations-API von Drittanbietern in Exchange Server unterstützt, müssen Sie die DAG im Replikationsmodus eines Drittanbieters erstellen, indem Sie das Cmdlet New-DatabaseAvailabilityGroup mit dem Parameter ThirdPartyReplication verwenden. Nachdem dieser Modus aktiviert wurde, kann er nicht mehr deaktiviert werden.

Nachdem die DAG erstellt wurde, können ihr Postfachserver hinzugefügt werden. Wenn der DAG der erste Server hinzugefügt wurde, wird ein Cluster für die DAG gebildet. Für DAGs wird die Windows-Failoverclusteringtechnologie genutzt, so etwa der Clustertakt, Clusternetzwerke und die Clusterdatenbank (zum Speichern von Daten, die sich ändern, beispielsweise Änderungen des Datenbankzustands von "Aktiv" nach "Passiv" oder umgekehrt oder von "Eingebunden" nach "Nicht eingebunden" und umgekehrt). Wird der DAG ein weiterer Server hinzugefügt, wird dieser in den zugrunde liegenden Cluster eingebunden (wobei das Quorummodell des Clusters automatisch von Exchange angepasst wird), und der Server wird dem DAG-Objekt in Active Directory hinzugefügt.

Nachdem Postfachserver einer DAG hinzugefügt wurden, können Sie verschiedene DAG-Eigenschaften konfigurieren, beispielsweise die Verwendung von Netzwerkverschlüsselung oder Netzwerkkomprimierung für die Datenbankreplikation innerhalb der DAG. Sie können außerdem DAG-Netzwerke konfigurieren und zusätzliche DAG-Netzwerke erstellen.

Nachdem Sie einer DAG Mitglieder hinzugefügt und die DAG konfiguriert haben, können die aktiven Postfachdatenbanken auf jedem Server auf die anderen DAG-Mitgliedern repliziert werden. Nach dem Erstellen von Postfachdatenbankkopien können Sie die Integrität und den Status der Kopien mithilfe einer Vielzahl integrierter Überwachungstools überwachen. Zusätzlich können Sie Datenbank- und Serverswitchover durchführen.

Quorummodelle für Database Availability Groups

Unterhalb jeder DAG befindet sich ein Windows-Failovercluster. Failovercluster verwenden das Konzept des Quorums, bei dem ein Konsens der Wähler verwendet wird, um sicherzustellen, dass nur eine Teilmenge der Clustermitglieder (was alle Mitglieder oder eine Mehrheit von Mitgliedern bedeuten könnte) gleichzeitig funktioniert. Quorum ist kein neues Konzept für Exchange Server. Hochverfügbare Postfachserver in früheren Versionen von Exchange verwenden auch Failoverclustering und dessen Quorumkonzept. Quorum stellt eine freigegebene Ansicht von Mitgliedern und Ressourcen dar, und der Begriff Quorum wird auch verwendet, um die physischen Daten zu beschreiben, die die Konfiguration innerhalb des Clusters darstellen, die von allen Clustermitgliedern gemeinsam genutzt wird. Daher erfordern alle DAGs, dass ihr zugrunde liegender Failovercluster über ein Quorum verfügt. Wenn der Cluster das Quorum verliert, werden alle DAG-Vorgänge beendet, und die Bereitstellung aller eingebundenen Datenbanken, die in der DAG gehostet werden, wird aufgehoben. In diesem Fall ist ein Administratoreingriff erforderlich, um das Quorumproblem zu beheben und DAG-Vorgänge wiederherzustellen.

Das Quorum dient zum Sicherstellen von Konsistenz, zum Lösen von Konflikten zur Vermeidung von Aufteilungen und zum Gewährleisten der Reaktionsfähigkeit des Clusters:

  • Sicherstellen der Konsistenz: Eine Hauptanforderung für einen Windows-Failovercluster ist, dass jedes Mitglied immer über eine Ansicht des Clusters verfügt, die mit den anderen Mitgliedern konsistent ist. Die Clusterstruktur dient als definitiver Datenspeicher aller Konfigurationsinformationen zum Cluster. Wenn die Clusterstruktur für ein DAG-Mitglied nicht lokal geladen werden kann, wird der Clusterdienst nicht gestartet, da er nicht gewährleisten kann, dass das Mitglied die Anforderung einer Ansicht des Clusters erfüllt, die mit den anderen Mitgliedern konsistent ist.

  • Als Tie-Breaker: Eine Quorumzeugenressource wird in DAGs mit einer geraden Anzahl von Mitgliedern verwendet, um Split Brain-Syndrom-Szenarien zu vermeiden und sicherzustellen, dass nur eine Sammlung der Mitglieder in der DAG als offiziell gilt. When the witness server is needed for quorum, any member of the DAG that can communicate with the witness server can place a Server Message Block (SMB) lock on the witness server's witness.log file. Das DAG-Mitglied, das den Zeugenserver sperrt (als Sperrknoten bezeichnet), behält eine zusätzliche Stimme für Quorumzwecke bei. The DAG members in contact with the locking node are in the majority and maintain quorum. Any DAG members that can't contact the locking node are in the minority and therefore lose quorum.

  • Sicherstellen der Reaktionsfähigkeit: Um die Reaktionsfähigkeit sicherzustellen, stellt das Quorummodell sicher, dass bei jeder Ausführung des Clusters genügend Mitglieder des verteilten Systems betriebsbereit und kommunikativ sind und mindestens ein Replikat des aktuellen Zustands des Clusters garantiert werden kann. Es ist kein weiterer Aufwand erforderlich, um Mitglieder in Kommunikation miteinander zu bringen oder festzustellen, ob ein bestimmtes Replikat garantiert ist.

DAGs with an even number of members use the failover cluster's Node and File Share Majority quorum mode, which employs an external witness server that acts as a tie-breaker. In this quorum mode, each DAG member gets a vote. In addition, the witness server is used to provide one DAG member with a weighted vote (for example, it gets two votes instead of one). The cluster quorum data is stored by default on the system disk of each member of the DAG, and is kept consistent across those disks. However, a copy of the quorum data isn't stored on the witness server. A file on the witness server is used to keep track of which member has the most updated copy of the data, but the witness server doesn't have a copy of the cluster quorum data. In this mode, a majority of the voters (the DAG members plus the witness server) must be operational and able to communicate with each other to maintain quorum. If a majority of the voters can't communicate with each other, the DAG's underlying cluster loses quorum, and the DAG will require administrator intervention to become operational again. Weitere Informationen finden Sie unter Rechenzentrumswechsel und Restore-DatabaseAvailabilityGroup.

DAGs with an odd number of members use the failover cluster's Node Majority quorum mode. In this mode, each member gets a vote, and each member's local system disk is used to store the cluster quorum data. If the configuration of the DAG changes, that change is reflected across the different disks. The change is only considered to have been committed and made persistent if that change is made to the disks on half the members (rounding down) plus one. For example, in a five-member DAG, the change must be made on two plus one members, or three members total.

Das Quorum erfordert, dass eine Mehrheit der Wähler miteinander kommunizieren kann. Angenommen, eine DAG hat vier Mitglieder. Da diese DAG eine gerade Mitgliederanzahl umfasst, wird einem der Clustermitglieder von einem externer Zeugenserver eine fünfte Stimme zum Lösen von Konflikten bereitgestellt. Um eine Mehrheit der Wähler (und demzufolge das Quorum) zu erhalten, müssen mindestens drei Wähler miteinander kommunizieren können. Maximal zwei Wähler können offline sein, ohne dass der Dienst- und Datenzugriff unterbrochen wird. Wenn drei oder mehr Wähler offline sind, verliert die DAG das Quorum, sodass der Dienst- und Datenzugriff so lange unterbrochen wird, bis das Problem behoben ist.