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

Vis-a-Vis [3.06.2020]

EGroupware bietet ab sofort mit der Integration von "Jitsi" ein Modul für Videokonferenzen. Über die Statusleiste sehen Anwender dabei, wer online ist. Mit diesen Mitarbeitern lassen sich ad hoc virtuelle Meetings veranstalten. [mehr]

Programm für IoT-, Blockchain- und KI-Start-ups [28.05.2020]

Telefónica hat gemeinsam mit dem eigenen Innovation Hub wayra ein Programm für Start-ups gestartet. Dabei soll der Fokus des Programms insbesondere auf den Technologie-Bereichen Internet der Dinge, Blockchain sowie Big Data und Künstliche Intelligenz liegen. Für die Laufzeit des sechsmonatigen Programms erhalten die Start-ups die Möglichkeit, die verschiedenen Plattformen des Telekommunikationskonzerns kennenzulernen und über API-Schnittstellen zu nutzen. [mehr]

Scan all you can [30.03.2020]

Tipps & Tools

Download der Woche: Krisp [8.07.2020]

Vor allem bei Video- oder Audiokonferenzen ist eine leise Umgebung sehr wichtig. Mit dem kostenlosen Tool "Krisp" können Sie Hintergrundgeräusche, die gerade im Home Office recht häufig entstehen, per Knopfdruck reduzieren. Die Software unterstützt derzeit über 800 Apps, unter anderem Zoom, Microsoft Teams und Skype. [mehr]

Intensiv-Seminare PowerShell und PKI [6.07.2020]

Da unsere Intensiv-Seminare in Kleingruppen abgehalten werden, ist jederzeit für den gebotenen Abstand gesorgt. Wir freuen uns deshalb, Ihnen neue Termine für unsere beiden Intensiv-Seminare "PowerShell für Admins" und "Aufbau einer PKI unter Windows" mitzuteilen. Letzteres findet im Dezember statt und führt Sie Schritt für Schritt durch den Aufbau einer PKI unter Windows Server. Noch sind dafür Teilnahmeplätze zu haben, ebenso für das Intensiv-Seminar "PowerShell für Admins" im Dezember. Abonnenten nehmen wie immer zum Vorzugspreis teil. [mehr]

Buchbesprechung

Microsoft Office 365

von Markus Widl

Anzeigen