In diesem Beitrag möchte ich die verschiedenen Aspekte der Auto Reseed Funktion von Exchange 2013 / 2016 beleuchten und erklären in welchen Szenarien diese Funktion eine sinnvolle Ergänzung der Exchange Architektur darstellt.

Microsoft hat eine sehr detaillierte bevorzugte Architektur für Exchange veröffentlicht (https://blogs.technet.microsoft.com/exchange/2015/10/12/the-exchange-2016-preferred-architecture/). Bezüglich des Exchange Server Designs lautet die generelle Message der Preferred Architecture wie folgt:

  • Das Exchange Server Design sollte so einfach wie möglich gehalten werden.
  • Die vorhandenen Hardware Ressourcen sollten möglichst optimal ausgenutzt werden.
  • Durch das Design sollte die Last möglichst gleichmäßig verteilt werden.

Im Wesentlichen bedeutet das bezogen auf unser Thema:

  • Exchange Server auf Hardware Servern zu betreiben, anstatt zu virtualisieren.
  • Als Storage für die Exchange Daten JBOD (Just a Bunch Of Disks) Festplatten zu verwenden, anstatt von RAID oder Storage Systemen. Geeignet sind kapazitätsmäßig große Festplatten aus dem preislich günstigen Segment wie z. B. SATA Festplatten.
  • Mehrere Datenbanken je Festplatte zu konfigurieren, um die Speicherkapazität der Festplatten möglichst optimal auszunutzen. (Wichtig! Die empfohlene max. Größe der Postfachdatenbanken ist nach wie vor 2 TByte).

Grundsätzlich ist es bei einem solchen Design so, dass beim Ausfall einer Disk die DAG (Database Availability Group) Mechanismen aktiviert werden. Dadurch werden die Postfach-Datenbanken, die auf der ausgefallenen Disk gespeichert sind / waren, von einem anderen Exchange Server in der DAG übernommen und bereitgestellt. Die Bereitstellung des Dienstes ist somit durch den DAG Cluster gewährleistet. Jedoch ist der Level der Hochverfügbarkeit beeinträchtigt. So z. B. kann bei einem zwei Knoten DAG Cluster der Ausfall einer Disk durch das Verschieben der aktiven Datenbanken auf den zweiten DAG Server kompensiert werden. Jedoch darf in diesem Szenario keine weitere Disk ausfallen, die dieselben Datenbanken hostet.

Der Administrator muss in einem solchen Fall die defekte Festplatte ersetzen, ein neues Volume im Betriebssystem bereitstellen und ein Reseed der Datenbanken auf das Volume manuell starten.

Im Vergleich zu den klassischen RAID oder Storage Systemen hat an der Stelle das JBOD System einen erheblichen Nachteil. Fällt in einem RAID System eine Disk aus, so wird der Ausfall durch die RAID Redundanzen kompensiert. Der Ausfall hat zunächst keine Auswirkung auf die Verfügbarkeit der Exchange Daten. Der Administrator ersetzt die ausgefallene Festplatte durch eine neue und abhängig vom Controller wird das RAID automatisch oder manuell wiederhergestellt.

Genau an der Stelle setzt die Auto Reseed Funktion an. Ganz allgemein gesagt wird mit der Auto Reseed Funktion die Funktionalität des RAID Controllers auf die Applikationsebene des Exchange Servers verschoben. Der Exchange Server überwacht periodisch den Zustand der Datenbanken. Fällt eine oder mehrere Datenbanken auf einem Server aus, so greifen zunächst die DAG Mechanismen und verschieben die ausgefallenen Datenbanken auf einen anderen Server in der DAG. Sollten die ausgefallenen Datenbanken nach einer Reihe von Prüfungen nicht in einen ‚Healthy‘ Status versetzt werden können (z. B. durch den Ausfall einer Disk), so identifiziert die Auto Reseed Funktion die ausgefallene Disk, stellt eine vordefinierte Spare-Disk an Stelle der ausgefallenen Disk bereit und initiiert den Reseed Prozess der ausgefallenen Datenbanken automatisch. Nach dem der Reseed Prozess der Datenbanken abgeschlossen ist, ist auch der Verfügbarkeits-Level der Datenbanken automatisch wiederherstellt. Der Administrator muss nun die ausgefallene Disk ersetzen, entsprechend formatieren und kann die neue Disk wieder als Spare-Disk definieren.

Die Implementierung der Auto Reseed Funktion in Exchange basiert auf der Fähigkeit des Windows Systems, ein und dasselbe Daten-Volumen gleichzeitig in mehreren Mountpoints in Filesystem bereitzustellen. Die Auto Reseed Funktion ist somit auch nur mit Daten-Volumes, die als Mountpoints bereitgestellt sind möglich (nicht mit Laufwerksbuchstaben).

Zunächst werden zwei Mountpoint-Bereiche (Root Verzeichnisse) definiert:

  • In einem Bereich werden nur solche Volumes gemounted, auf denen die Postfach-Datenbanken gespeichert sind;
  • Im zweiten Bereich werden alle Volumes inkl. der Spare-Disks gemouted.

Das Delta zwischen dem ersten Mountpoint-Bereich und dem zweiten Mountpoint-Bereich betrachtet Exchange als Spare-Disks. Es können so auch mehrere Spare-Disks definiert werden.

Hier ein einfaches Beispiel:

  • Vier Datenbanken: DB01-DB04
  • Zwei Disks: Disk1 und Disk2. Auf Disk1 sind DB01 und DB02 gespeichert. Auf Disk2 sind DB03 und DB04 gespeichert.
  • Eine Spare-Disk: Disk3
  • Mountpoint-Bereich für Datenbanken: C:\EXDB
  • Mountpoint-Bereich für Volumes: C:\EXVOL

In diesem Beispiel werden die Disks Disk1 / Disk2 in jeweils drei Mountpoints bereitgestellt:

  1. C:\EXDB\DB01 -> Disk1 für die Datenbank DB01
    C:\EXDB\DB02 -> Disk1 für die Datenbank DB02
  2. C:\EXDB\DB03 -> Disk2 für die Datenbank DB03
    C:\EXDB\DB04 -> Disk2 für die Datenbank DB04
  3. C:\EXVOL\Vol1 -> Disk1 im Volume-Bereich
    C:\EXVOL\Vol2 -> Disk2 im Volume-Bereich

Die Spare Disk3 wird jedoch nur im Mountpoint-Bereich für Volumes bereitgestellt:

  1. C:\EXVOL\Vol3 -> Disk3

Zu beachten ist, dass Microsoft bei der Auto Reseed Funktion eine feste Verzeichnisstruktur vorschreibt:

  • Die Namen der Mountpoints für die Datenbanken müssen den Datenbanknamen entsprechen DB01 -> C:\EXDB\DB01
  • Die Verzeichnisse für Datenbanken bzw. Transaktionsprotokolle:
    • Datenbank Verzeichnis <DBName>.db
      z. B. C:\EXDB\DB01\DB01.db
    • LOG Verzeichnis <DBName>.log
      z. B. C:\EXDB\DB01\DB01.log

In Exchange wird die Auto Reseed Funktion als DAG Parameter konfiguriert:

  • AutoDagVolumesRootFolderPath – definiert das Verzeichnis, in dem alle Volumes incl. der Spare-Disk gemountet werden.
  • AutoDagDatabasesRootFolderPath – definiert das Verzeichnis, in dem Datenbanken gemountet werden.
  • AutoDagDatabaseCopiesPerVolume – definiert die Anzahl der Datenbanken pro Volume. Es ist wichtig, dass immer die gleiche Anzahl an Datenbanken pro Volume konfiguriert wird.

Bei der Implementierung von Auto Reseed sind folgende Punkte zu beachten:

  • Die Mountpoints sollten auf einem Volume implementiert werden, das durch ein RAID abgesichert ist. Nach Preferred Architecture sollte das Betriebssystem des Exchange Servers auf einem RAID1 System installiert werden. Das System Volume C: kann in diesem Fall auch für die Mountpoints verwendet werden. Dadurch wird sichergestellt, dass bei Ausfall einer Disk alle Mountpoints und somit alle Datenbanken eines Servers verlorengehen.
  • Backup: Bei der Konfiguration des Backup Programms sollten die unterschiedlichen Zyklen für die Sicherung des Exchange Server OS und der Exchange Daten beachtet werden. Z. B. sollten bei der Sicherung der Disk C: evtl. eine Ausnahme für die Root Verzeichnisse der Mountpoints konfiguriert werden.
  • Bei mehreren Datenbanken je Volume kommt es schnell zu sehr vielen Mountpoints, und damit wird die initiale Konfiguration etwas aufwändiger. Jedoch kann der Exchange Storage Requirements Calculator an der Stelle Abhilfe schaffen, entsprechende Scripte können aus dem Calculator generiert werden.
  • Bitlocker: Es gibt mehrere Möglichkeiten, Bitlocker auf den Datenbank Volumes zu aktivieren. Diese können auch in Verbindung mit Auto Reseed implementiert werden. Ggf. sind zusätzliche manuelle administrativen Tätigkeiten bei bereitstellen der Volumes oder der Spare Disks erforderlich.
  • Wer über den Einsatz der Auto Reseed Funktion nachdenkt, sollte von vornherein das Exchange Server Design entsprechend ausrichten. Ein späteres Re-Design kann sehr zeit- und arbeitsintensiv werden.
  • Auch mit Auto Reseed ist ein gutes Monitoring der Exchange Server unabdingbar – der Administrator muss merken, dass eine Disk defekt ist.

Zusammenfassung:

Wann macht Auto Reseed Sinn?

  • Hauptsächlich bei JBOD Implementierungen.

Wann macht Auto Reseed weniger Sinn?

  • Wenn Datenbanken auf Raid Systemen gespeichert sind.
  • Wenn Datenbanken auf Storage Systemen gespeichert sind.
  • Bei Virtualisierten Exchange Servern (entspricht in der Regel der Variante DBs auf Storage System).

Vorteile gegenüber RAID / Storage:

  • Deutlich günstigerer Datenspeicher
  • Einfachere Architektur
  • Dadurch vereinfachter Betrieb
  • Bei gutem Design meistens weniger „Verschnitt“ vom Datenspeicher
  • Weniger Abhängigkeiten zu anderen Systemen / Teams / Wartungsplänen / etc. (z. B. Storage)

Nachteile gegenüber RAID / Storage:

  • Beim Ausfall einer Disk erfolgt ein Datenbank Failover. Demzufolge hat der Ausfall einer Disk eine Auswirkung auf die Endbenutzer, auch wenn dieser meist unbemerkt bleibt, weil er sehr kurz ist.
  • Während der Reseed Zeit ist der Verfügbarkeits-Level der Datenbanken beeinträchtigt.
  • Ggf. etwas mehr administrativen Aufwand beim Ersetzen der ausgefallenen Disk.

Die Auto Reseed Funktion ist eine gute und sinnvolle Ergänzung der Exchange DAG in einigen Szenarien. Wie immer ist eine sorgfältige Planung, sowie die Betrachtung der Vor- und Nachteile in jedem konkreten Fall notwendig für ein gutes Gelingen der Implementierung.