Erweiterung der „kleinen Exchange Organisation“ – Teil 4

Im vierten Teil der Erweiterung der kleinen Exchange Organisation ist die DAG an der Reihe. Domain Controller und Sophos UTM laufen bereits redundant und der zweite Exchange Server ist auch vorbereitet. Damit nun auch der Ausfall eines Exchange Servers oder der Ausfall des Hyper-V / ESX Servers abgefangen werden kann, ist eine Exchange DAG (Database Availability Group) nötig.

Vorwort

Für die DAG mit zwei Exchange Servern wird zusätzlich ein weiterer Windows Server als Zeugenserver benötigt. Der Zeugenserver darf dabei nicht auf einem der beiden Hypervisor laufen, die auch die Exchange Server beherbergen. In der von mir beschriebenen Umgebung ist also ein dritter physikalischer Server (Server 3) nötig:

Der Zeugenserver wird benötigt um zu ermitteln welcher Exchange Server ausgefallen ist und welcher der verbleibende Exchange Server ist. Der Zeugenserver muss keine besonderen Hardware Anforderungen erfüllen, hier liegen später nur ein paar kleine Dateien.

Hintergrund Zeugenserver

Die DAG basiert auf dem Windows Failover Cluster Feature und der Windows Failover Cluster arbeitet nach dem „Stimmenprinzip“. Vereinfacht gesagt: Jedes Cluster Mitglied erhält eine Stimme, innerhalb des Clusters muss immer die Stimmenmehrheit gewährleistet sein, sonst wird der Betrieb eingestellt. Im Falle von zwei Exchange Servern, hat also jeder Exchange Server 1 Stimme, fällt nun einer der Exchange Server aus, fällt somit auch eine Stimme weg. Der Cluster würde seinen Betrieb einstellen, da die Mehrheit nicht mehr gegeben ist. Die eine verbleibende Stimme ist eben nicht die Mehrheit, wir bräuchten also mehr als 50% der Stimmen.

Hier kommt der Zeugenserver ist Spiel. Der Zeugenserver bekommt 0,5 Stimmen. Bei zwei Exchange Servern und einem Zeugenserver hat der gesamte Cluster also 2,5 Stimmen. Fällt ein Exchange Server aus, bleiben 1,5 Stimmen übrig. Somit ist die Mehrheit gewahrt und alles ist schön. Der Grund für die Mehrheit ist einfach, nur wenn zweifelsfrei feststeht, welcher von 2 Servern ausgefallen ist, kann auch ein Failover durchgeführt werden.

Das Horrorszenario: Irgendwo fällt ein Switch oder Uplink aus, Exchange1 kann nicht mehr mit Exchange2 kommunizieren, Exchange1 denkt er müsste die passive Datenbank online schalten, Exchange2 denkt ebenfalls er muss die passive Datenbank online schalten. Ohne einen Zeugenserver hätten wir in diesem Fall Datenbanken auf beiden Exchange Servern aktiv und unweigerlich korrupte Daten. Um dies zu vermeiden wird der Zeugenserver gefragt und die Mehrheit bestimmt.

Konfiguration des Zeugenservers

Auf dem Zeugenserver muss kaum etwas vorbereitet werden. Es reicht Server 2012 R2 zu installieren und in das Active Directory aufzunehmen. Ich habe dazu den Server fs.frankysweb.org mit der IP 172.16.100.17 installiert.

Bei der Netzwerkkonfiguration ist darauf zu achten das beide DNS Server angegeben werden:

Damit das Zeugenverzeichnis durch Exchange konfiguriert werden kann, muss noch die Gruppe „Exchange Trusted Subsystem“ zur Gruppe der lokalen Administratoren hinzugefügt werden:

Das ist schon alles, weiter geht es mit der Konfiguration der DAG.

Konfiguration Exchange DAG

Auf einem der beiden Exchange Server kann nun die DAG konfiguriert werden

Nachdem die DAG angelegt wurde, können die beiden Exchange Server hinzugefügt werden:

Nach kurzer Zeit wurden die Server hinzugefügt und der Dialog kann geschlossen werden.

Im EAC sollte es nun wie folgt aussehen:

Eine DAG mit dem Namen „FWDAG1“. Die Server mit dem Namen „Exchange“ und „Exchange2“ sind Mitglieder, Zeugenserver ist „FS“.

Konfiguration Datenbankkopien

Für die beiden Datenbanken muss jetzt jeweils eine Kopie auf dem anderen Exchange Server hinzugefügt werden:

Für die Datenbank „MailboxDB“ wird also eine Kopie auf „Exchange2“ konfiguriert:

Für die zweite Datenbank wird ebenfalls eine Kopie auf dem Server „Exchange“ hinzugefügt:

Nachdem die Kopien hinzugefügt wurden, sollte es in etwa so aussehen:

Nachdem die Kopien hinzugefügt wurden, kann der Status überprüft werden.

Überprüfung

Bevor ein Ausfall getestet werden kann, sollte überprüft werden, ob die die Postfachkopien und der Index in Ordnung ist:

Get-MailboxDatabaseCopyStatus -Server exchange
Get-MailboxDatabaseCopyStatus -Server exchange2

• Bei mir war ein Index beschädigt. Ich habe den Index neu erstellt:

Exchange Index neu erstellen

Mittels des folgenden Befehls, kann der Index dann an den zweiten Server übertragen werden (falls auf beiden Servern der Index defekt sein sollte)

Update-MailboxDatabaseCopy MailboxDB\EXCHANGE2 -CatalogOnly

Der Ausfall

Der wichtigste Test ist natürlich der Ausfall eines kompletten Servers. In diesem Fall sind zeitgleich ein Domain Controller, ein Exchange Server und eine Sophos UTM nicht mehr verfügbar. Ich teste den Ausfall von Server1:

Auf Server1 befindet sich die aktive Sophos UTM, ein Domain Controller und der Exchange Server mit der aktiven Datenbank „MailboxDB“ in der das Administrator Postfach gespeichert ist. In meinem Fall passiert also ein Failover des UTM Clusters und ein Failover der Postfachdatenbank „MailboxDB“. Zur Erinnerung, ein Loadbalancer für Exchange wird nicht eingesetzt. Das Ergebnis könnt ihr euch im Video anschauen:

Oben rechts läuft ein Ping gegen den Domain Controller „DC“, in der Mitte ein Ping zum Exchange Server. Oben links läuft ein Ping zu meinem Blog und unten links der Ping zur UTM. Beim Ausfall von Server1 übernimmt die passive UTM nach kurzer Zeit, hier geht nur ein Ping verloren. Exchange Server und Domain Controller bleiben offline, Outlook bekommt von all dem nichts mit. Das Failover auf Exchange2 war erfolgreich:

Fazit

An dieser Stelle gibt es kein kleines Fazit. Es gibt noch einen ausführlicheren Artikel zu Pro und Kontra und zu den ungelösten Problemen.