Grundlegendes zu Database Availability Groups

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2015-03-09

Eine Database Availability Group (DAG) ist die Basiskomponente des Frameworks für hohe Verfügbarkeit und Ausfallsicherheit für Standorte in Microsoft Exchange Server 2010. 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, für Failover sowie für eine interne Exchange 2010-Komponente namens Active Manager dar. Der auf jedem Server in einer DAG ausgeführte Active Manager verwaltet Switchover- und Failovervorgänge. Weitere Informationen zu Active Manager finden Sie in Grundlegendes zu 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- oder Serverfehler.

Inhalt

Lebenszyklus einer Database Availability Group

Verwenden einer Database Availability Group für hohe Verfügbarkeit

Verwenden einer DAG zum Bereitstellen von Ausfallsicherheit für Standorte

Clientumgebung bei Verwenden von Database Availability Groups

Lebenszyklus einer Database Availability Group

DAGs nutzen eine Funktion von Exchange 2010, die als inkrementelle Bereitstellung bezeichnet wird. Hierbei handelt es sich um die Fähigkeit, die Dienst- und Datenverfügbarkeit für alle Postfachserver und Datenbanken bereitstellen zu können, nachdem Exchange installiert wurde. Nach der Bereitstellung von Exchange 2010 können Sie eine DAG erstellen, dieser Postfachserver hinzufügen und anschließend Postfachdatenbanken zwischen den DAG-Mitgliedern replizieren.

Hinweis

Es ist möglich, eine DAG zu erstellen, die eine Kombination aus physischen Postfachservern und virtualisierten Postfachservern enthält, sofern die Server und die Lösung den Exchange 2010 – Systemanforderungen entsprechen. 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. Dieses Verzeichnisobjekt wird verwendet, um relevante Informationen über die DAG zu speichern, z. B. Servermitgliedschaftsinformationen. 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. Sie können eine einzelne IP-Adresse oder eine durch Komma getrennte Liste mit IP-Adressen angeben, indem Sie den Parameter DatabaseAvailabilityGroupIPAddresses verwenden.

In diesem Beispiel wird eine DAG mit drei Servern gezeigt. 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 -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

Hinweis

Wenn Sie den Parameter DatabaseAvailabilityGroupIPAddresses mit dem Wert 0.0.0.0 konfigurieren, verwendet die DAG (Cluster) DHCP für ihre IP-Adressen oder IP-Adressressourcen.

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. In diesem Beispiel wird der Cluster für DAG1 mit der IP-Adresse 10.0.0.5 erstellt, die Adresse 192.168.0.5 wird ignoriert.

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 Clustergruppe auf EX3 verschoben wird.

Beim Windows-Failoverclustering werden die IP-Adressen für den Cluster in DNS (Domain Name System) registriert, sobald die Netzwerknamenressource online geschaltet wird. Darüber hinaus wird ein Clusternetzwerkobjekt (CNO) in Active Directory erstellt. Der Name, die IP-Adresse und der CNO für den Cluster werden intern vom System verwendet, um die DAG zu schützen und die interne Kommunikation zu unterstützen. Administratoren und Endbenutzer müssen keine Verbindung zu dem Namen oder der IP-Adresse der DAG herstellen.

Zusätzlich zu einem Namen oder mindestens einer IP-Adresse wird die DAG zur Verwendung eines Zeugenservers und eines Zeugenverzeichnisses konfiguriert. Der Zeugenserver und das Zeugenverzeichnis werden entweder automatisch durch das System angegeben oder können manuell vom Administrator festgelegt werden.

Standardmäßig ist eine DAG so konzipiert, dass sie die integrierte fortlaufende Replikation zum Replizieren von Postfachdatenbankservern in der DAG verwendet. Wenn Sie eine Drittanbieterlösung für die Datenreplikation verwenden, die die Exchange 2010-API für die Drittanbieterreplikation verwendet, müssen Sie die DAG im Drittanbieter-Replikationsmodus erstellen. Hierzu verwenden Sie das Cmdlet New-DatabaseAvailabilityGroup mit dem Parameter ThirdPartyReplication. 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. DAGs machen eingeschränkten Gebrauch vom Windows-Failoverclustering, und zwar von Clustertakt, Clusternetzwerken und 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). Werden der DAG weitere Server hinzugefügt, treten diese dem zugrunde liegenden Cluster bei (wobei das Quorummodell des Clusters automatisch vom System 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.

Quorummodelle für Database Availability Groups

Jeder DAG untergeordnet ist ein Windows-Failovercluster. Für Failovercluster gilt das Quorumkonzept. Hierbei wird eine Übereinstimmung von Wählern verwendet, um sicherzustellen, dass nur eine Teilmenge der Clustermitglieder (also entweder alle oder eine Mehrheit der Mitglieder) gleichzeitig funktionieren. Das Quorumkonzept ist keine neue Funktion von Exchange 2010. Auch hoch verfügbare Postfachserver in früheren Exchange-Versionen arbeiten mit Failoverclustern und dem dazugehörigen Quorumkonzept. Quorum steht für eine freigegebene Ansicht von Mitgliedern und Ressourcen, und der Begriff "Quorum" beschreibt außerdem die physischen Daten, welche die von allen Clustermitgliedern gemeinsam genutzte Konfiguration innerhalb des Clusters darstellen. Demzufolge erfordern alle DAGs, dass ihre zugrunde liegenden Failovercluster das Quorum besitzen. Wenn das Cluster das Quorum verliert, werden alle DAG-Operationen beendet, und die Bereitstellung aller in der DAG gehosteten Datenbanken wird aufgehoben. In diesem Fall ist ein Eingriff vonseiten des Administrators erforderlich, um das Quorumproblem zu beheben und die DAG-Operationen 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 von Konsistenz   Eine Hauptanforderung an ein Windows-Failovercluster ist, dass alle seine Mitglieder stets über eine Ansicht des Clusters verfügen, 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.

  • Lösen von Konflikten   Eine Quorumzeugenressource dient in DAGs mit einer geraden Anzahl von Mitgliedern zum Vermeiden des sog. Split Brain-Syndroms und zum Sicherstellen, dass nur eine Sammlung der Mitglieder in der DAG als "offiziell" angesehen wird. Wenn der Zeugenserver für das Quorum benötigt wird, können alle Mitglieder der DAG, die mit dem Zeugenserver kommunizieren können, eine SMB-Sperre (Server Message Block) für die Datei witness.log des Zeugenservers aktivieren. Das DAG-Mitglied, das den Zeugenserver sperrt (und als Sperrknoten bezeichnet wird), erhält für Quorumzwecke eine zusätzliche Stimme. Die DAG-Mitglieder in Kontakt mit dem Sperrknoten sind in der Mehrheit und behalten das Quorum. DAG-Mitglieder, die den Sperrknoten nicht kontaktieren können, sind in der Minderheit und verlieren deshalb das Quorum.

  • Sicherstellen der Reaktionsfähigkeit   Zum Sicherstellen der Reaktionsfähigkeit gewährleistet das Quorummodell, dass bei jeder Ausführung des Clusters genügend Mitglieder des verteilten Systems betriebs- und kommunikationsbereit 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 mit einer geraden Anzahl von Mitgliedern verwenden den Quorummodus Knoten- und Dateifreigabemehrheit des Failoverclusters, der zum Lösen von Konflikten mit einem externen Zeugenserver arbeitet. In diesem Quorummodus erhält jedes DAG-Mitglied eine Stimme. Außerdem wird einem DAG-Mitglied anhand des Zeugenservers eine gewichtige Stimme bereitgestellt (z. B. erhält es zwei Stimmen statt einer). Die Clusterquorumdaten werden standardmäßig auf den Systemdatenträgern der einzelnen DAG-Mitglieder gespeichert und auf diesen Datenträgern konsistent gehalten. Auf dem Zeugenserver wird hingegen keine Kopie der Quorumdaten gespeichert. In einer Datei auf dem Zeugenserver wird verfolgt, welches Mitglied die aktuelle Kopie der Daten besitzt. Auf dem Zeugenserver liegt jedoch keine Kopie der Clusterquorumdaten vor. In diesem Modus muss eine Mehrheit der Wähler (die DAG-Mitglieder plus Zeugenserver) zum Erhalten des Quorums für den Betrieb und die Kommunikation miteinander bereit sein. Wenn eine Mehrheit der Wähler nicht miteinander kommunizieren kann, verliert das der DAG zugrunde liegende Cluster das Quorum, sodass für die DAG ein Eingriff vonseiten des Administrators erforderlich ist, um wieder betriebsbereit zu werden.

DAGs mit einer ungeraden Anzahl von Mitgliedern verwenden den Quorummodus Knotenmehrheit des Clusters. In diesem Modus erhält jedes Mitglied eine Stimme, und der lokale Systemdatenträger der einzelnen Mitglieder dient zum Speichern der Clusterquorumdaten. Wenn sich die Konfiguration der DAG ändert, wird diese Änderung von den verschiedenen Datenträgern übernommen. Die Änderung gilt nur als dauerhaft gespeichert, wenn sie auf den Datenträgern der Hälfte der Mitglieder (nach Abrundung) plus eins erfolgt ist. Bei einer DAG mit fünf Mitgliedern muss diese Änderung beispielsweise bei zwei plus ein Mitglied bzw. insgesamt drei Mitgliedern erfolgt sein.

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.

Zurück zum Seitenanfang

Verwenden einer Database Availability Group für hohe Verfügbarkeit

Das nachfolgende Beispiel soll veranschaulichen, wie eine DAG eine hohe Verfügbarkeit für Ihre Postfachdatenbanken sicherstellen kann. Im Beispiel wird eine DAG mit fünf Mitgliedern verwendet. Diese DAG wird in der folgenden Abbildung dargestellt.

DAG mit fünf Mitgliedern

Datenbankverfügbarkeitsgruppe (DAG)

In der vorstehenden Abbildung handelt es sich bei den grün dargestellten Datenbanken um aktive Postfachdatenbankkopien, die blau dargestellten Datenbanken sind passive Postfachdatenbankkopien. In diesem Beispiel werden die Datenbankkopien nicht auf jedem Server gespiegelt, sondern über mehrere Server verteilt. Auf diese Weise wird sichergestellt, dass keine zwei Server in der DAG über denselben Satz von Datenbankkopien verfügen. Auf diese Weise wird mehr Ausfallsicherheit für die DAG erzielt, wenn beispielsweise andere Komponenten aufgrund von Wartungsarbeiten nicht verfügbar sind.

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

Zunächst arbeiten alle Datenbanken und Server fehlerfrei. Sie müssen einige Betriebssystemupdates auf EX2 installieren. Sie führen ein Serverswitchover aus, wodurch die Kopie von DB4 auf einem anderen Postfachserver aktiviert wird. Ein Serverswitchover wird durchführt, um alle aktiven Postfachdatenbankkopien vom aktuellen Server auf einen oder mehrere andere Postfachserver in der DAG zu verschieben, um den aktuellen Server auf einen geplanten Ausfall vorzubereiten. Sie können ein Serverswitchover rasch durchführen, indem der folgende Befehl in der Exchange-Verwaltungsshell ausgeführt wird.

Move-ActiveMailboxDatabase -Server EX2

In diesem Beispiel gibt es nur eine aktive Postfachdatenbank auf EX2 (DB4), weshalb nur eine aktive Postfachdatenbankkopie verschoben wird. Da im vorstehenden Befehl der Parameter ActivateOnServer nicht angegeben wurde, wählt das System die bestmögliche neue aktive Kopie. Im Beispiel wurde vom System die Kopie auf EX5 gewählt (siehe die folgende Abbildung).

DAG mit einem Server, der zur Wartung offline geschaltet wurde

DAG mit einem Offlineserver

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.

DAG mit einem zur Wartung offline geschalteten Server und einem ausgefallenen Server

DAG mit einem Offlineserver und einem ausgefallenen Server

Nachdem die geplanten Wartungsarbeiten auf EX2 abgeschlossen wurden, schalten Sie den Server wieder online. 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.

DAG mit einem wiederhergestellten Server, dessen Datenbankkopien synchronisiert werden

DAG mit wiederhergestelltem Server und erneuter Synchronisierung der Datenbanken

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.

DAG mit einem repariertem Server, dessen Datenbankkopien synchronisiert werden

DAG mit Mitglied und erneuter Synchronisierung der Datenbankkopien

Zurück zum Seitenanfang

Verwenden einer DAG zum Bereitstellen von Ausfallsicherheit für Standorte

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 und mindestens ein Hub-Transport- und Clientzugriffsserver) bereitgestellt werden. Anschließend wird der Postfachserver, wie in der folgenden Abbildung dargestellt, der DAG hinzugefügt.

Auf zwei Active Directory-Standorte erweiterte DAG

Auf zwei Active Directory-Standorte erweiterte DAG

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 Database Availability Groups zum Bereitstellen von Ausfallsicherheit

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.

Zurück zum Seitenanfang

Clientumgebung bei Verwenden von Database Availability Groups

DAGs können verwendet werden, um sowohl hohe Verfügbarkeit als auch Ausfallsicherheit bereitzustellen. Die Clientumgebung bei Verwenden einer DAG hängt von Typ und Version des Clients und dem Protokoll ab, das der Client für den Zugriff auf Postfachdaten verwendet. Wenn beispielsweise ein standortübergreifendes Datenbankfailover erfolgt, unterscheidet sich das Verhalten und die Erkennungslogik eines POP3- oder IMAP4-Clients vom Verhalten und der Erkennungslogik eines Microsoft Outlook 2010-Clients.

In den folgenden Abschnitten werden Verhalten und Logik von Clients in verschiedenen Szenarien beschrieben. Das beschriebene Verhalten setzt Folgendes voraus:

  • Die Umgebung enthält an jedem Active Directory-Standort ein einzelnes Clientzugriffsserver-Array, und jeder Standort weist mindestens zwei Clientzugriffsserver auf.

  • Dem Clientzugriffsserver-Array vorgelagert ist ein geeigneter installierter und konfigurierter Lastenausgleich auf Hardware- oder Softwarebasis.

  • Die ordnungsgemäße Planung und Konfiguration von Namespaces und Zertifikaten, einschließlich erforderlicher DNS-Einträge, ist abgeschlossen.

Verhalten und Logik von Microsoft Outlook

Im Allgemeinen verhalten sich alle Versionen von Outlook bei einem Datenbankfailover gleich, das in einem einzelnen Datencenter und an einem einzelnen Active Directory-Standort erfolgt. Im Gegensatz zu früheren Versionen von Exchange stellt Exchange 2010 in Outlook keine direkte Verbindung mehr mit dem Exchange-Informationsspeicher auf dem Postfachserver her. Stattdessen verbindet sich Outlook (und jeder beliebige andere MAPI-Client) mit den RPC-Clientzugriffs- und Adressbuchdiensten der Clientzugriffs-Serverrolle, und das Outlook des Benutzers ist so konfiguriert, dass eine Verbindung mit dem Clientzugriffsserver-Array erfolgt, das anschließend den Client mit einem einzelnen Clientzugriffsserver verbindet. Die sich vom Postfachserver entfernende Abstraktion der Outlook-Verbindung bietet die folgenden Vorteile:

  • Wenn ein Datenbankfailover erfolgt, bleibt Outlook mit demselben Server im Clientzugriffsserver-Array verbunden. Wenn dies der Fall ist, erfährt der auf dem Clientzugriffsserver ausgeführte Active Manager-Client, welches DAG-Mitglied die aktive Datenbankkopie des Active Manager der DAG hostet. Anschließend verbindet sich der Clientzugriffsserver mit diesem Postfachserver, und Outlook meldet, dass es mit dem Exchange-Server verbunden ist.

  • Wenn einer der Clientzugriffsserver im Clientzugriffsserver-Array aufgrund eines geplanten oder nicht geplanten Ausfalls nicht mehr zur Verfügung steht, können die in diesem Array verbleibenden Clientzugriffsserver die Clientlast übernehmen. Da Outlook für das Verbinden mit dem Clientzugriffsserver-Array und nicht mit einem einzelnen Clientzugriffsserver konfiguriert ist, können Mitglieder des Clientzugriffsserver-Arrays einzeln ausfallen oder manuell offline geschaltet werden, ohne dass sich dies auf das Outlook-Profil des Benutzers auswirkt. Dies kann automatisch (z. B. durch eine automatische Arraykonfiguration basierend auf der Überwachung der dem Array vorgelagerten Lastenausgleichslösung) oder manuell erfolgen.

Alle Outlook-Versionen verhalten sich bei einem Datencenterswitchover zwischen zwei Datencentern und zwei Active Directory-Standorten gleich. Ein Datencenterswitchover umfasst das Ändern der von Clientzugriffsnamespaces verwendeten IP-Adressen (z. B. Microsoft Office Outlook Web App, SMTP, POP3, IMAP4, AutoErmittlung, Exchange-Webdienste oder RPC-Clientzugriff) von IP-Adressen im primären Datencenter in IP-Adressen im sekundären Datencenter. Daraus resultiert, dass sich der im Outlook-Profil des Benutzers verwendete Namespace nicht ändert und die AutoErmittlungsfunktion Clients weiter auf denselben Namespace des Clientzugriffsserver-Arrays verweist.

Das Verhalten von Outlook nach einem standardübergreifenden Datenbankfailover unterscheidet sich vom Verhalten nach einem Datenbankfailover an einem einzelnen Active Directory-Standort oder einem Datencenterswitchover.

Beispielverhalten von Outlook-Versionen

Die folgenden Beispiele veranschaulichen das Verhalten von Outlook 2010, Office Outlook 2007 und Office Outlook 2003 nach einem standortübergreifenden Datenbankfailover. Die Topologie in diesen Beispielen ist eine DAG mit vier Mitgliedern, die auf zwei Active Directory-Standorte ausgedehnt wurde: Redmond und Portland. Das Benutzerpostfach wird auf DB1 gehostet und auf die anderen Server repliziert. In jedem Beispiel erfolgt ein Failover der aktiven Kopie von DB1 von MBX2 auf MBX3.

Beispieltopologie zum Veranschaulichen des Outlook-Verhaltens nach einem standortübergreifenden Datenbankfailover

Outlook-Verhalten mit Datenbankverfügbarkeitsgruppen

Alle Clients sind mit CAS1 als Stammserver konfiguriert, wobei Redmond der Outlook-Profilstandort ist. Da sich die Clients in Redmond befinden, wird die Eigenschaft RPCClientAccessServer für DB1 für CAS1 konfiguriert, wodurch Redmond zum bevorzugten Datenbankstandort wird. Da DB1 auf MBX2 ausgefallen ist und auf MBX3 aktiv wurde, ist Portland der eingebundene Datenbankstandort.

Beispiel für Outlook 2010 und Outlook 2007

Wenn ein Clientserver am Standort Redmond verfügbar ist, stellen Outlook 2010 und Outlook 2007 weiterhin eine Verbindung zum Array für den RPC-Clientzugriff am Standort Redmond her. Der vom Client verwendete Clientzugriffsserver kommuniziert über MAPI RPC mit dem Postfachserver des Benutzers am Standort Portland.

Sind am Standort Redmond keine Clientzugriffsserver verfügbar, muss ein Datencenterswitchover von Redmond nach Portland erfolgen, damit der Zugriff auf Service und Daten wiederhergestellt wird. Ausführliche Anweisungen zum Ausführen eines Datencenterswitchovers finden Sie unter Ausführen eines Serverswitchovers.

Beispiel für Microsoft Outlook 2003

Wenn Outlook 2003 versucht, eine Verbindung mit CAS1 herzustellen, wird als Reaktion auch die Meldung ecWrongServer empfangen. Im Gegensatz zu Outlook 2010 und Outlook 2007 bietet Outlook 2003 nicht die AutoErmittlungsfunktion, weshalb Sie eine andere Möglichkeit zum Ändern des Benutzerprofils wählen müssen. Der von Outlook 2003 verwendete Mechanismus ist die MAPI-Profilumleitung, die erfordert, dass der ursprüngliche Quellserver online ist. Wenn CAS1 nicht verfügbar ist und alle anderen Clientzugriffsserver im Array ebenfalls nicht verfügbar sind (oder das Array nur CAS1 enthält), kann Outlook 2003 keine MAPI-Umleitung durchführen oder sich ohne manuelle Eingriffe nicht mit der Postfachdatenbank des Benutzers verbinden.

Verhalten und Logik bei Verwendung Öffentlicher Ordner

Wenngleich Öffentliche Ordner-Datenbanken auf Postfachservern gehostet werden können, die Mitglieder einer DAG sind, wird für Öffentliche Ordner-Datenbanken nicht die fortlaufende Replikation verwendet. Zum Gewährleisten einer hohen Verfügbarkeit ist die Öffentliche Ordner-Replikation erforderlich. Das Verhalten von Outlook-Clients, die sich nach einem Failover einer Postfachdatenbank wieder mit einer Öffentlichen Ordner-Datenbank verbinden, hängt nicht nur von der Art des Fehlers, sondern auch von den Konfigurationseinstellungen für die Replikation Öffentlicher Ordner sowie dem Status und der Aktualität der Öffentlichen Ordner-Datenbanken ab. Da die fortlaufende Replikation für Öffentliche Ordner-Datenbanken nicht verwendet werden kann, wird eine hohe Verfügbarkeit für Öffentliche Ordner-Datenbanken erreicht, indem mehrere Öffentliche Ordner-Datenbanken bereitgestellt und für eine gegenseitige Replikation konfiguriert werden. Es wird empfohlen, für jeden Ordner mehrere Replikate zu konfigurieren.

Verhalten und Logik von Nicht-Outlook-Clients

Im Allgemeinen variiert das Verhalten anderer Clients und Protokolle als Outlook und MAPI je nach verwendeter Anwendung und dem Ausfallszenario. Im Allgemeinen verhalten sich wie bei Outlook die typischen Exchange-Anwendungen und -Clients (z. B. Outlook Web App, Microsoft Exchange ActiveSync, POP3, IMAP4 und Exchange-Webdienste) bei einem Datenbankfailover gleich, das in einem einzelnen Datencenter und an einem einzelnen Active Directory-Standort erfolgt. Gleichermaßen verhalten sich alle diese Clients und Protokolle (einschließlich SMTP und Windows PowerShell) bei einem Datencenterswitchover ebenso wie Outlook.

Wenn ein standortübergreifendes Datenbankfailover erfolgt, hängt das Verhalten von diesen Clients und Protokollen ab. In der folgenden Tabelle wird das Verhalten dieser Clients beschrieben.

Verhalten typischer Exchange-Clients beim standortübergreifenden Datenbankfailover

Client oder Protokoll Verhalten

Outlook Web App

Manuelle Umleitung. In diesem Szenario ändert sich der Clientnamespace von http://mailred.contoso.com in http://mailpdx.contoso.com. Nachdem der Benutzer Anmeldeinformationen eingegeben hat, wird der Benutzer über eine manuelle Umleitungsseite, auf der erklärt wird, dass die falsche URL verwendet wurde und die ordnungsgemäße URL http://mailpdx.contoso.com/owa lautet, zu CAS2 am Standort Portland umgeleitet.

Exchange ActiveSync

Proxy oder Umleitung. In diesem Szenario wird das Clientverhalten von der Implementierung und Version des Exchange ActiveSync-Protokolls auf dem Clientgerät bestimmt.

POP3 und IMAP4

Proxy. Dieses Szenario basiert stets auf Proxyfunktionen zwischen Clientzugriffsservern.

Exchange-Webdienste

Verwendet die AutoErmittlungsfunktion zum Bestimmen des neuen Verbindungsendpunkts.

Zurück zum Seitenanfang

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.