Exchange 2019: Database Availability Group (DAG)

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.

Exchange 2019: Database Availability Group (DAG)

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:

Exchange 2019: Database Availability Group (DAG)

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:

Exchange 2019: Database Availability Group (DAG)

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:

Exchange 2019: Database Availability Group (DAG)

Nachdem die DAG erstellt wurde, können die Mitgliedserver hinzugefügt werden:

Exchange 2019: Database Availability Group (DAG)

In diesem Fall müssen nun beide Exchange Server als Mitglieder der DAG angegeben werden:

Exchange 2019: Database Availability Group (DAG)

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.

Exchange 2019: Database Availability Group (DAG)

Exchange 2019: Database Availability Group (DAG)

Nach ein paar Minuten sind die beiden Server als Mitglieder der neuen DAG konfiguriert:Exchange 2019: Database Availability Group (DAG)

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:

Exchange 2019: Database Availability Group (DAG)

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:

Exchange 2019: Database Availability Group (DAG)

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:

Exchange 2019: Database Availability Group (DAG)

Hier kann nun der Exchange Server für die Kopie angegeben werden:

Exchange 2019: Database Availability Group (DAG)

Die Datenbank und die Logfiles werden nun auf den Server für die Kopie übertragen:

Exchange 2019: Database Availability Group (DAG)

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:

Exchange 2019: Database Availability Group (DAG)

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:

Exchange 2019: Database Availability Group (DAG)

Nach dem Klick auf “Aktivieren” wird eine Sicherheitsabfrage angezeigt:

Exchange 2019: Database Availability Group (DAG)

Nach ein paar Sekunden ist die passive Datenbank aktiv geschaltet worden. Die vormals aktive Datenbank wird somit passiv:

Exchange 2019: Database Availability Group (DAG)

Outlook im “Online Modus” zeigt in diesem Fall für etwa 1 Sekunde die Meldung “Verbindungsversuch”:

Exchange 2019: Database Availability Group (DAG)

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…

Exchange 2019: Database Availability Group (DAG)

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 Einstellungen für den Client Access Service

DNS Round Robin ist im der Standardeinstellung aktiviert:

DNS Einstellungen für den Client Access Service

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.

8 Kommentare zu “Exchange 2019: Database Availability Group (DAG)”

  1. Microsoft empfiehlt in seinem PA aber (ich meine schon ab Version 2016) keine Loadbalancer mehr zu verwenden sondern generell DNS Round Robin einzusetzen…?

    1. Würde ich nie machen. Der Vorteil eines Loadbalancers ist ja auch die aktive Prüfung der Verfügbarkeit, Stuerung der Lastverteilung Vorfilterung der Zugriffe und vieles mehr. Bei stumpfem RR hast du ja z.B. bei Ausfall eines Knotens im Zeifel auch immer einen Fehlzugriff, wenn du vom DNS eben gerade diese Adresse geroundrobint bekommen hast. Von den fehlenden anderen Möglichkeiten mal ganz abgesehen.

      Gibt MS in deiner Quelle auch einen Grund für RR und den Verzicht auf Loadbalancer an? Wäre mal interessant, vielleicht übersehe ich ja auch was.

  2. Hi Chris,
    man kann in DAGs nicht verschiedene Serverversionen mischen. Ging aber auch noch nie. Wenn du eine 2016er DAG hast, kann du parallel eine 2019er aufbauen, dann die Postfächer alle nach und nach rüber moven (Systempostfächer nicht vergessen) und dann die 2016er DAG abbauen, wenn sie leer ist.

    1. Hi Udo,

      das stimmt nicht seit 2013 gibt es die Möglichkeit das DAG auch über Exchange-Versionen hinweg zu „migieren“. Das haben wir bei uns aktuell mit der Migration von 2016 auf 2019 gemacht, einfach die Exchange 2019 Server in das DAG hinzufügen und dann mittels add-mailboxdatabasecopy die Kopien auf die neuen Exchange-Server bereitstellen.
      Danach einfach die alten Kopien entfernen und die Exchange 2013/2016 Installation deinstallieren. Wichtig via ADSI-Edit nachschauen ob die Server sauber entfernt wurden, wird scheinbar bei SplitPermission installationen nicht gemacht.

  3. super Bericht, wie immer auch optisch perfekt aufbereitet.
    was ich noch in diesem Bericht vermisse ist die Mischform (also nicht auf grüner Wiese) sondern in bestehenden Umgebungen. Wie sieht es aus wenn man bereits zwei Exchange 2016 mit einer DAG hat? Da die 2019er Datenbanken auch den Index beinhalten wird man vermutlich nicht die bestehende DAG verwenden können – oder? Sollte man dann am besten eine neue DAG anlegen oder die bestehende auflösen. Welche IP? 255.255.255.255 ist ja bereits reserviert wenn die bestehende bleibt?

    1. Es gibt keine DAGs die verschiedene Exchange Versionen beinhalten. Du installierst eine neue, wie oben beschrieben, und verschiebst die Postfächer.

      Was ist mit IP gemeint? DAGs sollten seit 2013SP1 immer IP-less installiert werden.
      New-DatabaseAvailabilityGroup -Name DAG01 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress]::None) -WitnessServer WitnessServerName

      Ralf

      1. ist hier nicht direkt on-topic aber da du es erwähnst: man *kann* ja trotzdem immernoch eine IP zuweisen, es geht aber seit 2016 (glaube ich), auch ohne. *Sollte* man wirklich IP-less installieren, also ist das best practise und was ist der Vorteil daran?
        …hatte ich mich auch schon gefragt. :)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.