Mit Exchange 2019 wurde das bekannte Prinzip der Database Availability Group (DAG) übernommen. Große Änderungen an der DAG gibt es nicht. Allerdings hat sich etwas an den Datenbanken geändert. Der Index ist nun Teil der Datenbank und geistert nicht mehr separat im Filesystem rum. Des weiteren gibt es mit Exchange 2019 die Möglichkeit SSDs als Datenbank Cache einzusetzen (MetaCache Database, MCDB), dies funktioniert allerdings nur mit einer DAG.
Dieser Artikel widmet sich der Konfiguration einer Exchange 2019 DAG, bestehend aus zwei Servern. Die MetaCache Database (MCDB) ist dann Bestandteil weiterer Artikel.
Umgebung
Die Exchange 2019 Testumgebung besteht aus insgesamt 4 Servern: Einen Domain Controller (DC1), 2 Exchange Server (EX1, EX2) und einem FileServer (FS1). Alle Server verwenden Windows Server 2019 als Betriebssystem.
Das Active Directory hört auf den Namen frankysweblab.de. Ein Loadbalancer für die Hochverfügbarkeit des CAS-Dienstes ist zunächst nicht Teil dieser Testumgebung, ich werde hier zunächst das DNS verwenden. Dazu später mehr.
Die beiden Exchange Server wurden nach dieser Anleitung installiert, die grundlegende Konfiguration der beiden Exchange Server ist ebenfalls bereits abgeschlossen und bezieht sich auf diese Anleitung. Beide Exchange Server wurden mit den gleichen URLs konfiguriert, dem Sendeconnector wurden beide Exchange Server als Quellserver hinzugefügt.
Auf der Server FS1 ist nur die Rolle “Dateiserver” installiert.
Der Vollständigkeit halber hier noch die IP-Adressen der Server:
- DC1: 192.168.200.12
- FS1: 192.168.200.13
- EX1: 192.168.200.14
- EX2: 192.168.200.15
Für Tests gibt es einen Client mit installiertem Outlook 2019.
Vorbereitung
Zunächst gilt es einmal den Fileserver FS1 vorzubereiten. Auf dem Server muss die Gruppe “Exchange Trusted Subsystem” in die Gruppe der lokalen “Administratoren” hinzugefügt werden:
Dies ist auch schon alles. FS1 wird das Zeugenverzeichnis für die DAG bereitstellen. Wichtig ist, dass die Rolle Dateiserver auf dem FileServer installiert ist, da es sonst beim Erstellen der DAG zu einer Fehlermeldung kommt:
Das Zeugenverzeichnis in einer 2-Server DAG dient Im Fehlerfall zur Feststellung welcher der beiden Server ausgefallen ist. Das Zeugenverzeichnis darf nicht auf einem Domain Controller abgelegt werden, da hier sonst die Gruppe “Exchange Trusted Subsystem” ebenfalls über die Gruppe Administratoren weitreichende Berechtigungen auf das Active Directory erhalten würde. Daher lieber einen vorhandenen FileServer für das Zeugenverzeichnis wählen.
Konfiguration der DAG
Das Erstellen der DAG ist denkbar einfach. Unter dem Reiter “Database Availability Groups” kann mit dem “Plus-Zeichen” eine neue DAG angelegt werden. Es muss nur ein Name für DAG, der FQDN des Zeugenservers (in diesem Fall also FS1) und ein Pfad für das Zeugenverzeichnis angegeben werden. Im Feld IP-Adresse wird 255.255.255.255 eingegeben, somit wird eine IP-Less DAG erzeugt:
Nachdem die DAG erstellt wurde, können die Mitgliedserver hinzugefügt werden:
In diesem Fall müssen nun beide Exchange Server als Mitglieder der DAG angegeben werden:
Nach einem Klick auf “Speichern” werden die Server zur DAG hinzugefügt, dies kann einen Moment dauern. Falls es hier zu einem Fehler kommt, dann bitte den Tipp am Ende dieses Abschnitts lesen.
Nach ein paar Minuten sind die beiden Server als Mitglieder der neuen DAG konfiguriert:
Somit steht das Grundgerüst für die Datenbankkopien.
Damit die Datenbanken im Falle eines Ausfalls oder zu Wartungszwecken auf einem anderen Exchange Server aktiviert werden können, muss für jede Datenbank eine Kopie auf dem jeweils anderen Server erstellt werden. Dies geschieht im nächsten Schritt.
Tipp: Es kann beim Hinzufügen der Exchange Server zur DAG zu folgendem Fehler kommen:
Fehler beim serverseitigen Verwaltungsvorgang für eine Database Availability Group. Fehler: Fehler bei Vorgang. CreateCluster-Fehler können von falsch konfigurierten statischen Adressen verursacht werden. Fehler: Das Windows-Failoverclustering ist auf ‚EX1.frankysweblab.de‘ nicht installiert.
In diesem Fall müssen die Exchange Server einmal neu gestartet werden. Das Feature “Windows Failoverclustering” wird zwar beim Hinzufügen der Server zur DAG installiert, fordert aber einen Neustart des Servers an:
Nachdem die Server neu gestartet sind, lassen sich die Server zur DAG hinzufügen.
Datenbankkopie hinzufügen
Damit Exchange Datenbanken hochverfügbar sind, muss es mindestens eine Kopie auf einem anderen Exchange Server geben. Die Datenbankkopien können jetzt konfiguriert werden, die Einstellungen können für jede Datenbank individuell vorgenommen werden. In einer 2-Server DAG sind die Möglichkeiten natürlich stark eingeschränkt, hier kann nur der jeweils andere Server eine Kopie der aktiven Datenbank hosten.
Wichtig: Ein Exchange 2019 Server in der Standard Edition kann nur maximal 5 aktive Datenbanken hosten. Hier dürfen also nur maximal 5 Datenbanken angelegt werden, bezogen auf dieses Beispiel darf EX1 also nur 3 aktive Datenbanken und EX2 nur 2 aktive Datenbanken hosten. Im Fehlerfall wären somit 5 Datenbanken auf einem Exchange Server aktiv. Exchange Server in der Enterprise Edition hat dieses Limit nicht.
Die Datenbankkopien können ebenfalls im Exchange Admin Center auf dem Reiter “Datenbanken” konfiguriert werden:
Hier kann nun der Exchange Server für die Kopie angegeben werden:
Die Datenbank und die Logfiles werden nun auf den Server für die Kopie übertragen:
Tipp: Falls die DAG nachträglich konfiguriert wird und die Datenbanken schon einige Postfächer / Daten beinhalten, bietet es sich an, die Kopie nach der Vollsicherung hinzuzufügen. Somit müssen nicht mehr so viele Logs von Server zu Server kopiert werden.
Nachdem beide Datenbanken eine Kopie haben, wird der Status im Exchange Admin Center wie folgt dargestellt:
Jetzt kann mit den Tests begonnen werden.
Hier kann zwischen Switchover und Failover unterschieden werden. Der Switchover ist ein geplantes Ereignis, etwa zu Wartungszwecken. Beim Switchover wird also bewusst die aktive Kopie auf einen anderen Server verlagert. Der Failover tritt ein, wenn beispielsweise die Hardware ausfällt und es zu einem plötzlichen Ausfall eines Exchange Servers kommt.
Switchover testen
Nachdem die Datenbankkopien hinzugefügt wurden, kann zunächst das Verschieben einer Datenbank getestet werden (Switchover). Dazu wird im Exchange Admin Center die Kopie der Datenbank aktiviert:
Nach dem Klick auf “Aktivieren” wird eine Sicherheitsabfrage angezeigt:
Nach ein paar Sekunden ist die passive Datenbank aktiv geschaltet worden. Die vormals aktive Datenbank wird somit passiv:
Outlook im “Online Modus” zeigt in diesem Fall für etwa 1 Sekunde die Meldung “Verbindungsversuch”:
Nach ca. 1 Sekunde ist Outlook ohne Cache Modus wieder verbunden. Bei den Screenshots handelt es sich eigentlich um zwei Switchover Vorgänge, zu erkennen an der Zeit: 22:11 Uhr und 22:12 Uhr, ich war mit den Screenshots etwas zu langsam…
Wenn Outlook im Cache Modus betrieben wird, bekommt Outlook diese kurze Unterbrechung nicht mit.
Ich hab ein kleines Video erstellt, so ist der Switchover besser nachzuvollziehen:
Failover testen
Für den Failover Test habe ich den Server mit der aktiven Datenbank ausgeschaltet. Der Failover der Datenbank dauert etwas länger als der Switchover, hier muss Exchange zunächst den Ausfall eines Servers feststellen und dann die Datenbank einbinden. Outlook im Online Modus zeigt sich aber auch davon unbeeindruckt. Ich habe dazu ebenfalls ein kleines Video erstellt, so ist der Vorgang etwas besser nachzuvollziehen:
DNS Einstellungen für den Client Access Service
Eingangs hatte ich erwähnt, dass ich keinen Loadbalancer für den Client Access Service verwende, sondern das DNS benutze. Die DAG schützt nur die Datenbanken vor Ausfall, der Client Access Service muss separat betrachtet werden.
Im Normallfall würde man einen Cluster aus mindestens zwei Loadbalancern vorschalten um den Client Access Service hochverfügbar auszulegen. Hier in dieser Testumgebung funktioniert dies allerdings auch per DNS Roundrobin, das ist zwar nicht ideal und es findet keine echte Lastverteilung statt, aber für eine einfache Testumgebung reicht dies aus.
Es gibt also im DNS einfach die Einträge für Autodiscover und Outlook doppelt, jeweils mit den IPs der beiden Exchange Server:
DNS Round Robin ist im der Standardeinstellung aktiviert:
Wenn man ganz ausgefuchst ist, könnte man auch noch DNS Policies für das “Loadbalancing” benutzen:
Ich würde hier aber immer einen Loadbalancer vorziehen. Für Testumgebungen lässt sich hier ja auch eine kleine Linux VM mit beispielsweise HAProxy oder Ähnlichem nutzen.