Exchange-DAG aufbauen mit Standard oder Enterprise Edition

Aus technischer Sicht ist es durchaus machbar, auf der Basis von Exchange 2010 Standard  Edition eine DAG (Database Availability Group) zu erstellen und somit eine günstige Hochverfügbarkeit für Postfächer-Server sicherzustellen. Doch dieser Ansatz eignet sich nicht für alle Anforderungen, wie unser Exchange-Spezialist Tony Redmond erläutert.

Der Aufbau einer DAG (Database Availability Group) mit der Standard-Edition des Exchange Server 2010 ist machbar, denn Microsoft setzt nicht voraus, dass man die Enterprise-Edition von Exchange dazu verwendet. Mit einer DAG lassen sich ausfallsichere Exchange-Umgebungen aufbauen. Ob das Einschlagen dieses Wegs allerdings in jedem Fall eine weise Entscheidung ist, scheint doch sehr fraglich. Auf alle Fälle ist der Einsatz des Windows Failover Clusterings als eine notwendige Voraussetzung zu nennen – dazu benötigt man zumindest die Enterprise-Edition des Windows Server 2008 Release 2.

Sicher müssen die meisten Unternehmen heutzutage genau aufpassen, welche Summen sie für die IT-Ausrüstung ausgeben. Wo immer man einsparen kann, sollte man das auch tun – so lautet die landläufige Meinung. Eine DAG auf der Basis der Standard-Edition des Exchange Server 2010 unterstützt fünf gemountete Datenbanken auf jedem Server (dazu zählen die Postfach-Datenbanken sowie die für die öffentlichen Ordner). Dagegen liegt bei der Enterprise-Edition von Exchange 2010 der Grenzwert für die Anzahl der Datenbanken pro Server bei 100.

Angenommen man verwendet eine genügende Anzahl von DAG-Mitgliedern, um drei Kopien für jede Datenbank vorzuhalten (zwei Kopien bieten eine vernünftige Hochverfügbarkeit und eine dritte Kopie macht einfach nur ein besseres Gefühl), dann erscheint es vernünftig, sich die höheren Lizenzkosten für die Enterprise Edition von Exchange 2010 zu sparen und folgerichtig auf die Standard Edition zu setzen. Doch nicht in jedem Fall wird sich das als sinnvoll erweisen.

Kleine DAG mit drei Postfach-Servern

Eine kleine DAG – etwa mit drei Postfach-Servern – kann bestimmt eine gute Redundanz zu sehr günstigen Kosten bieten, vor allem wenn man dazu noch kostengünstigen JBOD-Speicher (Just a Bunch of Disks) verwendet. Doch wenn man dann überlegt, warum man eine DAG einsetzen will, kommt man schnell und einfach auf das Argument: hochverfügbare Postfächer sind das finale Ziel.

Wer hier zustimmt, der muss dann auch für diese Software eine qualitative hochwertige Umgebung bereitstellen. Dazu gehören Aspekte wie mehrere Netzwerk-Interface-Karten für die Server, intelligente Storage Controller, Festplatten mit einer hohen MTBF (Mean Time Between Failure) aber auch eine vernünftige Server-Hardware, die nicht unbedingt selbst aufgebaut sein sollte. Sprich man wird sich auf viele Arten gegen den Ausfall der Hardware absichern.

Treibt man dieses Konzept weiter, kommt man auch auf die Frage, ob es nicht doch besser sei, wenn man mehr als nur fünf gemountete Datenbanken auf einem Server betreiben kann.

Mehr Flexibilität durch die Enterprise-Edition

Zu den Grundüberlegungen eines sinnvollen DAG-Entwurfs zählt auch, dass man möglichst viel Flexibilität haben sollte. Daher empfiehlt sich auch der Einsatz von größeren DAGs – mit bis zu 16 Mitgliedern, die bei Exchange 2010 maximal unterstützt werden. Das hat viele Vorteile gegenüber einer kleineren DAG – vor allem eine höhere Ausfallsicherheit.

Kann man mehr Datenbanken auf einem DAG-Mitglied mounten, bedeutet das, dass die Datenbanken selbst kleiner sein können. Auch das führt zu großen Vorteilen – verglichen mit dem Handling von extreme großen Datenbanken. Die vom Administrator angestoßenen Umschaltvorgänge sind schneller, auch das Beheben von Fehlern in der Datenbank läuft schneller ab – ebenso die Reseed-Vorgänge. Des Weiteren ist das Sichern von kleinen Datenbanken schneller erledigt – ebenso deren Wiederherstellung.

Auch das Thema “Erweiterung” lässt sich eleganter angehen, wenn man mehr als nur fünf Datenbanken gleichzeitig mounten kann. Sieht man von den höheren Lizenzkosten ab, sprich eigentlich alles für den Einsatz der Enterprise Edition von Exchange, wenn man DAG einsetzen möchte.

Kostenvorteile sprechen für die DAG mit der Standard-Edition

Allerdings gibt es auch Szenarien, die mit der günstigeren Variante gut bedient sind. Angenommen man möchte einen einzelnen Server in einer DAG haben, auf dem die Standard Edition von Exchange läuft, und der niemals aktive Datenbanken beherbergen soll. Denn dieser Server soll nur passive Kopien von Datenbanken enthalten, in denen die Postfächer von “sehr wichtigen Personen im Unternehmen” – wie den Vorständen oder Geschäftsführern – liegen.

Bei einer derartigen Anforderung existieren Kopien dieser Datenbanken innerhalb der DAG und die lassen sich im Falle eines Falles auch schnell aktivieren. Dabei bekommt der komplette Postfachserver die Aktivierungsrichtlinie „Blocked“ verpasst – etwa mit dem Powershell-Cmdlet Set-MailboxServer. Dadurch wird es der „Active Manager“ erst gar  nicht ersuchen, den Server mit den Datenbank-Kopien online zu bringen. Die grundlegende Idee dahinter lautet: Es wird eine zusätzliche Kopie von bis zu fünf Datenbanken angelegt, die besonders kritische Postfächer enthalten. Diese Kopien lassen sich dann über einen händischen Eingriff eines Administrators online bringen – falls etwas wirklich Schlimmes passiert.

Ein derartiges Konzept könnte sich in einigen wenigen Fällen als sinnvoll erweisen –doch in der Regel wird man es vorziehen, die Enterprise-Edition von Exchange Server 2010 einzusetzen. Denn eine derartige Vorgehensweise hat zur Folge, dass der Server mit Exchange 2010 Enterprise Edition zu einem vollwertigen Mitglied in der DAG wird.

Interessanter wäre dagegen das folgende Szenario: Man könnte in einer DAG einen Exchange Server 2010 Standard einsetzen, der nur die Archiv-Postfächer beherbergt. Denn bei Exchange 2010 ist es möglich, das primäre Postfach von seinem Archiv zu trennen. Doch in den meisten Fällen werden sich die Administratoren glücklich schätzen, wenn sie die beiden Postfächer (das aktive und das Archiv) in nur einer Datenbank abgelegt haben. Denn das erweist sich in der Verwaltung und dem Betrieb in aller Regel als einfacher – und das ist dann auch meistens besser.

Nicht alles auf eine Karte setzen

Doch andererseits gibt es auch die Regel, nicht alles auf eine Karte – in diesem Fall auf einen Server – zu setzen. Da ist dann die Trennung von Archiv und aktiven Postfach wieder besser. Zudem könnte man beim Design der Server-Hardware auf die geringeren Anforderungen beim Archivsystem zurückgreifen und dazu auch wieder die Standard-Edition des Exchange Server 2010 nehmen.

Das wäre dann ein passender Sonderfall – aber auch hier erscheint die Variante mit der Enterprise-Edition eines Exchange Server 2010 als verlockend: Wenn alle Server in der DAG die identische Hardware und dieselbe Software einsetzen, kann man eine einfachere Lastverteilung zwischen diesen Systemen erreichen. Und diese Art des Betriebs entspricht auf dem eigentlichen Designkonzept der DAGs.

Ein jedes Unternehmen wird unterschiedliche Anforderungen stellen und daher können die Argumente und ihre Gewichtung auch zu anderen Ergebnissen führen. Daher können diese Ausführungen auch nur in eine allgemeine Empfehlung münden – etwa genauso wie die Frage, ob ein Postfach-Server als physisches System oder in einer virtuellen Maschine laufen soll (hier lautet die Antwort des Autors: immer als physisches System).

Ein weiterer Diskussionspunkt zum Thema DAG ist die aktuelle Beschränkung auf maximal 16 Mitglieder in der DAG. Das wird bei Exchange 2013 künftig nur wenig Freude machen. Denn Exchange Server 2013 wird Windows Server 2012 unterstützen – und ab diesem Betriebssystem liegt die Obergrenze  für Knoten in einem Cluster bei 64. Doch das wird – nach heutigem Informationsstand – der Exchange Server 2013 nicht ausnutzen.

Denn diese kommende Exchange-Version wird auch auf Windows Server 2008 Release 2 mit Servicepack 1 unterstützt. Da liegen die Grenzen beim Cluster nach wie vor bei 16 Knoten. Und Microsoft möchte es unbedingt vermeiden, dass man die Grenzen für die DAG abhängig vom darunter liegenden Betriebssystem macht.

Denn was wäre, wenn man eine gemischte Umgebung – also mit Exchange 2010 und Exchange 2013 sowie mit Windows Server 2012 und Windows Server 2008 R2 SP1, einsetzt? Das ist allerdings nur hypothetisch und natürlich nicht erlaubt, denn Exchange unterstützt keine DAGs mit verschiedenen Exchange-Versionen oder verschiedenen Betriebssystemversionen.

Tony Redmond/rhh

Dieser Beitrag basiert auf einem Artikel von Tony Redmond, der auf seinem Blog bei WindowsITpro erscheint.