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.

Generell sollten Sie sich beim Thema "Hochverfügbarkeit" an die Empfehlungen des Herstellers halten und abweichende Konfigurationen vermeiden. In Verbindung mit einem 2-Server-Cluster geht die aktuell nur mit einem vorgelagerten Lastverteilungssystem. LoadBalancer
Manchmal ist ein einzelner Server mit einer guten Überwachung und einen funktionierenden Backup sogar unterm Strich besser verfügbar und nebenbei günstiger.

Beachten Sie, dass Sie für die Funktion auch Domaincontroller und einen Witness-Server (Dateiserver) brauchen, die in der Regle aber sowieso da sind. Nicht alle Konfigurationen sind daher mit "genau zwei" Servern abzubilden. Die DAG besteht aus zwei Servern.

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 viele denkbare Möglichkeiten für einen "kleinen" Cluster, wobei nur eine Teilmenge davon "supportet" ist. Die anderen Optionen sind daher als Information aber nicht als Vorschlag oder gar Empfehlung zu verstehen:

Modell Bild IP Support
Status		 Beschreibung

4-Server mit NLB

5

OK

Der "klassische Ansatz" mit Mailbox Cluster und separaten CAS-Servern mit NLB. Allerdings ist dies natürlich kein "2-Server-DAG" mehr, sondern erforder mindestens 4 Server und passende Lizenzen.

Das Bild kann etwas verwirren da die gelben Pfeile, die die DAG-Replikation andeuten quasi durch die beiden CAS-Server geht. Die CAS-Server haben natürlich nichts mit der DAG-Replikation zu tun. Aber nur wenn die CAS bildlich in der Mitte stehen, dann passt der NLB-Block mit der IP3 oben sinnvoll hin.

Auch wenn dies eine supportete Konfiguration ist, so sollten Sie genau die Einschränkungen von NLB können, ehe Sie diesen Weg gehen.

Hyper-V

5

OK

Um aus der Konfiguration mit 4 Servern dennoch eine 2-Server-Konfiguration zu bauen, hilft uns Virtualisierung. Microsoft unterstützt ja mit VMWare, Hyper-V und Xen auch virtuell betriebene Exchange Server und heute Hardware ist meist leistungsfähig genug, in mittleren und kleineren Umgebungen auch mehrere Server zu betreiben.

Das ist die Basis dieses Hyper-V Paares, welches aber kein Hyper-V Cluster sein muss. Denn sowohl die CAS mit NLB als auch die Mailbox Rolle als DAG sind in sich schon hochverfügbar. Sie müssen also nicht noch die Hyper-V-Rolle mit MSCluster und einem SharedDisk versehen, um VMs hin und her schieben zu können.

Sie brauchen "nur" zwei virtuelle Windowsserver als VM, von denen einer CAS und der andere Mailbox-Server ist und das auf jedem der beiden physikalischen VM-Hosts einmal

Für den Betrieb von NLB in Verbindung mit Virtualisierung müssen Sie eventuell einige Besonderheiten bei der Netzwerkkonfiguration betrachten, z.B. der Einsatz von Multicast.

Lizenztechnisch ist das interessant, da Sie mit Windows Enterprise als Basis bis zu vier Server pro Host virtuell betrieben werden können., d.h. auf zwei physikalischen Servern lässt sich ein "klassischer" Betrieb einrichten. Allerdings benötigen Sie natürlich Exchange Lizenzen.

Load Balancer

Klassischer Cluster mit separaten CAS

3

OK

Die zweite und aus meiner Sicht bessere Variante ist der Betrieb mit einem vorgelagerten Lastverteilungssystem. Die IP-Adresse des CAS-Array verweist auf diese Adresse und das System verteilt die Anfragen auf den jeweils aktiven CAS-Server. Im Vergleich zu NLB hat das sehr viele Vorteile

  • Alternative Verteilungsoptionen
    NLB verteilt Verkehr statisch nach der Quell IP/Quellnetz aber kann keine Rücksicht auf Zielports oder URLs oder Dienste nehmen. Ein LoadBalancer kann oft sogar die aktuelle Last der Zielsysteme z.B. per SNMP oder HTTP-Anfragen ermitteln und das System als Ziel wählen, welches am wenigsten tut.
  • Sicherheit
    Viele Lastverteiler sind zwar keine Firewall aber "kennen" schon die Protokolle, die sie verteilen sollen und können beim HTTP-Verbindungen die URL prüfen und unerwünschte Zugänge damit schon blockieren.
  • Offloading SSL
    Fast alle Systeme macht dabei nicht nur ein einfaches TCP-Forwarding, sondern können sogar HTTPS-Anfragen selbst terminieren und nach intern ohne Verschlüsselung weiter reichen. Das entlastet die CAS-Server.

Insofern gibt es eigentlich sehr viele Argument für den Einsatz einer solchen Lösung, auch wenn die Lastverteiler zusätzliche Systeme sind, die Anschaffungs- und Betriebskosten verursachen. Im Bereich der Verfügbarkeit sind dies aber die geringeren Probleme, zumal diese System auch noch für andere Dienste genutzt werden könnten.

Hinweis: Ein ISA/TMG-Server kann auch eine Webfarm veröffentlichen und daher als Loadbalancer für CAS-Server dienen. Er kann dies aber NICHT für RPC

DNS-Failover

2

Denkbar

Microsoft schreibt, dass ein Client immer den gleichen CAS-Server verwenden soll, und nur dann wechseln muss, wenn der Server ausgefallen oder herunter gefahren wurde. Nun könnten Sie ja einfach den Namen des CAS-Array auf eine physikalische IP-Adresse eines Clusterknotens binden. Fällt dieser aus oder wird er zur Wartung herunter gefahren, dann können Sie ja im DNS-Server einfach den Eintrag auf den anderen CAS-Server ändern und den DNS TTL Abwarten. Nach und nach

  • Keine Lastverteilung
  • Verzögerung beim umschalten

Eine Aussage zur Supportability habe ich nicht. Ich kann mir denken, dass es sogar supportet ist, aber die FunktionsEinschränkungen und Zusatzarbeiten sind doch so, dass diese Konfiguration nicht ernsthaft in Betracht gezogen werden sollte.

ClusterIP

3

KEIN Support

Die ganze umschaltung von DNS-Einträge könnten Sie sich sparen, indem Sie einfach die Cluster IP oder eine neu angelegte IP-Adresse als Cluster-Ressource definieren und damit dem Microsoft Cluster den Schwenk im Fehlerfall überlassen.

Sie könnten also zwei Exchange 2010 Server mit den üblichen Rollen Mailbox, ClientAccess und HubTransport als DAG installieren. Soweit wäre alles noch Standard aber eben noch nicht hoch verfügbar.

Sie könnten nun aber die Funktion von Windows Cluster nutzen um IP-Adressen immer auf einem aktiven Host zu schwenken. Das könnte die IP des Cluster Servers oder eine neue zusätzliche IP sein. Fällt ein Knoten aus, würde die Adresse zum anderen Knoten schwenken, der auch eine aktive CAS-Rolle hat.

Technisch erscheint das alles perfekt und hat mit wenig Last sogar funktioniert. Allerdings gibt es drei relevante Punkte:

  • Partieller CAS-Fehler wird nicht erkannt
    Das es für die CAS-Rolle keine Cluster Ressource gibt, kann der Ausfall der CAS-Rolle nicht vom Clusterdient erkannt werden. Wenn also etwas oder jemand einfach den IIS stoppt, dann schwenkt hier nichts. Die Verfügbarkeit ist also nicht da
  • Lastverteilung
    Zudem wäre ja immer nur ein Server aktiv und der andere tut "nichts". Sie müssten also zumindest die CAS-Rolle stärker auslegen.
  • Kein Support
    Microsoft testet und beschreibt diese Konfiguration nicht und damit sind sie immer "unsicher", ob eine aktuell funktionierende Umgebung mit dem nächten Update, Servicepack oder Drittprodukten weiter funktioniert

Zudem kann ich nicht sagen, ob diese Lösung wirklich auch skalierbar und unter hohen Lastbedingungen stabil läuft.

DNS Round Robin

 

Kein Support

Wer nun denkt, dass man doch einfach die beiden CAS Server per DNS zweimal einträgt, der glaubt eine funktionierende Konfiguration zu erhalten, der irrt. Ohne Last könnte es sogar funktionieren, dass ein Client bei einer DNS-Anfragen einmal die eine und einmal die andere IP-Adresse erhält, aber hochverfügbar ist dies nicht, denn:

  • Keine Fehlerfalllösung
    Wenn ein CAS-Server "down" oder gestört ist, dann wird der DNS-Server weiterhin die Daten ausliefern und den Client zu 50% in die Irre lenken. Selbst wenn der Server gar nicht mehr erreichbar ist, wird der Client es weiter versuche, denn Outlook "versteht" einfach nicht, dass es noch eine zweite IP-Adresse geben könnte. Erst wenn der DNS-Cache des Clients den nicht erreichbaren Server wieder entfernt und bei der nächsten Anfrage dann zufällig der andere Server zurück gegeben wird, kann der Client weiter arbeiten-
  • Affinity
    Aber selbst wenn alles geht, dann kann es passieren, dass ein Client für jede Connection (Und Outlook hat mehrere), einen anderen CAS-Server verwendet. für jeden braucht er Anmeldedaten und jeder CAS muss die Sessions verwalten. Damit haben mehrere Server mehrfach die Last.

Dieses Konfiguration ist daher nicht unterstützt.

NLB + DAG kombiniert

 

NIcht möglich

Wenn Sie bei all den Optionen die Konfiguration vermissen, bei der einfach alle Rollen auf einen Server konsolidiert betrieben werden und vielleicht per NLB dann der Zugriff auf CAS und HT erlaubt werden soll, dann sollten Sie noch mal die Systemvoraussetzungen für Windows Cluster und NLB lesen. Diese beiden Dienste vertragen sich nicht auf dem gleichen Server.

Das funktioniert also nur, wenn Sie unterschiedliche Serverinstanzen, d.h. eigene Server in Hardware oder virtuell haben.

Sie sehen also, dass viele nette Ideen, die eine DAG auch für kleine und mittlere Firmen interessant werden lassen, doch am Ende nicht umsetzbar sind und und zwei Optionen auch sinnvoll sind. Wer "Verfügbarkeit" will, solle genau prüfen, wo er wie viel Geld investiert. Ich stehe ja immer noch auf dem Standpunkt, dass ein gut überwachter (Eventlog, Perfmon, SNMP) und abgesicherter (Backup, uSV, Updates) unterm Strich sicherer, stabiler und verfügbarer ist, also ein halbwegs implementierter Cluster. Wenn Sie den Hyper-V-Weg gehen und sich an den zwei zusätzlichen Exchange Standard Server Lizenzen aufhalten, dann sollten Sie generell noch mal das Thema "Hochverfügbarkeit" überdenken.

Auch die Argumentation mit dem Loadbalancer kann ich immer weniger nachvollziehen, da diese Systeme nicht nur für Exchange relevant sind, sondern auch gut bei Sharepoint, Proxy aber auch anderen TCP-Verbindungen zum Einsatz kommen können. Und wer Exchange "hochverfügbar" macht, wird sicher noch das ein oder andere System haben, welches durch den dann vorhandenen Load Balancer davon profitieren kann.

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.

  • Exchange DAG
    In dieser Hyper-V Umgebung kann nun in einer virtuellen Maschine auf jedem Knoten ein Windows Enterprise Server mit Exchange Standard installiert und als Cluster konfiguriert werden.
  • CAs per NLB
    Zwei weitere Server werden als CAS/HT-Server installiert und per NLB "hochverfügbar" gemacht. Damit die Clients diesen "neuen" Server nutzen, müssen wir noch ein CAS-Array konfigurieren, was weiter unten beschrieben ist.
  • Optional: DCs
    Wer mag kann natürlich auf den Hyper-V-Host noch je einen weiteren Gast mit entsprechenden Domaincontrollern betreiben.

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)

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

  • Zertifikate
    Wer mehr als nur die physikalischen Namen der Server in der Konfiguration verwendet und mit virtuellen geclusterten IPs und CAS-Arrays agiert, muss auf den Exchange Servern natürlich auf "passende" Zertifikate einrichten, die den Namen enthalten, der von den Clients verwendet wird.
  • External-URL
    An verschiedenen Stellen der Konfiguration ist eine External-URL gepflegt, damit Autodiscover die richtigen Pfade an die Clients melden kann. Diese müssen auf ihre gewählte CAS-Konfiguration passen

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 müssenprodukt werden kann.

Weitere Links