Verwalten von Datenbankverfügbarkeitsgruppen

 

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

Letztes Änderungsdatum des Themas: 2016-11-28

Eine Database Availability Group (DAG) ist eine Gruppe von bis zu 16 Microsoft Exchange Server 2010-Postfachservern, die eine automatische Wiederherstellung auf Datenbankebene nach einem Datenbank-, Server- oder Netzwerkfehler bieten. Für DAGs wird eine fortlaufende Replikation und ein Teil der Windows-Failoverclusteringtechnologien verwendet, um eine hohe Verfügbarkeit und Ausfallsicherheit für Standorte zu gewährleisten. Die Postfachserver in einer DAG überwachen sich gegenseitig auf Fehler. Wenn einer DAG ein Postfachserver hinzugefügt wird, ist dieser mit den anderen Servern in der DAG kompatibel, damit eine automatische Wiederherstellung auf Datenbankebene nach Datenbankausfällen bereitgestellt werden kann.

Wenn Sie eine DAG erstellen, ist diese zunächst leer, und in Active Directory wird ein Verzeichnisobjekt für die DAG erstellt. Das Verzeichnisobjekt dient zum Speichern relevanter Informationen über die DAG, z. B. Servermitgliedschaftsinformationen. Wenn Sie der DAG den ersten Server hinzufügen, wird für die DAG automatisch ein Failovercluster erstellt. Darüber hinaus wird die Infrastruktur für die Ü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, z. B. Datenbankeinbindungsstatus, Replikationsstatus und Standort der letzten Einbindung.

Inhalt

Erstellen von DAGs

DAG-Mitgliedschaft

Konfigurieren von DAG-Eigenschaften

DAG-Netzwerke

Konfigurieren von DAG-Mitgliedern

Ausführen des Wartungsprozesses auf DAG-Mitgliedern

Herunterfahren von DAG-Mitgliedern

Installieren von Updaterollups auf DAG-Mitgliedern

Erstellen von DAGs

Eine DAG kann mithilfe des Assistenten für neue DAGs in der Exchange-Verwaltungskonsole (EMC) oder durch Ausführen des Cmdlets New-DatabaseAvailabilityGroup in der Exchange-Verwaltungsshell erstellt werden. Wenn Sie eine DAG erstellen, geben Sie einen Namen für die DAG, einen optionalen Zeugenserver und Einstellungen für das Zeugenverzeichnis an. Darüber hinaus werden der DAG eine oder mehrere IP-Adressen zugewiesen, entweder durch Verwenden statischer IP-Adressen oder durch Zulassen der automatischen Zuweisung erforderlicher IP-Adressen zur DAG über DHCP (Dynamic Host Configuration Protocol). Sie können der DAG mit dem Parameter DatabaseAvailabilityGroupIpAddresses manuell IP-Adressen zuweisen. Wenn Sie diesen Parameter weglassen, versucht die DAG, mithilfe eines DHCP-Servers in Ihrem Netzwerk eine IP-Adresse zu erhalten.

Genaue Anweisungen zum Erstellen einer DAG finden Sie unter Erstellen einer Datenbankverfügbarkeitsgruppe.

Wenn Sie eine DAG erstellen, werden ein leeres Objekt für die DAG mit dem von Ihnen angegebenen Namen und die Objektklasse msExchMDBAvailabilityGroup in Active Directory erstellt.

DAGs nutzen einen Teil der Windows-Failoverclusteringtechnologien: Clustertakt, Clusternetzwerke und Clusterdatenbank (zum Speichern von Daten, die sich ändern oder schnell ändern können, beispielsweise Änderungen des Datenbankzustands von "Aktiv" zu "Passiv" oder umgekehrt oder von "Eingebunden" zu "Nicht eingebunden" und umgekehrt). Da DAGs auf Windows Failover Clustering basieren, können sie auch auf Exchange 2010-Postfachservern mit dem Windows Server 2008 Enterprise-Betriebssystem oder dem Windows Server 2008 R2 Enterprise-Betriebssystem erstellt werden.

DAG-Zeugenserver und -Zeugenverzeichnis

Beim Erstellen einer DAG müssen Sie einen Namen für die DAG angeben, der maximal 15 Zeichen lang und innerhalb der Active Directory-Gesamtstruktur eindeutig ist. Darüber hinaus wird jede DAG mit einem Zeugenserver und einem Zeugenverzeichnis konfiguriert. Der Zeugenserver und sein Verzeichnis werden nur zu Quorumzwecken verwendet, wenn eine ungerade Anzahl von Mitgliedern in der DAG vorliegt. Sie müssen das Zeugenverzeichnis nicht im Voraus erstellen. Exchange erstellt und sichert das Verzeichnis automatisch für Sie auf dem Zeugenserver. Das Verzeichnis sollte ausschließlich für den DAG-Zeugenserver verwendet werden.

Der Zeugenserver muss folgende Anforderungen erfüllen:

• Der Zeugenserver darf kein Mitglied der DAG sein.

• Der Zeugenserver muss sich in derselben Active Directory-Gesamtstruktur wie die DAG befinden.

• Der Zeugenserver muss das Betriebssystem Windows Server 2003 ausführen.

• Ein einzelner Server kann als Zeuge für mehrere DAGs fungieren. Für jede DAG ist jedoch ein eigenes Zeugenverzeichnis erforderlich.

Sie sollten einen Exchange 2010-Hub-Transport-Server an dem Active Directory-Standort verwenden, an dem sich die DAG befindet. Auf diese Weise können Zeugenserver und -verzeichnis unter der Kontrolle eines Exchange-Administrators verbleiben. Unabhängig von dem als Zeugenserver verwendeten Server müssen Sie, wenn die Windows-Firewall auf dem vorgesehenen Zeugenserver aktiviert ist, die Windows-Firewallausnahme für die Datei- und Druckerfreigabe aktivieren.

Weder Zeugenserver noch Zeugenverzeichnis müssen fehlertolerant sein oder eine Form von Redundanz oder hoher Verfügbarkeit verwenden. Es besteht keine Notwendigkeit zur Verwendung eines Dateiclusterservers oder einer anderen Form von Ausfallsicherung für den Zeugenserver. Hierfür gibt es verschiedene Gründe. Bei größeren DAGs (z. B. mit sechs oder mehr Mitgliedern) können mehrere Fehler auftreten, bevor der Zeugenserver benötigt wird. Da eine DAG mit sechs Mitgliedern zwei Wählerfehler tolerieren kann, ohne dass das Quorum verloren geht, müssten drei Wähler ausfallen, bevor der Zeugenserver zur Aufrechterhaltung des Quorums benötigt wird. Wenn es einen Fehler gibt, der sich auf den aktuellen Zeugenserver auswirkt (wenn Sie beispielsweise den Zeugenserver wegen eines Hardwareausfalls verlieren), können Sie zudem mit dem Cmdlet Set-DatabaseAvailabilityGroup einen neuen Zeugenserver und ein neues Zeugenverzeichnis konfigurieren (vorausgesetzt, es besteht ein Quorum).

Als bewährte Methode empfiehlt es sich in einer Umgebung, in der eine DAG sich über mehrere Datencenter (und Active Directory-Standorte) erstreckt und für die Ausfallsicherheit von Standorten konfiguriert ist, einen Zeugenserver im primären Datencenter zu konfigurieren (dem Datencenter, in dem sich die Mehrzahl der Benutzer befindet). Falls jedes Datencenter über dieselbe Anzahl Benutzer verfügt, wird das Datencenter, das Sie als Host für den Zeugenserver auswählen, von der Lösung als primäres Datencenter betrachtet. Wenn sich der Zeugenserver im Datencenter mit der Mehrzahl der Clients befindet, besteht für die Mehrzahl der Clients nach einem Fehler auch weiterhin Zugriff.

Wenn sich das Datencenter remote zu großen Benutzergruppen befindet, kann sich dies auf Ihre Entscheidung auswirken. Sie müssten dann bestimmen, ob das primäre Datencenter sich in einem fehlerfreien und aktiven Zustand befinden muss, falls es zu einem Ausfall der WAN-Verbindung zu den anderen beiden Datencentern kommen sollte. In diesem Fall sollte sich der Zeugenserver ebenfalls im primären Datencenter befinden.

Zwar wird die Verwendung eines Zeugenservers in einem dritten Datencenter unterstützt, doch ist von diesem Szenario abzuraten. Aus einer Exchange-Perspektive bietet Ihnen diese Konfiguration keine höhere Verfügbarkeit. Es ist wichtig, dass Sie die kritischen Pfadfaktoren untersuchen, wenn Sie einen Zeugenserver in einem dritten Datencenter verwenden. Wenn beispielsweise die WAN-Verbindung zwischen dem primären und dem zweiten und dritten Datencenter ausfällt, ist auch die Lösung im primären Datencenter nicht mehr verfügbar.

Angeben eines Zeugenservers und Zeugenverzeichnisses bei der DAG-Erstellung

Beim Erstellen einer DAG müssen Sie einen Namen für die DAG angeben. Optional können Sie auch einen Zeugenserver und ein Zeugenverzeichnis angeben. Es wird empfohlen, dass Sie einen Hub-Transport-Server verwenden, wenn Sie einen Zeugenserver angeben, damit einem Exchange-Administrator die Verfügbarkeit des Zeugenservers bewusst ist.

Beim Erstellen einer DAG sind die folgenden Kombinationen von Optionen und Verhalten verfügbar:

• Sie können nur einen Namen für die DAG angeben und die Felder Zeugenserver und Zeugenverzeichnis leer lassen. In diesem Szenario sucht der Assistent nach einem Hub-Transport-Server, der die Postfachserverrolle nicht installiert hat, erstellt automatisch das Standardverzeichnis ("%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>") und die Standardfreigabe ("<DAGFQDN>") auf diesem Server und verwendet den Hub-Transport-Server als Zeugenserver. Stellen Sie sich beispielsweise vor, Sie haben einen Zeugenserver namens "EXMBX3", dessen Betriebssystem auf Laufwerk "C:" installiert wurde. Eine DAG namens "DAG1" in einer Domäne namens "contoso.com" verwendet das Standardzeugenverzeichnis "C:\DAGFileShareWitnesses\DAG1.contoso.com", das als "\\EXMBX3\DAG1.contoso.com" freigegeben wird.

• Sie können einen Namen für die DAG, den Zeugenserver, den Sie verwenden möchten, sowie das Verzeichnis, das Sie erstellen und auf dem Zeugenserver freigeben möchten, angeben.

• Sie können einen Namen für die DAG und den Zeugenserver angeben, den Sie verwenden möchten, und das Feld Zeugenverzeichnis leer lassen. In diesem Szenario erstellt der Assistent das Standardverzeichnis auf dem angegebenen Zeugenserver.

• Sie können einen Namen für die DAG angeben, das Feld Zeugenserver leer lassen und das Verzeichnis angeben, das Sie erstellen und auf dem Zeugenserver freigeben möchten. In diesem Szenario sucht der Assistent nach einem Hub-Transport-Server, der die Postfachserverrolle nicht installiert hat, und erstellt automatisch die angegebene DAG auf dem Server, gibt das Verzeichnis frei und verwendet den Hub-Transport-Server als Zeugenserver.

Eine neu erstellte DAG verwendet zunächst das Knotenmehrheits-Quorummodell. Wird der DAG der zweite Postfachserver hinzugefügt, wird das Quorum automatisch in ein Knoten- und Dateifreigabemehrheits-Quorummodell geändert. Kommt es zu dieser Änderung, beginnt die DAG, den Zeugenserver zu verwenden, um ein Quorum aufrechtzuerhalten. Ist das Zeugenverzeichnis nicht vorhanden, wird es von Exchange automatisch erstellt, freigegeben und die Freigabe mit den vollständigen Steuerungsberechtigungen für das CNO-Computerkonto (Clusternamensobjekt) für die DAG ausgestattet.

Wenn die Windows-Firewall auf dem Zeugenserver aktiviert wird, bevor die DAG erstellt wurde, kann dies die Erstellung der DAG möglicherweise blockieren. Exchange verwendet die Windows Management Instrumentation (WMI), um das Verzeichnis und die Dateifreigabe auf dem Zeugenserver zu erstellen. Wenn die Windows-Firewall auf dem Zeugenserver aktiviert ist und für WMI keine Firewallausnahmen konfiguriert sind, schlägt das Cmdlet New-DatabaseAvailabilityGroup mit einem Fehler fehl. Wenn Sie einen Zeugenserver, aber kein Zeugenverzeichnis angeben, erhalten Sie die folgende Fehlermeldung.

Der Task konnte das Standardzeugenverzeichnis auf Server <Servername> nicht erstellen. Geben Sie manuell ein Zeugenverzeichnis an.

Wenn Sie einen Zeugenserver und ein Zeugenverzeichnis angeben, erhalten Sie die folgende Warnmeldung.

Kein Zugriff auf Dateifreigaben auf Zeugenserver 'Servername'. Bis zur Behebung des Problems kann die DAG anfälliger für Fehler sein. Verwenden Sie das Cmdlet "Set-DatabaseAvailabilityGroup", um den Vorgang zu wiederholen. Fehler: Der Netzwerkpfad wurde nicht gefunden.

Wenn die Windows-Firewall auf dem Zeugenserver aktiviert wird, nachdem die DAG erstellt wurde, aber bevor die Server hinzugefügt wurden, kann dies das Hinzufügen oder Entfernen von DAG-Mitgliedern blockieren. Wenn die Windows-Firewall auf dem Zeugenserver aktiviert ist und für WMI keine Firewallausnahmen konfiguriert sind, zeigt das Cmdlet Add-DatabaseAvailabilityGroupServer die folgende Warnmeldung an.

Fehler beim Erstellen des Dateifreigabe-Zeugenverzeichnisses 'C:\DAGFileShareWitnesses\DAG_FQDN' auf Zeugenserver 'Servername'. Bis zur Behebung des Problems kann die DAG anfälliger für Fehler sein. Verwenden Sie das Cmdlet 'Set-DatabaseAvailabilityGroup', um den Vorgang zu wiederholen. Fehler: WMI-Ausnahme auf Server 'Servername': Der RPC-Server ist nicht verfügbar. (Ausnahme von HRESULT: 0x800706BA)

Führen Sie eine der folgenden Aktionen aus, um die vorangehenden Fehler und Warnungen zu beheben:

• Erstellen Sie das Zeugenverzeichnis und die Freigabe auf dem Zeugenserver manuell, und weisen Sie dem Clusternamensobjekt für die DAG den Vollzugriff für das Verzeichnis und die Freigabe zu.

• Aktivieren Sie die WMI-Ausnahme in der Windows-Firewall.

• Deaktivieren Sie die Windows-Firewall.

Zurück zum Seitenanfang

DAG-Mitgliedschaft

Nach dem Erstellen einer DAG können Sie Server hinzufügen oder daraus entfernen. Verwenden Sie dazu den Assistenten zum Verwalten einer DAG in der Exchange-Verwaltungskonsole oder die Cmdlets Add-DatabaseAvailabilityGroupServer oder Remove-DatabaseAvailabilityGroupServer in der Shell. Genaue Anweisungen zum Verwalten der DAG-Mitgliedschaft finden Sie unter Verwalten der Mitgliedschaft in einer Datenbankverfügbarkeitsgruppe.

Wenn für den einer DAG hinzugefügten Postfachserver keine Failoverclusteringkomponente installiert ist, wird die Failoverclusteringfunktion mit der Methode installiert, die zum Hinzufügen des Servers verwendet wird (z. B. das Cmdlet Add-DatabaseAvailabilityGroupServer oder der Assistent zum Verwalten einer DAG).

Beim Hinzufügen des ersten Postfachservers zu einer DAG geschieht Folgendes:

• Die Windows-Failoverclusteringkomponente wird installiert, wenn sie nicht bereits installiert ist.

• Ein Failovercluster mit dem Namen der DAG wird erstellt. Dieser Failovercluster wird ausschließlich von der DAG verwendet, und der Cluster muss für die DAG bestimmt sein. Die Verwendung des Clusters für einen anderen Zweck wird nicht unterstützt.

• Ein Clusternamensobjekt wird im Container des Standardcomputers erstellt.

• Name und IP-Adresse der DAG werden als Datensatz "Host (A)" in DNS (Domain Name System) registriert.

• Der Server wird dem DAG-Objekt in Active Directory hinzugefügt.

• Die Clusterdatenbank wird anhand der Informationen in den eingebundenen Datenbanken auf dem hinzugefügten Server aktualisiert.

In einer großen oder mehrere Standorte umfassenden Umgebung, insbesondere mit DAGs, die sich über mehrere Active Directory-Standorte erstrecken, müssen Sie auf den Abschluss der Active Directory-Replikation des DAG-Objekts warten, das das erste DAG-Mitglied enthält. Wenn dieses Active Directory-Objekt nicht in der gesamten Umgebung repliziert wird, kann das Hinzufügen des zweiten Servers zum Erstellen eines neuen Clusters (und eines neuen Clusternetzwerkobjekts) für die DAG führen. Der Grund hierfür ist, dass das DAG-Objekt aus Sicht des zweiten hinzugefügten Mitglieds leer zu sein scheint. Dies führt dazu, dass das Cmdlet Add-DatabaseAvailabilityGroupServer einen Cluster und ein Clusternamensobjekt für die DAG erstellt, obwohl diese Objekte bereits vorhanden sind. Wenn Sie überprüfen möchten, ob das DAG-Objekt, das den ersten DAG-Server enthält, repliziert wurde, verwenden Sie das Cmdlet Get-DatabaseAvailabilityGroup auf dem zweiten Server. Dieser wurde hinzugefügt, um sicherzustellen, dass der erste von Ihnen hinzugefügte Server als Mitglied der DAG aufgelistet wird.

Beim Hinzufügen des zweiten sowie weiterer Server zur DAG geschieht Folgendes:

• Der Server wird mit dem Windows-Failovercluster für die DAG verknüpft.

• Das Quorum-Modell wird automatisch angepasst:

  • Für DAGs mit einer ungeraden Mitgliederzahl wird ein Knotenmehrheits-Quorummodell verwendet.

  • Für DAGs mit einer geraden Mitgliederzahl wird ein Knoten- und Dateifreigabemehrheits-Quorummodell verwendet.

• Zeugenverzeichnis und -freigabe werden bei Bedarf automatisch von Exchange erstellt.

• Der Server wird dem DAG-Objekt in Active Directory hinzugefügt.

• Die Clusterdatenbank wird anhand von Informationen über eingebundene Datenbanken aktualisiert.

Vorabbereitstellen des Clusternamenobjekts für eine DAG

Das Clusternetzwerkobjekt (CNO) ist ein in Active Directory erstelltes Computerkonto und der Namensressource des Clusters zugeordnet. Die Namensressource des Clusters ist an das Clusternetzwerkobjekt gebunden, wobei es sich um ein Kerberos-fähiges Objekt handelt, das als Identität des Clusters dient und den Sicherheitskontext des Clusters bereitstellt. In Exchange 2007 wurde dieses Kerberos-fähige Computerkonto mithilfe des Sicherheitskontexts des Benutzers in der Domäne erstellt, der die Aufgaben ausführt. Dies erfordert, dass das Konto des Benutzers über die Berechtigung zum Erstellen und Aktivieren von Computerkonten in der Domäne verfügt oder das Computerkonto ordnungsgemäß vorab- und standardmäßig bereitgestellt wurde.

Die Formation des Clusters, der der DAG zugrunde liegt, und des Clusternetzwerkobjekts für diesen Cluster wird durchgeführt, wenn das erste Mitglied zur DAG hinzugefügt wird. Wenn der erste Server zur DAG hinzugefügt wird, kontaktiert Powershell den Microsoft Exchange-Replikationsdienst auf dem hinzuzufügenden Postfachserver. Der Microsoft Exchange-Replikationsdienst installiert die Failoverclusteringfunktion (sofern diese nicht bereits installiert ist) und beginnt mit der Clustererstellung. Der Microsoft Exchange-Replikationsdienst wird unter dem Sicherheitskontext LOKALES SYSTEM ausgeführt, unter dem auch die Clustererstellung durchgeführt wird.

In Umgebungen, in denen die Erstellung von Computerkonten eingeschränkt ist oder in denen Computerkonten in einem anderen Container als dem Container der Standardcomputer erstellt werden, können Sie das Clusternetzwerkobjekt vorab bereitstellen und einrichten. Sie erstellen zuerst ein Computerkonto für das CNO, deaktivieren es, und führen dann einen der folgenden Schritte aus:

• Zuweisen von Vollzugriff auf das Computerkonto an das Computerkonto des ersten Postfachservers, der der DAG hinzugefügt wird.

• Zuweisen von Vollzugriff auf das Computerkonto an die universelle Sicherheitsgruppe "Exchange Trusted Subsystem".

Das Zuweisen des Vollzugriffs auf das Computerkonto zum Computerkonto des ersten Postfachservers, den Sie der DAG hinzufügen, stellt sicher, dass der Sicherheitskontext LOKALES SYSTEM in der Lage ist, das vorab bereitgestellte Computerkonto zu verwalten. Das Zuweisen des Vollzugriffs auf das Computerkonto an die universelle Sicherheitsgruppe "Exchange Trusted Subsystem" kann stattdessen verwendet werden, da die universelle Sicherheitsgruppe "Exchange Trusted Subsystem" die Computerkonten aller Exchange-Server in der Domäne enthält.

Genaue Anweisungen zum Vorabbereitstellen und Einrichten des Clusternetzwerkobjekts für eine DAG finden Sie unter Provisorische Bereitstellung des Clusternamenobjekts für eine Database Availability Group.

Entfernen von Servern aus einer DAG

Postfachserver können mithilfe des Assistenten zum Verwalten der Mitgliedschaft in einer DAG in der Exchange-Verwaltungskonsole oder mithilfe des Cmdlets Remove-DatabaseAvailabilityGroupServer in der Shell entfernt werden. Vor dem Entfernen eines Postfachservers aus einer DAG müssen zunächst alle replizierten Postfachdatenbanken vom Server entfernt werden. Der Versuch, einen Postfachserver mit replizierten Postfachdatenbanken aus einer DAG zu entfernen, schlägt fehl.

In manchen Szenarien müssen Sie einen Postfachserver aus einer DAG entfernen, bevor Sie bestimmte Vorgänge ausführen können. Diese Szenarien umfassen:

• Ausführen eines Serverwiederherstellungsvorgangs   Wenn ein Postfachserver, der Mitglied einer DAG ist, verloren geht bzw. ausfällt, sich nicht wiederherstellen lässt und ersetzt werden muss, können Sie mit der Option Setup /m:RecoverServer einen Serverwiederherstellungsvorgang ausführen. Bevor Sie jedoch einen Wiederherstellungsvorgang ausführen können, müssen Sie zunächst den Server mithilfe des Cmdlets Remove-DatabaseAvailabilityGroupServer und des Parameters ConfigurationOnly aus der DAG entfernen.

• Entfernen der DAG   In bestimmten Situationen müssen Sie eine DAG möglicherweise entfernen (z. B. beim Deaktivieren des Replikationsmodus eines Drittanbieters). Wenn Sie eine DAG entfernen müssen, müssen Sie zunächst alle Server aus der DAG entfernen. Der Versuch, eine DAG mit einem oder mehreren Mitgliedern zu entfernen, schlägt fehl.

Zurück zum Seitenanfang

Konfigurieren von DAG-Eigenschaften

Nachdem der DAG Server hinzugefügt wurden, können Sie mithilfe der Exchange-Verwaltungskonsole oder der Shell die Eigenschaften einer DAG konfigurieren, einschließlich des von der DAG verwendeten Zeugenservers und -verzeichnisses sowie die der DAG zugewiesenen IP-Adressen.

Zu den konfigurierbaren Eigenschaften gehören folgende:

• Zeugenserver   Der Name des Servers, auf dem die Dateifreigabe für den Dateifreigabenzeugen gehostet werden soll. Es wird empfohlen, dass Sie einen Hub-Transport-Server außerhalb der DAG als Zeugenserver verwenden. Auf diese Weise kann das System die Freigabe nach Bedarf automatisch konfigurieren, sichern und verwenden.

• Zeugenverzeichnis   Der Name eines Verzeichnisses, in dem Dateifreigabenzeugen-Daten gespeichert werden. Dieses Verzeichnis wird automatisch vom System auf dem angegebenen Zeugenserver erstellt.

• IP-Adressen für DAGs   Eine oder mehrere IP-Adressen, die der DAG zugewiesen sind. Diese Adressen können mithilfe manuell zugewiesener statischer IP-Adressen konfiguriert oder der DAG automatisch über einen DHCP-Server in der Organisation zugewiesen werden.

Mit der Shell können Sie DAG-Eigenschaften konfigurieren, die in der Exchange-Verwaltungskonsole nicht zur Verfügung stehen, z. B. DAG-IP-Adressen, Netzwerkverschlüssselungs- und -komprimierungseinstellungen, Netzwerkerkennung, den für die Replikation verwendeten TCP-Port und alternative Zeugenserver- und Zeugenverzeichniseinstellungen. Außerdem können Sie den Aktivierungsmodus des Datencenters (Datacenter Activation Coordination, DAC) aktivieren.

Genaue Anweisungen zum Konfigurieren der Eigenschaften von DAGs finden Sie unter Konfigurieren der Eigenschaften der Datenbankverfügbarkeitsgruppe.

DAG-Netzwerkverschlüsselung

DAGs unterstützen die Verwendung von Verschlüsselung durch die Nutzung der Verschlüsselungsfunktionen des Windows Server-Betriebssystems. DAGs verwenden die Kerberos-Authentifizierung zwischen Exchange-Servern. Die EncryptMessage- und DecryptMessage-APIs von Microsoft Kerberos Security Support Provider (SSP) verarbeiten die Verschlüsselung des DAG-Netzwerkdatenverkehrs. Microsoft Kerberos SSP unterstützt mehrere Verschlüsselungsalgorithmen. (Eine vollständige Liste finden Sie in Abschnitt 3.1.5.2 zum Thema "Verschlüsselungstypen" der Kerberos-Protokollerweiterungen). Der Kerberos-Authentifizierungshandshake wählt das stärkste Verschlüsselungsprotokoll aus der Liste aus: Im Allgemeinen ist dies AES (Advanced Encryption Standard) mit 256 Bit, möglicherweise mit einem SHA-basierten Nachrichtenauthentifizierungscode (Hash-based Message Authentication Code, HMAC) zur Wahrung der Datenintegrität. Weitere Informationen finden Sie unter HMAC.

Die Netzwerkverschlüsselung ist eine Eigenschaft der DAG, nicht eines DAG-Netzwerks. Sie können die DAG-Netzwerkverschlüsselung mithilfe des Cmdlets Set-DatabaseAvailabilityGroup in der Shell konfigurieren. Die möglichen Verschlüsselungseinstellungen für die DAG-Netzwerkkommunikation sind in der folgenden Tabelle aufgelistet.

Verschlüsselungseinstellungen für die DAG-Netzwerkkommunikation

Einstellung	Beschreibung
Deaktiviert	Die Netzwerkverschlüsselung wird nicht verwendet.
Aktiviert	Die Netzwerkverschlüsselung wird in allen DAG-Netzwerken für Replikation und Seeding verwendet.
InterSubnetOnly	Die Netzwerkverschlüsselung wird in DAG-Netzwerken bei der Replikation über verschiedene Subnetze verwendet. Dies ist die Standardeinstellung.
SeedOnly	Die Netzwerkverschlüsselung wird in allen DAG-Netzwerken nur für Seeding verwendet.

DAG-Netzwerkkomprimierung

DAGs unterstützen die integrierte Komprimierung. Ist die Komprimierung aktiviert, verwendet die DAG-Netzwerkkommunikation XPRESS, die Microsoft-Implementierung des LZ77-Algorithmus. Weitere Informationen finden Sie unter Erläuterung zum Verkleinerungsalgorithmus und in Abschnitt 3.1.7.2, "Kompressionsalgorithmus", der Referenz unter Sendeformat-Protokollspezifikation. Es handelt sich um denselben Komprimierungstyp, der in zahlreichen Microsoft-Protokollen verwendet wird, insbesondere bei der MAPI-RPC-Komprimierung zwischen Outlook und Exchange.

Wie die Netzwerkverschlüsselung ist auch die Netzwerkkomprimierung eine Eigenschaft der DAG, nicht eines DAG-Netzwerks. Sie können die DAG-Netzwerkkomprimierung mithilfe des Cmdlets Set-DatabaseAvailabilityGroup in der Shell konfigurieren. Die möglichen Komprimierungseinstellungen für die DAG-Netzwerkkommunikation sind in der folgenden Tabelle aufgelistet.

Komprimierungseinstellungen für die DAG-Netzwerkkommunikation

Einstellung	Beschreibung
Deaktiviert	Die Netzwerkkomprimierung wird nicht verwendet.
Aktiviert	Die Netzwerkkomprimierung wird in allen DAG-Netzwerken für Replikation und Seeding verwendet.
InterSubnetOnly	Die Netzwerkkomprimierung wird in DAG-Netzwerken bei der Replikation über verschiedene Subnetze verwendet. Dies ist die Standardeinstellung.
SeedOnly	Die Netzwerkkomprimierung wird in allen DAG-Netzwerken nur für Seeding verwendet.

Zurück zum Seitenanfang

DAG-Netzwerke

Ein DAG-Netzwerk ist eine Sammlung aus einem oder mehreren Subnetzen, die für Replikations- oder MAPI-Verkehr verwendet werden. Jede DAG enthält maximal ein MAPI-Netzwerk und kein oder mehr Replikationsnetzwerke. In einer Konfiguration mit einem einzelnen Netzwerkadapter wird das Netzwerk sowohl für den MAPI- als auch für den Replikationsdatenverkehr verwendet. Auch wenn einzelne Netzwerkadapter und -pfade unterstützt werden, sollte jede DAG mindestens zwei DAG-Netzwerke haben. In einer Konfiguration aus zwei Netzwerken ist das eine Netzwerk im Allgemeinen für Replikationsverkehr bestimmt, während das andere Netzwerk primär für MAPI-Verkehr verwendet wird. Sie können auch jedem DAG-Mitglied Netzwerkadapter hinzufügen und weitere DAG-Netzwerke als Replikationsnetzwerke konfigurieren.

Sie können ein DAG-Netzwerk mithilfe des Assistenten für neues DAG-Netzwerk in der Exchange-Verwaltungskonsole oder mithilfe des Cmdlets New-DatabaseAvailabilityGroupNetwork in der Shell erstellen. Genaue Anweisungen zum Erstellen eines Netzwerks mit DAGs finden Sie unter Erstellen eines DAG-Netzwerks.

Sie können die Eigenschaften des DAG-Netzwerks mithilfe des Dialogfelds Eigenschaften in der Exchange-Verwaltungskonsole oder mithilfe des Cmdlets Set-DatabaseAvailabilityGroupNetwork in der Shell konfigurieren. Genaue Anweisungen zum Konfigurieren der Eigenschaften von DAG-Netzwerken finden Sie unter Konfigurieren der Eigenschaften von DAG-Netzwerken. In jedem DAG-Netzwerk müssen erforderliche und optionale Parameter konfiguriert werden:

• Netzwerkname   Ein bis zu 128 Zeichen langer, eindeutiger Name für das DAG-Netzwerk.

• Netzwerkbeschreibung   Eine bis zu 256 Zeichen lange Beschreibung für das DAG-Netzwerk.

• Netzwerksubnetze   Ein oder mehrere Subnetze, die im Format "IP-Adresse/Bitmaske" eingegeben werden (Beispiel: 192.168.1.0/24 für IPv4-Subnetze; 2001:DB8:0:C000::/64 für IPv6-Subnetze).

• Replikation aktivieren   Aktivieren Sie in der Exchange-Verwaltungskonsole das Kontrollkästchen, um das DAG-Netzwerk für Replikationsverkehr zu reservieren und MAPI-Verkehr zu blockieren. Deaktivieren Sie das Kontrollkästchen, um zu verhindern, dass die Replikation das DAG-Netzwerk verwendet, und um den MAPI-Verkehr zu aktivieren. Verwenden Sie in der Shell den Parameter ReplicationEnabled im Cmdlet Set-DatabaseAvailabilityGroupNetwork, um die Replikation zu aktivieren bzw. zu deaktivieren.

Die vom System erstellten anfänglichen DAG-Netzwerke (z. B. DAGNetzwerk01 und DAGNetzwerk02) basieren auf den Subnetzen, die vom Clusterdienst aufgezählt wurden. Jedes DAG-Mitglied muss über dieselbe Anzahl von Netzwerkadaptern verfügen und jeder Netzwerkadapter muss eine IPv4-Adresse (und optional auch eine IPv6-Adresse) in einem eindeutigen Subnetz besitzen. Mehrere DAG-Mitglieder können IPv4-Adressen im gleichen Subnetz besitzen, aber jedes Paar aus Netzwerkadapter und IP-Adresse in einem bestimmten DAG-Mitglied muss sich in einem eindeutigen Subnetz befinden. Außerdem sollte nur der für das MAPI-Netzwerk verwendete Adapter mit einem Standardgateway konfiguriert werden. Replikationsnetzwerke sollten nicht mit einem Standardgateway konfiguriert werden.

Stellen Sie sich z. B. DAG1 vor, eine zwei Mitglieder umfassende DAG, in der jedes Mitglied zwei Netzwerkadapter besitzt (einer für das MAPI-Netzwerk und der andere für das Replikationsnetzwerk). In der nachfolgenden Tabelle sind Beispieleinstellungen für die IP-Adresskonfiguration enthalten.

Beispieleinstellungen für den Netzwerkadapter

Servernetzwerkadapter	IP-Adresse/Subnetzmaske	Standardgateway
EX1-MAPI	192.168.1.15/24	192.168.1.1
EX1-Replikation	10.0.0.15/24	Nicht zutreffend
EX2-MAPI	192.168.1.16	192.168.1.1
EX2-Replikation	10.0.0.16	Nicht zutreffend

In der folgenden Konfiguration werden zwei Subnetze in der DAG konfiguriert: 192.168.1.0 und 10.0.0.0. Beim Hinzufügen von EX1 und EX2 zur DAG werden zwei Subnetze aufgezählt und zwei DAG-Netzwerke erstellt: DAGNetzwerk01 (192.168.1.0) und DAGNetzwerk02 (10.0.0.0). Diese Netzwerke werden, wie in der folgenden Tabelle gezeigt, konfiguriert.

Aufgezählte DAG-Netzwerkeinstellungen für eine DAG mit einzelnem Subnetz

Name	Subnetze	Schnittstellen	MAPI-Zugriff aktiviert	Replikation aktiviert
DAGNetwork01	192.168.1.0/24	EX1 (192.168.1.15) EX2 (192.168.1.16)	True	True
DAGNetwork02	10.0.0.0/24	EX1 (10.0.0.15) EX2 (10.0.0.16)	False	True

Deaktivieren Sie die Replikation für DAGNetzwerk01, indem Sie den folgenden Befehl ausführen, um die Konfiguration von DAGNetzwerk02 als dediziertes Replikationsnetzwerk abzuschließen.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\DAGNetwork01 -ReplicationEnabled:$false

Nachdem die Replikation für DAGNetzwerk01 deaktiviert ist, verwendet der Microsoft Exchange-Replikationsdienst DAGNetzwerk02 für die fortlaufende Replikation. Wenn in DAGNetzwerk02 ein Fehler auftritt, verwendet der Microsoft Exchange-Replikationsdienst wieder DAGNetzwerk01 für die fortlaufende Replikation. Das System geht bewusst auf diese Weise vor, um die hohe Verfügbarkeit zu erhalten.

DAG-Netzwerke und Bereitstellungen mit mehreren Subnetzen

Im vorherigen Beispiel wird die DAG als DAG mit einzelnem Subnetz betrachtet, obwohl zwei unterschiedliche Subnetze verwendet werden (192.168.1.0 und 10.0.0.0), da jedes Mitglied dasselbe Subnetz verwendet, um das MAPI-Netzwerk zu bilden. Wenn die DAG-Mitglieder verschiedene Subnetze für das MAPI-Netzwerk verwenden, wird die DAG als DAG mit mehreren Subnetzen bezeichnet. In einer DAG mit mehreren Subnetzen muss eine zusätzliche Konfiguration der DAG-Netzwerke ausgeführt werden, um die richtigen Subnetze den einzelnen DAG-Netzwerken zuzuordnen.

Stellen Sie sich z. B. DAG2 vor, eine zwei Mitglieder umfassende DAG, in der jedes Mitglied zwei Netzwerkadapter besitzt (einer für das MAPI-Netzwerk und der andere für das Replikationsnetzwerk), und jedes DAG-Mitglied befindet sich an einem separaten Active Directory-Standort, während das jeweiige MAPI-Netzwerk in einem anderen Subnetz enthalten ist. In der nachfolgenden Tabelle sind Beispieleinstellungen für die IP-Adresskonfiguration enthalten.

Beispieleinstellungen für einen Netzwerkadapter für eine DAG mit mehreren Subnetzen

Servernetzwerkadapter	IP-Adresse/Subnetzmaske	Standardgateway
EX1-MAPI	192.168.0.15/24	192.168.0.1
EX1-Replikation	10.0.0.15/24	Nicht zutreffend
EX2-MAPI	192.168.1.15	192.168.1.1
EX2-Replikation	10.0.1.15	Nicht zutreffend

In der folgenden Konfiguration werden vier Subnetze in der DAG konfiguriert: 192.168.0.0, 192.168.1.0, 10.0.0.0 und 10.0.1.0. Beim Hinzufügen von EX1 und EX2 zur DAG werden vier Subnetze aufgezählt und zwei DAG-Netzwerke erstellt: DAGNetzwerk01 (192.168.1.0), DAGNetzwerk02 (10.0.0.0), DAGNetzwerk03 (192.168.1.0) und DAGNetzwerk04 (10.0.1.0). Diese Netzwerke werden, wie in der folgenden Tabelle gezeigt, konfiguriert.

Aufgezählte DAG-Netzwerkeinstellungen für eine DAG mit mehreren Subnetzen

Name	Subnetze	Schnittstellen	MAPI-Zugriff aktiviert	Replikation aktiviert
DAGNetwork01	192.168.0.0/24	EX1 (192.168.0.15)	Wahr	Wahr
DAGNetwork02	10.0.0.0/24	EX1 (10.0.0.15)	False	Wahr
DAGNetwork03	192.168.1.0/24	EX2 (192.168.1.15)	True	True
DAGNetwork04	10.0.1.0/24	EX2 (10.0.1.15)	False	True

Damit die erforderliche Konfiguration abgeschlossen wird, sollten DAGNetzwerk03 und DAGNetzwerk04 in DAGNetzwerk01 bzw. DAGNetzwerk02 ausgeblendet werden. Dies umfasst das Hinzufügen des momentan zu DAGNetzwerk03 zugeordneten Subnetzes zu DAGNetzwerk01 sowie das Hinzufügen des momentan zu DAGNetzwerk04 zugeordneten Subnetzes zu DAGNetzwerk02. Dadurch werden die Subnetzzuordnungen von DAGNetzwerk03 und DAGNetzwerk04 entfernt, die dadurch als leere DAG-Netzwerke verbleiben und dann entfernt werden können. Zum Ausblenden der Subnetze in zwei DAG-Netzwerke und zum Deaktivieren der Replikation im MAPI-Netzwerk führen Sie die folgenden Befehle aus.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork01 -Subnets 192.168.0.0,192.168.1.0 -ReplicationEnabled:$false
Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -Subnets 10.0.0.0,10.0.1.0
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork03
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork04

DAG-Netzwerke und iSCSI-Netzwerke

Standardmäßig führen DAGs die Ermittlung aller Netzwerke durch, die erkannt und für die Verwendung durch den zugrunde liegenden Cluster konfiguriert wurden. Dazu gehören alle iSCSI-Netzwerke (Internet SCSI), die sich als iSCSI-Speicher für ein oder mehrere DAG-Mitglieder in Verwendung befinden. Es wird empfohlen, dass iSCSI-Speicher dedizierte Netzwerke und Netzwerkadapter verwenden. Diese Netzwerke sollten nicht durch die DAG oder deren Cluster verwaltet oder als DAG-Netzwerke (MAPI oder Replikation) verwendet werden. Stattdessen sollten diese Netzwerke manuell für die Verwendung durch die DAG deaktiviert werden, damit sie für iSCSI-Speicherverkehr reserviert werden können. Damit iSCSI-Netzwerke nicht als DAG-Netzwerke erkannt und verwendet werden, konfigurieren Sie die DAG so, dass alle aktuell erkannten iSCSI-Netzwerke ignoriert werden. Verwenden Sie dazu das Cmdlet Set-DatabaseAvailabilityGroupNetwork, wie in diesem Beispiel gezeigt:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true

Dieser Befehl deaktiviert auch die Verwendung des Netzwerks durch den Cluster. Nach Ausführung des oben stehenden Befehls werden die iSCSI-Netzwerke zwar weiterhin als DAG-Netzwerke angezeigt, jedoch nicht für MAPI- oder Replikationsdatenverkehr verwendet.

Zurück zum Seitenanfang

Konfigurieren von DAG-Mitgliedern

Postfachserver, die Mitglieder einer DAG sind, weisen einige für die hohe Verfügbarkeit spezifische Eigenschaften auf, die gemäß den Beschreibungen in den folgenden Abschnitten konfiguriert werden sollten:

• Automatisches Einbinden von Datenbanken

• Automatische Aktivierungsrichtlinie für die Datenbankkopie

• Maximale Anzahl aktiver Datenbanken

Automatisches Einbinden von Datenbanken

Der Parameter AutoDatabaseMountDial gibt das Verhalten für das automatische Einbinden von Datenbanken nach einem Datenbankfailover an. Mithilfe des Cmdlets Set-MailboxServer können Sie den Parameter AutoDatabaseMountDial mit den folgenden Werten konfigurieren:

• BestAvailability   Wenn dieser Wert angegeben wird, wird die Datenbank sofort nach einem Failover automatisch bereitgestellt, wenn die Länge der Kopiewarteschlange kleiner oder gleich 12 ist. Die Länge der Kopiewarteschlange entspricht der Anzahl von Protokollen, die von der passiven Kopie als zu replizieren erkannt werden. Wenn die Länge der Kopiewarteschlange größer als 12 ist, wird die Datenbank nicht automatisch bereitgestellt. Wenn die Länge der Kopiewarteschlange kleiner oder gleich 12 ist, versucht Exchange die verbleibenden Protokolle auf die passive Kopie zu replizieren und stellt die Datenbanken bereit.

• GoodAvailability   Wenn dieser Wert angegeben wird, wird die Datenbank sofort nach einem Failover automatisch bereitgestellt, wenn die Länge der Kopiewarteschlange kleiner oder gleich sechs ist. Die Länge der Kopiewarteschlange entspricht der Anzahl von Protokollen, die von der passiven Kopie als zu replizieren erkannt werden. Wenn die Länge der Kopiewarteschlange größer als sechs ist, wird die Datenbank nicht automatisch bereitgestellt. Wenn die Länge der Kopiewarteschlange kleiner oder gleich sechs ist, versucht Exchange die verbleibenden Protokolle auf die passive Kopie zu replizieren und stellt die Datenbanken bereit.

• Lossless   Wenn dieser Wert angegeben wird, werden die Datenbanken erst dann automatisch bereitgestellt, nachdem alle Protokolle, die auf der aktiven Kopie generiert wurden, auf die passive Kopie kopiert wurden. Diese Einstellung führt auch dazu, dass der Auswahlalgorithmus für den optimalen Kopiervorgang von Active Manager die potenziellen Kandidaten für die Aktivierung auf Grundlage des Aktivierungseinstellungswerts und nicht der Länge der Kopierwarteschlange sortiert wird.

Der Standardwert ist GoodAvailability. Wenn BestAvailability oder GoodAvailability angegeben wird und nicht alle Protokolle von der aktiven Kopie zur aktivierten passiven Kopie kopiert werden können, kann es zum Verlust von Postfachdaten kommen. Die Funktion "Transportdumpster" (die standardmäßig aktiviert ist) unterstützt Sie aber beim Schutz vor den meisten Datenverlusten, indem Nachrichten, die sich in der Transportdumpster-Warteschlange befinden, erneut übermittelt werden.

Zusätzlich zu den vorherigen Werten können Sie auch den Parameter AutoDatabaseMountDial mit einem benutzerdefinierten Wert konfigurieren, indem Sie den ADSI-Editor oder "Ldp.exe" verwenden, um das Attribut direkt in Active Directory zu ändern. Der Parameter AutoDatabaseMountDial wird durch das Attribut msExchDataLossForAutoDatabaseMount des Postfachserverobjekts dargestellt. Der ganzzahlige Wert für dieses Attribut stellt die maximale Anzahl von Transaktionsprotokolldateien dar, die Sie bereit sind, für das Einbinden einer Datenbank ohne menschliches Eingreifen zu verlieren. Wenn Sie den Parameter AutoDatabaseMountDial mit einem benutzerdefinierten Wert konfigurieren, der größer als 12 ist, wird empfohlen, dass Sie auch die Größe des Transportdumpsters erhöhen, um den erhöhten Schutz vor einer größeren Anzahl verlorener Protokolle zu aktivieren.

Beispiel: Konfigurieren des Automatischen Einbindens von Datenbanken

Im folgenden Beispiel wird ein Postfachserver mit einer AutoDatabaseMountDial-Einstellung von GoodAvailability konfiguriert.

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

Automatische Aktivierungsrichtlinie für die Datenbankkopie

Der Parameter DatabaseCopyAutoActivationPolicy gibt den Typ der automatischen Aktivierung an, der für Postfachdatenbankkopien auf ausgewählten Postfachservern verfügbar ist. Mithilfe des Cmdlets Set-MailboxServer können Sie den Parameter DatabaseCopyAutoActivationPolicy mit den folgenden Werten konfigurieren:

• Blocked   Wenn Sie diesen Wert angeben, können Datenbanken auf den ausgewählten Postfachservern nicht automatisch aktiviert werden.

• IntrasiteOnly   Wenn Sie diesen Wert angeben, kann die Datenbankkopie auf Servern am gleichen Active Directory-Standort aktiviert werden. Dadurch wird ein Failover oder eine Aktivierung zwischen Standorten vermieden. Diese Eigenschaft gilt für eingehende Postfachdatenbankkopien (z. B. für eine passive Kopie, die von einer aktiven Kopie erstellt wird). Datenbanken können auf diesem Postfachserver nicht für Datenbankkopien aktiviert werden, die an einem anderen Active Directory-Standort aktiv sind.

• Unrestricted   Wenn Sie diesen Wert angeben, gelten keine besonderen Einschränkungen für die Aktivierung von Postfachdatenbankkopien auf den ausgewählten Postfachservern.

Beispiel: Konfigurieren der automatischen Aktivierungsrichtlinie für die Datenbankkopie

Im folgenden Beispiel wird ein Postfachserver mit einer DatabaseCopyAutoActivationPolicy-Einstellung von Blocked konfiguriert.

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

Maximale Anzahl aktiver Datenbanken

Der Parameter MaximumActiveDatabases (der auch mit dem Cmdlet Set-MailboxServer verwendet wird) gibt die Anzahl von Datenbanken an, die auf einem Postfachserver eingebunden werden können. Sie können Postfachserver derart konfigurieren, dass sie Ihren Bereitstellungsanforderungen entsprechen, indem Sie sicherstellen, dass ein einzelner Postfachserver nicht überlastet wird.

Der Parameter MaximumActiveDatabases wird mit einem ganzzahligen Wert konfiguriert. Wenn die maximale Anzahl erreicht ist, werden die Datenbankkopien auf dem Server bei einem Failover oder Switchover nicht aktiviert. Sind die Kopien auf einem Server bereits aktiv, lässt der Server die Einbindung der Datenbanken nicht zu.

Beispiel: Konfigurieren der maximalen Anzahl aktiver Datenbanken

Im folgenden Beispiel wird ein Postfachserver für die Unterstützung von maximal 20 aktiven Datenbanken konfiguriert.

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

Zurück zum Seitenanfang

Ausführen des Wartungsprozesses auf DAG-Mitgliedern

Bevor Sie eine Software- oder Hardwarewartung auf einem DAG-Mitglied ausführen, sollten Sie zuerst das DAG-Mitglied mithilfe des Skripts "StartDagServerMaintenance.ps1" aus dem Dienst entfernen. Dieses Skript verschiebt alle aktiven Datenbanken vom Server und hindert aktive Datenbanken daran, auf diesen Server verschoben zu werden. Das Skript stellt außerdem sicher, dass alle wichtigen DAG-Unterstützungsfunktionen, die sich möglicherweise auf dem Server befinden (z. B. die PAM-Rolle), auf einen anderen Server verschoben und daran gehindert werden, wieder auf diesen Server zurück verschoben zu werden. Das Skript "StartDagServerMaintenance.ps1" führt insbesondere die folgenden Aufgaben aus:

• Führt Suspend-MailboxDatabaseCopy mit dem Parameter ActivationOnly aus, um die Aktivierung jeder auf dem DAG-Mitglied gehosteten Datenbankkopie anzuhalten.

• Hält den Knoten im Cluster an, der verhindert, dass der Knoten der PAM (Primary Active Manager) ist oder wird.

• Legen Sie für den Wert des Parameters DatabaseCopyAutoActivationPolicy des DAG-Mitglieds auf Blocked fest.

• Verschieben Sie alle derzeit auf dem DAG-Mitglied gehosteten aktiven Datenbanken auf andere DAG-Mitglieder.

• Wenn das DAG-Mitglied momentan im Besitz der Standardclustergruppe ist, verschiebt das Skript die Standardclustergruppe (und daher die PAM-Rolle) auf ein anderes DAG-Mitglied.

Wenn eine der vorhergehenden Aufgaben fehlschlägt, werden sämtliche Vorgänge mit Ausnahme der erfolgreichen Datenbankverschiebungen rückgängig gemacht.

Nachdem die Wartung abgeschlossen und das DAG-Mitglied bereit ist, den Dienst wieder aufzunehmen, können Sie das Skript "StopDagServerMaintenance.ps1" verwenden, um das DAG-Mitglied aus dem Wartungsmodus zurück in den Produktionsmodus zu versetzen. Das Skript "StopDagServerMaintenance.ps1" führt insbesondere die folgenden Aufgaben aus:

• Führt das Cmdlet Resume-MailboxDatabaseCopy für jede Datenbankkopie aus, die auf dem DAG-Mitglied gehostet wird.

• Setzt den Knoten im Cluster fort, wodurch die uneingeschränkte Clusterfunktionalität für die DAG-Mitglieder aktiviert wird.

• Legen Sie für den Wert des Parameters DatabaseCopyAutoActivationPolicy des DAG-Mitglieds auf Unrestricted fest.

Beide Skripts akzeptieren den Parameter -ServerName (bei dem es sich entweder um den Hostnamen oder den vollständig qualifizierten Domänennamen (FQDN) des DAG-Mitglieds handeln kann) und den Parameter -WhatIf. Beide Skripts können lokal oder remote ausgeführt werden. Auf dem Server, auf dem die Skripts ausgeführt werden, müssen die Tools zur Windows-Failoverclusterverwaltung (RSAT-Clustering) installiert sein.

Zurück zum Seitenanfang

Herunterfahren von DAG-Mitgliedern

Die Exchange 2010-Lösung mit hoher Verfügbarkeit ist in den Windows-Prozess zum Herunterfahren integriert. Wenn ein Administrator oder eine Anwendung das Herunterfahren eines Windows-Servers in einer DAG mit einer eingebundenen Datenbank initiiert, die an eine oder mehrere DAG-Mitglieder repliziert wird, versucht das System, eine andere Kopie der eingebundenen Datenbank zu aktivieren, bevor der Server heruntergefahren werden kann.

Dieses neue Verhalten gewährleistet jedoch keine lossless-Aktivierung aller Datenbanken auf dem Server, der heruntergefahren wird. Deshalb wird empfohlen, vor dem Herunterfahren eines Servers, der Mitglied einer DAG ist, einen Serverswitchover durchzuführen. Genaue Anweisungen zum Durchführen eines Serverswitchovers finden Sie unter Ausführen eines Serverswitchovers.

Zurück zum Seitenanfang

Installieren von Updaterollups auf DAG-Mitgliedern

Das Installieren von Microsoft Exchange Server 2010-Updaterollups auf einem Server, der Mitglied einer Database Availability Group (DAG) ist, ist ein relativ einfacher Prozess. Wenn Sie ein Updaterollup auf einem Server installieren, der Mitglied einer DAG ist, werden mehrere Dienste während der Installation angehalten, darunter auch alle Exchange-Dienste und der Clusterdienst. Die allgemeine Vorgehensweise zum Zuweisen von Updaterollups zu einem DAG-Mitglied ist folgende:

1. Verwenden Sie das Skript "StartDagServerMaintenance.ps1", um das DAG-Mitglied in den Wartungsmodus zu versetzen.

2. Installieren Sie das Updaterollup.

3. Mithilfe des Skripts "StopDagServerMaintenance.ps1" versetzen Sie das DAG-Mitglied aus dem Wartungsmodus zurück in den Produktionsmodus.

4. Verwenden Sie das Skript "RedistributeActiveDatabases.ps1", um die aktiven Datenbankkopien für die DAG neu auszugleichen.

Sie können das aktuelle Updaterollup für Exchange 2010 im Microsoft Download Center herunterladen. Genaue Anweisungen zum Installieren eines Updaterollups auf einem DAG-Mitglied finden Sie unter Installieren von Updaterollups für Mitglieder einer Datenbankverfügbarkeitsgruppe.

Zurück zum Seitenanfang

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.