AutoReseed in Exchange 2013

Einige Neuerungen in Exchange 2013 erscheinen auf den ersten Blick simpel. Bei der Konfiguration stellt sich dann aber heraus, dass dem nicht ganz so ist. So auch bei «AutoReseed». Auch nach langer Suche konnte ich keinen Artikel oder Blogpost finden, der die Schritte und die Konfiguration brauchbar erklärt. Auch die Abhandlung in Technet liess bei mir mehr Fragen offen, als sie beantwortete. Deshalb heisst es nun: Selbst ist der Mann. Ich hab das Feature für Sie konfiguriert und getestet.

Schauen wir uns zuerst an, was es in der Theorie macht und in welchem Szenario es eingesetzt werden kann.

Wenn eine Disk oder LUN ausfällt, auf der eine Exchange-Datenbank liegt, wird dies durch die Database Availability Group abgefangen. Das heisst, es wird automatisch eine passive Kopie der Datenbank auf einem anderen Mailbox Server aktiviert. Sollte ich noch mehr passive Kopien haben, bleibt auch die Ausfallsicherheit bestehen. Oft sind aber nur zwei Kopien konfiguriert (weil die Datenbanken auf dem teuren SAN liegen). Und hier geraten wir in eine kritische Situation: Ein weiterer Ausfall, der die Datenbank oder den Server betrifft, auf dem die DB gehostet ist, führt mit hoher Wahrscheinlichkeit zu einem Datenverlust. Der Admin muss also die ausgefallene Disk/LUN so schnell wie möglich wieder reparieren und die Datenbank auf die Ersatzdisk replizieren.

Genau dieser Vorgang wird durch das AutoReseed Feature erledigt. Dies ist eigentlich nur bei JBOD-Implementationen sinnvoll (also kein RAID – dort würde die Disk weiter funktionsfähig bleiben, selbst wenn eine Spindel ausfällt). Das Feature macht sich die Möglichkeit zunutze, mehrere Mountpoints pro Volume erstellen zu können.

Wie wird das AutoReseed Feature konfiguriert?

1. Geben Sie dem Exchange Server die Ordner für die Mountpoints an. Wird dies nicht gemacht, verwendet der Server die beiden Defaults: c:\ExchangeVolumes und c:\ExchangeDatabases. Die zugehörigen Ordner müssen in jedem Fall erstellt werden.

Die Pfade sind in der Exchange Management Shell mit dem Befehl

get-DatabaseAvailabilityGroup | fl

ersichtlich.

2. Über den Parameter «AutoDagDatabaseCopiesPerVolume» müssen die Anzahl Datenbanken pro Volume konfiguriert werden. Der Default-Wert ist 4. In meinem Beispiel musste ich ihn auf 2 anpassen, wie im obenstehenden Screenshot ersichtlich ist.

3. In den erstellten Ordnern bilde ich jetzt eine Ordnerstruktur der Datenbanken ab.

4. In die Folder werden die Volumes gemountet.

Hier für das aktive Volume:

Und hier für den Spare:

Das Spare Volume muss NTFS-formatiert sein (64KB Cluster Size nicht vergessen) und sollte keine Ordnerstruktur aufweisen (dies würde zu Problemen führen, da der AutoReseed Manager versucht, diese Struktur im Schadenfall zu erstellen).

5. Innerhalb der DB Folder wird eine Struktur für DB und Logfiles erstellt:

Darin werden die DB und Logs angelegt oder hinein verschoben. Dann wird auf den zweiten DAG Memberserver mit einer identischen Konfiguration die passive Kopie der Datenbank angelegt.

Was geschieht nun bei einem Ausfall der Disk?

1. Disk offline

2. Der AutoReseed Manager erkennt das und ändert den/die Mountpoints für die DBs auf das 2 Volume, erstellt wieder eine Kopie der DBs und startet den Seeding-Prozess:

3. Der Admin muss nur noch die physische Disk ersetzen, im Disk Management einbinden und formatieren. Dann steht wieder ein Spare zur Verfügung.

Je mehr DBs auf derselben Disk konfiguriert sind, desto schneller geht der Reseed-Prozess, da dieser von der Source limitiert ist. Bei mehreren Datenbanken wird von mehreren Sources gleichzeitig ein Seeding gemacht. Darum und weil Disks in den letzten Monaten an Kapazität gewonnen haben, lohnt sich diese Art von Konsolidierung.