Fachartikel

Datenbankverfügbarkeitsgruppen in Exchange 2016 (3)

Datenbankverfügbarkeitsgruppen – DAGs – halten Exchange-Datenbanken zwischen verschiedenen Servern synchron. Diese Absicherung ist bereits ab zwei Exchange-Servern sinnvoll und erhöht die Verfügbarkeit deutlich, ohne, dass ein teurer Cluster zum Einsatz kommen muss. Wir zeigen, wie sich DAGs über die Exchange Management Shell schnell einrichten lassen und wie die Steuerung der Replikation klappt. Im dritten und letzten Teil des Workshops beschäftigen wir uns mit einem Server- und Rechenzentrumswitchover.
DAGs halten Exchange-Datenbanken zwischen verschiedenen Servern synchron.
Server- und Rechenzentrumswitchover
Bei einem Serverswitchover schalten Sie alle aktiven Postfachdatenbanken vom aktuellen Postfachserver auf einen oder mehrere Postfachserver mit entsprechenden Postfachdatenbankkopien um. Navigieren Sie dazu im Exchange Admin Center zu "Server". Wählen Sie den gewünschten Postfachserver aus, auf dem aktuell die produktiven Datenbanken gespeichert sind, und klicken auf den Server. Wählen Sie "Serverswitchover" aus.

Anschließend können Sie Exchange die Wahl überlassen, welche Postfachdatenbankkopien auf den verschiedenen Servern mit den Kopien aktiv geschaltet werden, oder Sie wählen manuell einen Zielserver aus, auf dem Exchange die Postfachdatenbankkopien zukünftig als produktive Datenbanken einsetzt.

In der Exchange Management Shell funktioniert das Ganze dann folgendermaßen:
Move-ActiveMailboxDatabase 
 -Server <Quellserver>
 -ActivateOnServer <Zielserver>
Sie können für DAGs einen speziellen Modus für Rechenzentren aktivieren. Dies ist sinnvoll, wenn Sie größere DAGs betreiben und diese über verschiedene AD-Standorte verteilt sind. Der Modus ist standardmäßig deaktiviert. Ist der Modus nicht aktiviert, startet nach einem Ausfall die Datenbankverfügbarkeitsgruppe neu und versucht, die Datenbanken bereitzustellen. In einer Konfiguration mit mehreren Datencentern kann dieses Verhalten zu Problemen führen, wenn Mitglieder der DAGs untereinander nicht mehr kommunizieren können.

Fallen in einem Rechenzentrum alle Server und die Verbindung zu anderen Rechenzentren aus, können Sie ein Standby-Rechenzentrum aktivieren. Ist die Netzwerkverbindung zwischen den Rechenzentren wieder aktiv, fährt Exchange normalerweise die Mitglieder der Datenbankverfügbarkeitsgruppe im ausgefallenen Rechenzentrum wieder hoch. Das zentrale Rechenzentrum sollte immer das Quorum der Datenbankverfügbarkeitsgruppe haben, also die Mehrzahl der Mitglieder, einschließlich des Zeugenservers.

Auf diese Weise verfügt das zentrale Rechenzentrum über die Mehrheit der DAG, also die meisten Server des Clusters, auch wenn keine Verbindung zu den Mitgliedern der Datenbankverfügbarkeitsgruppe im Standby-Rechenzentrum besteht. Hierbei kann es allerdings zu Problemen kommen, da Exchange Datenbanken im zentralen Rechenzentrum bereitstellt, in denen andere Daten gespeichert sind als in den produktiven Datenbanken, die aktuell im aktivierten Standby-Rechenzentrum bereitgestellt sind.
Der Active Manager, das Kontrollmodul in Exchange zur Steuerung der DAG, speichert ein Flag (0 oder 1) im Arbeitsspeicher. Dieses Bit legt fest, ob die lokale DAG lokale Datenbanken, die auf dem Server als aktiv zugewiesen sind, bereitstellen darf. Haben Sie für eine Datenbankverfügbarkeitsgruppe den Rechenzentrum-Aktivierungsmodus aktiviert, setzt Exchange das Bit auf 0, was bedeutet, dass Exchange die Datenbanken nicht automatisch bereitstellt.

Dadurch muss der Server erst versuchen, ob er mit allen Mitgliedern der Datenbankverfügbarkeitsgruppe kommunizieren kann. Antwortet ein anderer Server, dass sein Bit auf 1 gesetzt ist, bedeutet das, dass die Server Datenbanken automatisch bereitstellen dürfen. Bei der Wiederherstellung eines zentralen Rechenzentrums nach einem Stromausfall, bei dem die Server funktionieren, aber nicht die Verbindung zu den anderen Rechenzentren, ist bei allen Mitgliedern der Datenbankverfügbarkeitsgruppe im zentralen Rechenzentrum das Bit auf den Wert "0" gesetzt.

Aus diesem Grund stellt keiner der Server im Rechenzentrum automatisch Datenbanken bereit, da die Server nicht mit einem Mitglied der Datenbankverfügbarkeitsgruppe kommunizieren können, das im Rechenzentrum-Aktivierungsprotokoll einen Bit-Wert von 1 zurückmeldet. Den Aktivierungsmodus für Rechenzentren starten Sie in der Exchange Management Shell mit dem Cmdlet Set-DatabaseAvailabilityGroup, also etwa mit:
Set-DatabaseAvailabilityGroup 
-Identity DAG1
-DatacenterActivationMode DagOnly
Die DAG-Mitglieder im primären Datencenter müssen als beendet gekennzeichnet sein, damit die Datenbanken nicht versehentlich bereitgestellt werden. Dazu verwenden Sie am Standort das Cmdlet Stop-DatabaseAvailabilityGroup und die Option "ActiveDirectorySite". Sie müssen das Stop-Cmdlet auf allen Servern im zentralen Rechenzentrum ausführen.

Im zweiten Rechenzentrum, dem Standby-Zentrum, müssen Sie herausfinden, welche Server des zentralen Rechenzentrums beendet wurden. Dazu verwenden Sie ebenfalls das Cmdlet Stop-DatabaseAvailabilityGroup mit den Optionen "ConfigurationOnly" und "ActiveDirectorySite" mit dem Namen des Active-Directory-Standorts im ausgefallenen zentralen Rechenzentrum.

Für DAG-Mitglieder im zentralen Rechenzentrum müssen Sie Cluster der Datenbankverfügbarkeitsgruppe entfernen, wenn die Bereinigung nicht korrekt funktioniert. Verwenden Sie dazu auf den Servern im zentralen Rechenzentrum die folgenden beiden Befehle in der Eingabeaufforderung:
Net stop clussvc Cluster <DAG> node <DAG-Mitglied> /forcecleanup
Die Mitglieder der DAG im zweiten Rechenzentrum starten Sie neu und schließen damit den entsprechenden Vorgang ab. Halten Sie den Cluster-Dienst für jedes Mitglied der Datenbankverfügbarkeitsgruppe im zweiten Datencenter an, indem Sie den Befehl Net stop clussvc verwenden. Geben Sie auf einem DAG-Mitglied im zweiten Rechenzentrum den folgenden Befehl ein, um das Quorum, die Steuerung des DAG-Clusters, zu übernehmen:
Net start clussvc /forcequorum
Starten Sie dann den Failovercluster-Manager und stellen Sie die Verbindung mit dem Cluster der Datenbankverfügbarkeitsgruppe her. Navigieren Sie zu "<Clustername> / Knoten". Klicken Sie mit der rechten Maustaste auf jeden Knoten im zentralen Rechenzentrun und wählen Sie "Weitere Aktionen/Entfernen".

Befindet sich die Datenbankverfügbarkeitsgruppe im Aktivierungsmodus für die Datenbanken, sollten Sie diesen Modus auf jedem DAG-Mitglied im zweiten Rechenzentrum beenden, zum Beispiel mit dem Cmdlet Stop-Service ClusSvc. Alternativ können Sie dazu auch Net stop clussvc verwenden.

Die Postfachserver im zweiten Rechenzentrum aktivieren Sie mit Restore-DatabaseAvailabilityGroup für die Übernahme. Den Active-Directory-Standort des zweiten Rechenzentrums nutzen Sie mit dem Cmdlet Restore-DatabaseAvailabilityGroup. Nach den Vorbereitungen führen Sie auf den Servern im ausgefallenen zentralen Rechenzentrum ein Serverswitchover durch. Dazu können Sie natürlich wie immer auch die Exchange Management Shell verwenden:
Move-ActiveMailboxDatabase 
-Server <DAG-Server im ausgefallenen zentralen Rechenzentrum>
-ActivateOnServer <DAG-Server im Standby-Rechenzentrum>
Stellen Sie manuell alle Datenbanken im zweiten Rechenzentrum bereit. Ist das zentrale Rechenzentrum wieder verfügbar, übertragen Sie schließlich die Verwaltung der DAG wieder zum zentralen Rechenzentrum.

Fazit
Datenbankverfügbarkeitsgruppen bieten für Unternehmen eine effiziente Absicherung der Exchange-Datenbanken. Auch wenn recht viele unterschiedliche Steuerungsmöglichkeiten im Exchange Admin Center und der Exchange Management Shell zur Verfügung stehen, ist die Verwaltung nicht sehr kompliziert.

In den meisten Fällen sollten die DAGs nach der Einrichtung von allein laufen. Wenn doch etwas schiefgeht, steht zumindest ein gewisser Ausfallschutz zur Verfügung, mit dem sich Exchange weitgehend automatisch reparieren kann.

Im ersten Teil des Workshops haben wir das Prinzip des Failoverclusters erklärt und wie Sie DAGs erstellen, löschen und in der Shell anpassen. Im zweiten Teil ging es um das Einrichten und Verwalten von Postfachdatenbankkopien.
15.06.2020/ln/Thomas Joos

Nachrichten

Privatsphäre in der Cloud [15.10.2020]

ONLYOFFICE veröffentlicht ein Update für die Kollaborationsplattform "Groups 11.0" und seine Dokumenten-Editoren namens "Docs 6.0". Mit an Bord sind neue Tabellenfunktionen, zusätzliche Produktivitätsfeatures und Private Rooms. Mit letzteren lassen sich Dokumente in der Cloud sicher gemeinsam bearbeiten. [mehr]

BT bietet Zoom als Service an [13.10.2020]

Der Kommunikationsdienstleister BT bietet seinen Kunden den Video-Dienst Zoom Meetings als gemanagten Service an. Basierend auf einem Carrier Agreement mit Zoom Video Communications erweitert BT damit das Portfolio seiner Cloud-basierten Audio- und Video-Collaboration-Services für multinationale Geschäftskunden. [mehr]

Tipps & Tools

Filesharing im gleichen Netzwerk [24.10.2020]

Wenn Sie eine Notiz oder Datei mit Ihren Kollegen teilen möchten, ist nicht unbedingt eine E-Mail oder bestimmte App notwendig. Auf der Webseite "ssavr.com" können Sie Textnachrichten oder Dateien schnell für andere verfügbar machen. Jeder, der sich im gleichen Netzwerk befindet und den Link aufruft, kann auf die Inhalte zugreifen. [mehr]

Open Document Foundation kritisiert OpenOffice-Stillstand [23.10.2020]

Die Open Document Foundation, die Stiftung hinter LibreOffice, hat einen offenen Brief an Apache OpenOffice verfasst. Darin kritisiert die Foundation den Stillstand von OpenOffice und fordert dessen Macher dazu auf, das lebendige LibreOffice zu unterstützen. [mehr]

Buchbesprechung

Windows 10 Pannenhilfe

von Wolfram Gieseke

Anzeigen