Database Availability Groups (DAGs)

Gilt für: Exchange Server 2013

Erfahren Sie mehr über Exchange DAG in Exchange Server 2013. In diesem Artikel wird der Lebenszyklus von Datenbankverfügbarkeitsgruppen (DAG) sowie die Verwendung einer DAG für Hochverfügbarkeit und Standortresilienz erläutert.

Eine Database Availability Group (DAG) ist die Basiskomponente des Frameworks für Postfachserver für hohe Verfügbarkeit und Ausfallsicherheit für Standorte in Microsoft Exchange Server 2013. 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.

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.

Lebenszyklus von Datenbankverfügbarkeitsgruppen (DAG)

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 2013-Postfachserver bereitgestellt haben, können Sie eine DAG erstellen, der DAG Postfachserver hinzufügen und dann Postfachdatenbanken zwischen den DAG-Mitgliedern replizieren.

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 Cluster-Administratorzugriffspunkt können nur auf Servern erstellt werden, auf denen Exchange 2013 Service Pack 1 oder neuer auf Windows Server 2012 R2 Standard oder Datacenter Edition ausgeführt wird. 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 Shell 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 Clusteradministratorzugriffspunkt erfordern, und Ihre DAG Exchange 2013 SP1 oder höher 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 Drittanbieterreplikations-API in Exchange 2013 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.

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.

Dag-Quorummodelle (Database Availability Group, Datenbankverfügbarkeitsgruppe)

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 2013. 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.

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.

Verwenden einer Datenbankverfügbarkeitsgruppe (DAG) für Hochverfügbarkeit

Um zu veranschaulichen, wie eine DAG Hochverfügbarkeit für Ihre Postfachdatenbanken bereitstellen kann, sehen Sie sich das folgende Beispiel an, das eine DAG mit fünf Mitgliedern verwendet. Diese DAG wird in der folgenden Abbildung veranschaulicht.

In der vorherigen Abbildung sind die grünen Datenbanken aktive Postfachdatenbankkopien und die blauen Datenbanken passive Postfachdatenbankkopien. In diesem Beispiel werden die Datenbankkopien nicht auf jedem Server gespiegelt, sondern auf mehrere Server verteilt. Dadurch wird sichergestellt, dass keine zwei Server in der DAG über denselben Satz von Datenbankkopien verfügen, was der DAG eine höhere Resilienz gegenüber Fehlern bietet, einschließlich Fehlern, die auftreten, während andere Komponenten aufgrund regelmäßiger Wartungen nicht verfügbar sind.

Im folgenden Szenario wird anhand der zuvor genannten Beispiel-DAG die Ausfallsicherheit im Falle verschiedener Datenbank- und Serverfehler veranschaulicht.

Anfänglich sind alle Datenbanken und Server fehlerfrei. Sie müssen einige Betriebssystemupdates auf EX2 installieren, damit Sie den Server in den Wartungsmodus versetzen. Dies führt zu einem Serverwechsel, der die Kopie von DB4 auf einem anderen Postfachserver aktiviert. Ein Serverwechsel verschiebt alle aktiven Postfachdatenbankkopien von ihrem aktuellen Server auf einen oder mehrere andere Postfachserver in der DAG, um einen geplanten Ausfall für den aktuellen Server vorzubereiten. In diesem Beispiel gibt es nur eine aktive Postfachdatenbank auf EX2 (DB4), sodass nur eine aktive Postfachdatenbankkopie verschoben wird.

Während Sie die Wartungsarbeiten auf EX2 durchführen, kommt es auf EX3 zu einem schweren Hardwarefehler, sodass EX3 offline geht. Vor dem Ausfall von EX3 wurde die aktive Kopie von DB2 gehostet. Zur Wiederherstellung aktiviert das System innerhalb von 30 Sekunden automatisch die Kopie von DB2, die auf EX1 gehostet wird. Dieser Vorgang wird in der folgenden Abbildung dargestellt.

Nachdem die geplanten Wartungsarbeiten auf EX2 abgeschlossen wurden, schalten Sie den Server wieder online und nehmen ihn aus dem Wartungsmodus. Sobald EX2 wieder verfügbar ist, werden die weiteren Mitglieder der DAG benachrichtigt, und die Kopien von DB1, DB4 und DB5, die auf EX2 gehostet werden, werden automatisch mit der aktiven Kopie jeder Datenbank synchronisiert. Dieser Vorgang wird in der folgenden Abbildung dargestellt.

Nachdem die ausgefallene Hardwarekomponente auf EX3 durch eine neue Komponente ersetzt wurde, wird EX3 online geschaltet. Sobald EX3 wieder verfügbar ist, werden die weiteren Mitglieder der DAG benachrichtigt, und die auf EX3 gehostet Kopien von DB2, DB3 und DB4 werden automatisch mit der aktiven Kopie jeder Datenbank synchronisiert. Dieser Vorgang wird in der folgenden Abbildung dargestellt.

Verwenden einer Datenbankverfügbarkeitsgruppe (DAG) für Standortresilienz

Zusätzlich zur Bereitstellung einer hohen Verfügbarkeit innerhalb eines Datencenters kann eine DAG auch auf ein oder mehrere Datencenter in einer Konfiguration ausgeweitet werden, die Ausfallsicherheit für ein oder mehrere Datencentern bietet. In den vorherigen Beispielabbildungen befindet sich die DAG in einem einzelnen Datencenter und an einem einzelnen Active Directory-Standort. Durch inkrementelle Bereitstellung kann diese DAG auf ein zweites Datencenter (und einen zweiten Active Directory-Standort) ausgeweitet werden, indem ein Postfachserver und die nötigen unterstützenden Ressourcen (mindestens ein Active Directory-Server sowie DNS-Dienste) bereitgestellt werden. Anschließend wird der Postfachserver, wie in der folgenden Abbildung dargestellt, der DAG hinzugefügt.

In diesem Beispiel wird eine passive Kopie jeder aktiven Datenbank im Datencenter Redmond auf EX6 im Datencenter Dublin konfiguriert. Es gibt jedoch zahlreiche andere Beispiele für DAG-Konfigurationen, die für Ausfallsicherheit sorgen. Beispiel:

• Anstatt nur passive Datenbankkopien zu hosten, kann EX6 alle aktiven Kopien oder eine Kombination aus aktiven und passiven Kopien hosten.

• Zusätzlich zu EX6 können mehrere DAG-Mitglieder im Datencenter Dublin bereitgestellt werden, um weiteren Ausfallschutz zu bieten. Diese Konfiguration bietet zudem weitere Kapazität, sodass bei einem Ausfall des Datencenters Redmond das Datencenter Dublin weitaus mehr Benutzer unterstützen kann.

Verwenden mehrerer Datenbankverfügbarkeitsgruppen (DAGs) für Standortresilienz

Im vorherigen Beispiel wurde eine DAG auf mehrere Datencenter ausgedehnt, um Ausfallsicherheit für ein oder beide Datencenter zu bieten. Bei Verwenden einer einzelnen DAG zum Bereitstellen von Ausfallsicherheit in einer Umgebung, in der jedes Datencenter, auf das Sie die DAG ausdehnen, einen aktiven Benutzerbestand hat, stellt die WAN-Verbindung eine einzelne Fehlerquelle dar. Aus diesem Grund erfordert das Quorum, dass eine Mehrheit der Wähler aktiv ist und miteinander kommunizieren kann.

Im vorherigen Beispiel befindet sich die Mehrheit der Wähler im Datencenter Redmond. Wenn das Datencenter Dublin aktive Postfachdatenbanken hostet und über einen lokalen Benutzerbestand verfügt, führt ein WAN-Ausfall zum Ausfall des Messagingsdiensts für die Benutzer in Dublin. Bei Unterbrechung der WAN-Verbindung behalten nur die DAG-Mitglieder im Datencenter Redmond das Quorum und stellen den Messagingdienst weiter zur Verfügung.

Zum Vermeiden, dass das WAN eine einzelne Fehlerquelle darstellt, wenn Sie Ausfallsicherheit für mehrere Datencenter mit aktivem Benutzerbestand bereitstellen müssen, ist es erforderlich, mehrere DAGs bereitzustellen, wobei jede DAG über eine Mehrheit der Wähler in einem separaten Datencenter verfügt. Bei einem WAN-Ausfall wird die Replikation so lange blockiert, bis die Verbindung wiederhergestellt ist. Die Benutzer können den Messagingdienst nutzen, da jede DAG weiter für ihren lokalen Benutzerbestand aktiv ist.