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.

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

  1. 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. :)

  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. 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.

  4. Hallo,
    erstmal super Website. Hat mir schon oft geholfen. Eine Frage zur DAG. Ich beabsichtige mit 2 Exchange 2019 eine DAG aufzubauen. Müssen in der Grundkonfiguration beide Systeme identisch eingerichtet werden? Da auch eine Migration eines Exchange 2010 durchgeführt werden muß, macht es da Sinn erstmal die Migration durchzuführen und danach die DAG einzurichten? Anschließend den 2ten Server mit den Einstellungen (Autodiscover, Sende- Empfangsconnector etc) des ersten Servers einzubinden. Achso, gibt es eine reelle Empfehlung zum RAM ausser die 128GB von MS? Früher war es doch pro Postfach x Ram.

    Gruß, Robert

    1. Die Systeme müssen nicht unbedingt gleich sein, allerdings aber die Datenbank-Pfade im Filesystem und das Filesystem selbst sollte auch identisch sein (NTFS oder ReFS). Selbstverständlich sollte auch genügend Platz vorhanden sein, die einzelnen Kopien auf jedem Knoten zu mounten.

      Ansonsten würde ich die 2019er DAG mit den beiden von dir geplanten Knoten komplett parallel aufbauen mit allen dazugehörigen Konfigurationen (du erwähntest schon die Konnektoren etc.) und dann, wenn alles rund läuft, die Postfächer einfach in die neue DAG mirgrieren (MoveRequest). Ist alles umgezogen (Systempostfächer nicht vergessen), die alte DB und dann den alten Server abbauen.

      Die HW-Voraussetzungen seitens MS scheinen mir persönlich etwas überzogen. Hab jetzt noch keinen 2019er am Laufen, aber soooo ein großer Unterschied zum 2016er wird es auch nicht sein und die laufen hier bei mir in einer 3-Knoten-DAG mit jeweils 16MB RAM. Das kannst du ja aber testen, wenn du deine neue DAG aufbaust. Bevor du die „heißen“ Postfächer migrierst, wirst du ja sowieso erstmal mit Testusern ausprobieren.

      1. Hallo Udo,
        danke für die sehr schnelle Rückinfo. Starte mit dem Projekt Ende 10/2019. Deine Infos waren hilfreich. Ich werde es testen und eine Rückinfo hier posten.

        Gruß, Robert

        1. Hallo Robert,

          wir haben schon 2 2019er im Einsatz mit einigen Powerusern.
          Ich habe beiden Ex2019 40GB Ram „Gegönnt“ (Endausbau sind knapp 350 Postfächer, wobei 215 User + Shared).

          Bisher ist die Last fast nichts (ca. 10GB), wobei ich die Server auf Server 2019 CORE betreibe.

  5. Hallo Franky,

    Danke für das tolle Tutorial.

    Eine Frage habe ich, wie synchronisiert sich die DB01 mit der DB02.

    Weil, wenn ich get-mailbox -database DB01 ausführe bekomme ich alle aktiven Postfächer angezeigt, führe ich das mit der DB02 aus wird nicht ein User angezeigt.

  6. @Basti
    Die synchronisieren sich gar nicht, das sind ja zwei völlig verschiedene Datenbanken. In einer DAG wird von der DB01 und der DB02 in diesem Fall auf jedem DAG-Member(Server) eine Kopie gehalten, wovon jeweils eine immer die aktive ist.
    Anschauen kannst du dir das mit
    Get-MailboxDatabaseCopyStatus DB*
    Da bekommst du für beide Datenbanken (db*) alle Kopien, mit Servernamen und den Mount- und Indexstatus angezeigt. Wenn da überall „Healthy“ bzw. „Mounted“ steht, is alles fit und die Kopien sind in Ordnung.

  7. Hi Basti,
    das ist nur ein Beispiel. Es geht auch mit nur einer DB (die allerdings dann in der DAG repliziert wird, aber das sind eben die Kopien, die du mit dem o.g. Befehl einsehen kannst). In diesem Fall sind es wohl zwei, weil auf jedem Server nach der Installation eine Standard-DB vorhanden ist, die Frank in seinem Installationsbeispiel halt einfach umbenannt hat in DB01 und DB02. Genauso gut hätte er eine umbennen und eine löschen oder eine neue anlegen und die Standard-DBs im Anschluss löschen können (nach übertragen der Systemmailboxen natürlich).
    Ich glaub, du verstehst da was grundsätzlich falsch: Du kannst auf *einem* Exch-Server dutzende Datenbanken haben, die nichts miteinander zu tun haben. Dort verteilst du dann deine Nutzer. Es kann aber sehr gut auch nur eine DB sein. Hat man eine DAG eingerichtet, kann man für jede dieser DBs Kopien auf beliebige Mitgliedsserver der DAG verteilen – die sind dann synchron und bringen die Sicherheit. Mehrere DBs hat man im Fall einer DAG z.B. zu Zwecken der Lastverteilung, indem man die User dann auf die DBs aufteilt und im vorliegenden Fall z.B. auf jedem Knoten jeweils die aktive Kopie der DBs hält, so dass man eine Lastverteilung erreicht.
    Ansonsten lies dich vielleicht nochmal in das Konzept von DAGs ein, das würde hier sonst bisschen weit führen, das im einzelnen zu erklären.

    1. @Udo

      das habe ich verstanden, dachte nur das die zusätzlich synchronisiert werden aber macht ja kein Sinn, daher habe ich noch mal gefragt. Gut erklärt, Danke Dir :)

Schreibe einen Kommentar

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