2-Server-DAG - Mittelstandscluster

Ich sehe ein großes Potential einer Exchange 2010 Cluster Lösung auch gerade im klassischen Mittelstand, zumindest wenn Sie über mehr als einen Server nachdenken und die Verfügbarkeit  nicht in Stunden oder gar Tagen gefordert wird. Meine ersten Exchange 2010 haben mich darin bekräftigt.

Die Exchange 2010 Database Availability Group löst die Exchange 2007 Funktionen LCR, CCR und SCR komplett ab. Gerade für den Mittelstand ist die DAG aber bei einer ersten Betrachtung am ehesten mit dem Exchange Cluster zu vergleichen. Nun weiß ich selbst, dass gerade beim Thema "Cluster" bei vielen Firmen erst mal vorbehalte bestehen, weil dazu zum einen Windows Enterprise Server erforderlich sind und der Betrieb eines Clusters auch für gewöhnlich die Komplexität steigert.

Bei der neuen Exchange Database Availability Group ist das aber etwas anderes gelagert. Sie benötigen immer mindestens zwei Windows Enterprise Server Lizenzen und zwei Server (Hardware oder Virtuell). Im Gegensatz zu Exchange 2007 können aber die zusätzlichen Rollen CAS und HT mit auf dem Cluster installiert werden und die Funktion des Clusters ist so stark vereinfacht, dass Sie eigentlich gar nichts mehr davon bemerken. Durch die Kombination sparen Sie zudem zwei ansonsten erforderliche Exchange Lizenzen und zwei Windows Standard Lizenzen.

Wenn Sie allerdings die offiziellen Dokumentationen und Anleitungen studieren, dann finden Sie sich da nicht immer gleich wieder. Dort wird sehr gerne von großen Umgebungen mit zigtausend Postfächern, mehreren Exchange Postfachservern die sogar auf Redundanz bei Disks (RAID) und Backup verzichten und mehreren CAS-Servern als Array gesprochen. Aber es geht auch etwas "kleiner" und mit wenigen Einschränkungen.

Fakt ist natürlich, dass Sie zwei Server benötigen, die sich aber bei geschickter Konfiguration die Last teilen und die Funktion des jeweils anderen Server übernehmen können. Sie gewinnen die Skalierung und eine automatisch Ausfallsicherheit. Nur wie kann so eine Konfiguration aussehen ?

Ich möchte ihnen auf dieser Seite zwei Konfigurationen aufzeigen, die eine interessante Option darstellen könnte. Der Kniff besteht darin, wie die Kombination aus den Rollen ClientAccess/HubTransport und Postfachrollen konfiguriert werden, damit die Clients einen "virtuellen CAS"-Server erreichen, obwohl man auf dem Cluster kein NLB einrichten kann und die wenigsten kleinen Firmen einen vorgeschalteten Load-balancer haben. Es gibt vier Möglichkeiten für einen "kleinen" Cluster:

Name Klassische LoadBalancer IP-Failover Hyper-V
Beschreibung Der "klassische Ansatz" mit Mailbox Cluster und separaten CAS-Servern mit NLB Wenn ein externer Load Balancer  CAS-Rolle auf Cluster mit externem Load Balancer Zusätzliche IP als Cluster Ressource Mit Windows Enterprise als Basis können bis zu 4 Server virtuell betrieben werden, d.h. auf zwei physikalischen Servern lässt sich ein "klassischer" Betrieb einrichten.
Bild Klassischer Cluster mit separaten CAS
Systeme 2x Mailbox als MSCluster
2x CAS/HT mit NLB		 2x Mailbox/CAS/HT als MSCluster
2x Load Balancer		 2x Mailbox/CAS/HT 2x Mailbox als MSCluster
2x CAS/HT mit NLB
Lizenzen
Beschränkung auf 5 Datenbanken		 2x Windows Enterprise
2x Windows Standard
4x Exchange Standard		 2x Windows Enterprise
2x Exchange Standard		 2x Windows Enterprise
2x Exchange Standard		 2x Windows Enterprise
4x Exchange Standard
Supported Ja Ja unbekannt Ja
Lastverhalten alle aktiv alle aktiv nur ein Knoten macht CAS-Arbeit alle aktiv
IP-Adressen im LAN 5 Stück 3 bzw. 5 Stück 3 Stück 5 Stück

Bitte verstehen Sie diese Beschreibungen aber nicht als Detailbeschreibung.

Hyper-V Konfiguration

Die Lizenzierung eines Windows Enterprise Servers erlaubt auch den Betrieb von bis zu vier virtuellen Windows Enterprise Servern auf der gleichen Hardware mittels Hyper-V. Das eröffnet natürlich den Weg, auf zwei physikalischen Servern einfach je einmal Hyper-V (ohne Cluster !) zu installieren. Jeder Server hat dabei seinen eigenen lokalen Speicher.

Vereinfacht sieht das wie folgt aus.

Hyper-V DAG

Beachten Sie, dass es keinen Failover von einem Hyper-V-Gast von einem Host auf einen anderen Host erfolgt. Die virtuellen Maschinen sind fest mit dem Gastgeber verbunden. Die Verfügbarkeit erfolgt allein innerhalb der Gastsysteme.

Achtung:
Wenn Sie Hyper-V selbst noch "clustern", oder auf dem Host weitere Anwendungen installieren, dann betreiben Sie keine von Microsoft unterstützte Konfiguration.

Wenn Sie sich nun daran erinnern, dass Sie für all dies kein SAN oder anderen schnellen teuren Massenspeicher benötigen und Sie quasi mit Standard Hardware ein solches System aufbauen können, dann ist diese Lösung schon interessant. Allerdings kostet sie diese Konfiguration vier Exchange Server Lizenzen. (2x Standard für CAS und 2x Standard für bis zu 5 Datenbanken in der DAG, Enterprise für bis zu 100 Datenbanken)

DAG mit zusätzlicher Cluster-IP für CAS

Eine anderen Alternative kommt ohne Hyper-V aus. Ich installiere dazu zwei Exchange 2010 Server mit den üblichen Rollen Mailbox, ClientAccess und HubTransport und konvertiere diese in eine DAG. Soweit ist das alles noch Standard. Bei dieser Konfiguration wird ihnen aber jeder Consultant erzählen, dass Sie die beiden CAS-Server nicht wirklich hochverfügbar haben, da Sie diese nicht per NLB mit einem gemeinsamen Namen und IP-Adresse  veröffentlichen können. Dabei geht es nicht nur um OWA und ActiveSync aus dem Internet sondern auch der Zugriff von Outlook über MAPI, die seit Exchange 2010 auch über die CAS-Rolle erfolgen.

Das hindert uns aber nicht, dem Cluster, der bislang nur aus dem Clustername, dem Quorum  und einer IP-Adresse besteht, einen "generischen Dienst" zu konfigurieren, welcher NUR eine IP-Adresse hat. Wir brauchen keinen Namen und auch sonst keine Abhängigkeiten. Diese Gruppe ist einfach auf einem der Knoten "online" und wenn der Knoten ausfällt, dann schwenkt die IP-Adresse auf den anderen Knoten. Dann veröffentlichen wir im DNS noch einen Namen für diese Ressource und schon sind wir fast am Ziel: Wir haben einen Namen und eine IP-Adresse, hinter der sich ein CAS-Server meldet, auf einem der beiden Systeme online ist und sogar automatisch ein Failover macht.

Die Mailbox Server sind also wie bisher mit dem physikalischen Namen des Clusterknotens und seiner IP-Adresse erreichbar, während die Clients für den CAS-Zugriff einen dritten, vom physikalischen Knoten unabhängigen, Namen mit eigener IP-Adresse verwenden.

2-Server DAG

Auch hier muss über eine weitere Konfiguration dem Client diese Änderung mitgeteilt werden. Im MAPI-Profil des Clients darf nicht der Clusterknoten auftauchen, ansonsten ist noch etwas nicht korrekt.

Wer das Prinzip durchschaut hat, wird nun aber feststellen, dass ein Knoten nun nach außen auch die CAS-Last aufnimmt und die Zugriff entweder an die lokalen Postfachspeicher oder die Mailboxrolle auf dem anderem Knoten weiter gibt. Je nach dem wo die aktive Datenbank gerade liegt. Es könnte daher sinnvoll sein, die primären Datenbanken auf dem anderen Knoten zu betreiben und zwischen den Knoten eine gute Verbindung zu haben. Dann entspricht diese Konfiguration ein Stück dem Betrieb eines Postfachservers mit einem zweiten Server als CAS. Allerdings mit dem wesentlichen Unterschied, dass beide Rollen hochverfügbar sind, d.h. beim Ausfall eines Knotens der andere Knoten automatisch und schnell übernimmt.

Sie könnten diese Konstellation natürlich noch weiter entwickeln und einfach zwei IP-Adressen mit zwei virtuellen CAS-Servern konfigurieren um so die Last und die Zugriffe zu verdoppelt. Das ist sogar möglich und bei einer geschickten Konfiguration erreichen Sie damit so gar eine Lastverteilung.

Achtung:
Es gibt noch keine Bestätigung, dass diese Konfiguration "supported" ist.
Zudem ist der Zugriff auf öffentliche Ordner damit nicht abgedeckt, da Outlook dazu auf den Mailboxserver zugreift.

Einrichten des CAS-Arrays

Damit die Clients aber nicht die Rechnernamen der Clusterknoten sondern diese virtuelle Namen nutzen, müssen Sie ein CAS-Array einrichten.

New-ClientAccessArray -Name CAS -Fqdn cas.msxfaq.de -Site Paderborn
Get-MailboxDatabase | Set-MailboxDatabase -RpcClientAccessServer cas.msxfaq.de

All diese Änderungen sind nicht in der GUI sichtbar. Dokumentieren Sie daher, was sie tun. Aber dann können Sie in Outlook einfach "CAS" bzw. cas.msxfaq.de als Server eintragen und Outlook behält auch den Namen.

Achtung:
Beim Zugriff auf CAS Server ist die "Affinity" zu beachten. Wenn mehr als ein Server im CAS-Array aktiv ist, muss sichergestellt sein, dass Zugriffe eines Clients immer auf dem gleichen CAS landen. DNS-Round Robin ist daher kein gangbarer Weg.

Wer also unbedingt zwei CAS-Server bereit stellen möchte, könnte auf den Gedanken kommen und je zwei CAS-Arrays mit genau einem virtuellen CAS-Server als Mitglied zu definieren um dank auf 50% der Clients wird dann der Namen des einen CAS-Arrays und auf den anderen Clients das andere CAS-Array eingetragen.
Das funktioniert aber nicht, da es pro AD-Site immer nur genau ein CAS-Array geben darf.

Exchange Konfiguration abstimmen

Die Verwendung weiterer IP-Adressen mit weiteren Namen beeinflusst natürlich auch an anderen Stellen die Exchange Konfiguration

Eine gewissenhafte Planung und Konfiguration ist hier unterlässlich, aber würde den Rahmen dieser kurzen Anleitung sprengen.

Vergleich zu Exchange 2007

Vergleichen Sie diese beiden Alternativen einmal mit einer Exchange 2007 Verfügbarkeitslösung wie SCR oder CCR. Im Vergleich zu CCR ist die DAG natürlich schnell als Gewinner ausgemacht, da nun beide Server aktiv Daten betreiben können und die Kombination mit der CAS-Rolle die bei Exchange 2007 noch erforderlichen zusätzlichen Server bei der zweiten Variante überflüssig macht.

Aber selbst den Vergleich zu SCR muss die DAG nicht scheuen. Auch SCR benötigt zwei Exchange Server Lizenzen und zwei Server. Zwar kann auch ein SCR-Server "über kreuz" die Datenbanken eines anderen Servers replizieren aber der Failover ist dabei nicht dynamisch. Hier muss ein Administrator immer aktiv werden, selbst wenn er "geplant" einen Server für Updates nur kurz offline nehmen möchte. Dafür ist der Aufpreis einer Windows Enterprise Lizenz sicher zu verkraften.

Für mich stellt sich beim Kunden eigentlich nur noch die Frage, ob der Kunde mit den Einschränkungen eines noch günstigeren "Single Servers" arbeiten möchte. Ich gehe aber davon aus, dass aufgrund der Bedeutung eines Mailsystems die Exchange 2010 DAG schon fast zum Massenprodukt werden kann.

CASArray auf MSCluster ohne Tricks

Diesen (nicht supporteten) Trick mit der Failover-IP-Adresse benötigen sie nicht wenn sie eine der drei anderen Optionen nutzen.

Diese Lösungen sind auch immer vorzuziehen, wenn die Umgebung größer wird. Wenn Sie aber jeden Server und Komponente zählen, dann kann die hier vorgestellte Lösung mit ihren Einschränkungen (z.B. fraglicher Support) passend sein. Und im Zweifelsfall können Sie die DNS-Adresse immer noch auf einen Clusterknoten binden und damit das Üroblem nachstellen und "Supported" arbeiten.

Weitere Links

Keywords: E2010 CAS Cluster DAG NLB