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.
Kann man mehrere ip less DAGs haben? z.B. migrations zwecke eine für 2016 und eine weiter mit 2019 ertellen? Oder wird die esrte automtisch übnerschrieben da 255.255.255.255 schon besteht?
Hallo Zusammen,
ich scheitere an der DB Kopie auf dem zweiten Server
Fehler der speicherort für logfolderpath befindet sich nicht auf einem festplattenlaufwerk.
Server 1 2 Platten , C und D (alles Exchange ist auf D)
Server 2 1 Platte alles auf c….
muss Server im Plattenlayout exakt gleich sein?
Hallo Holger,
die Pfade und Laufwerksbuchstaben müssen gleich sein.
Beste Grüße,
Frank
nein, kannst du natürlich in einer Powershell machen. Die Move-Requests werden nach und nach im Hintergrund abgearbeitet. Den Stand kann man sich jederzeit ansehen. Du kannst alle auf einmal losschicken, oder auch einzeln (sinnvoll sicher erstmal für die ersten Testaccounts) oder auch datenbankweise, ganz nach deinem Geschmack.
Die Nutzer merken davon normalerweise auch nichts, wenn sonst alles richtig eingerichtet ist. Zumindest war es bei mir von 2013 nach 2016 so, aber ich wüsste jetzt auch keinen Grund, warum das nach 2019 anders sein sollte.
Hallo zusammen,
mir ist das grundsätzliche Verfahren noch nicht ganz klar, deshalb frage ich lieber nach und bin für jeden Input dankbar: ich habe eine Exchange 2016 DAG mit vier Servern und mehrere Datenbanken mit Kopien auf allen vier Servern. Wenn ich die neuen Exchange 2019 Server nicht in die bestehende DAG aufnehmen kann, sondern eine neue erstellen muß, wie bekomme ich dann die Datenbanken von der alten in die neue DAG? Der normale Weg über „neue Datenbankkopie erstellen“ geht ja in dieser Konstellation nicht.
Viele Grüße,
Michael
gar nicht. du legst neue DBs in der neuen DAG an und schiebst alle Mailkonten (einschließlich der Systemmailboxen) in dies(e) neue(n) DB. Die alten haust du dann weg, wenn mit den neuen alles funktioniert.
Danke für die schnelle Antwort. Wenn ich das richtig verstehe, geht es also nur über Move-Requests. Ich habe 25 Datenbanken mit je um die 300 Nutzer. Kann ich da die Nutzer einer DB per Powershell moven oder wird das zu viel und ich muß es irgendwie „quanteln“?
Viele Grüße,
Michael
Moin Moin,
hat wer Erfahrungen mit DAG´s an geografisch unterschiedlichen Lokationen?
Bsp.:
Site A:
DAG-Node A
DAG-Node B
Loadbalancer für NodeA und NodeB;
DNS Name ist exchange.Meinedomain.local im Loadbalancer hinterlegt
Site B
DAG-Node C
DNS Name ist exchange.Meinedomain.local
Wenn nun ein Client aus SiteB sich mit der DAG verbindet gelangt sein Packet zwangsweise beim Loadbalancer; doch was passiert dann?
Über welchen Server versendet der Client seine Mails?
Achtung Fallstrick: Bei einer Migration EX2013 -> EX2019 mit Einrichtung einer DAG2019 „bevor“ die Postfächer migriert wurden, trifft man auf das Problem, dass man keine Datenbank Kopien erstellen kann.
Lösung: Man muss zuerst ein Postfach eines Benutzers mit entsprechenden Rechten auf einer DB2019 einrichten oder migrieren und sich mit diesem Benutzer an der EAC anmelden.
Hat ne Weile gedauert, bis ich auf die Lösung gestoßen bin…
VG Bernie
Hallo zusammen, ich schließe nicht aus, dass ich zu doof dafür bin :D aber ich habe noch meine Testumgebung für die Migration übrig gehabt. Jetzt wo auch das Echtsystem fertig ist, wollte ich mir das DAG einmal anschauen.
Ich hab in meiner Testumgebung einen Exchange 2019 als Core gehabt. Ich habe einfach einen zweiten Server 2019 mit Exchange 2019 installiert (hier konnte ich keine Organisation mehr auswählen, da ja schon in der Domäne vorhanden). Links identisch gesetzt… Connectoren identisch… (beideseitig eingetragen wie bei der Migration, sofern überhaupt nötig?!).
Jeder Server hat seine eigene DB (Namen sind NICHT identisch).
DAG aufgebaut nach der Anleitung und bei dem Punkt „Datenbankkopie erstellen“ stopt alles mit dem Hinweis, dass schon Logs vorhanden wären mit gleichem Namen. Äh?! Wie kann das sein, ab welchem Punkt habe ich hier einen Fehler gemacht?
Gruß Mike
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.
@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 :)
@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.
@Udo
Danke für die Antwort aber ich verstehe dann nicht wozu 2 DB´s benötigt werden wenn diese sich nicht synchronisieren?
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.
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
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.
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
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.
Microsoft empfiehlt in seinem PA aber (ich meine schon ab Version 2016) keine Loadbalancer mehr zu verwenden sondern generell DNS Round Robin einzusetzen…?
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.
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.
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.
Hallo Michael,
es ist nicht supported innerhalb einer DAG unterschiedliche Exchange Versionen einzusetzen:
All servers within a DAG must be running the same version of Exchange. You can’t mix Exchange 2013 servers and Exchange servers in the same DAG.
https://docs.microsoft.com/en-us/Exchange/high-availability/manage-ha/create-dags?view=exchserver-2019
Der Weg wie von Udo beschrieben ist hier die richtige Vorgehensweise.
Gruß,
Frank
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?
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
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. :)