Exchange im Cluster

Lesen Sie unbedingt auch Hochverfügbarkeit und Clustergrundlagen. Sie finden dort sehr viele Grundlagen zum Clustereinsatz im Unternehmen. Sie finden hier keine Beschreibung mehr für Exchange 5.5 Cluster, da ich nicht davon ausgehe, dass diese noch installiert werden. Die Funktion von Exchange 5.5 ist sehr unterschiedlich zu Exchange 2000/2003.

Lesen Sie unbedingt "vorher" Hochverfügbarkeit und Clustergrundlagen, und dort insbesondere den Hinweis, welche Dienste nicht auf Cluster installiert werden können.

Exchange 2003 mit Windows 2003 unterstützt bis zu 8 Clusterkonten mit 7 aktiven virtuellen Servern a 20 Datenbanken.
http://msexchangeteam.com//archive/2005/09/09/410522.aspx

Servicepack und Cluster.
Sie können das Servicepack problemlos auf dem passiven Knoten installieren. Nur installieren Sie das Service Pack immer von einer lokalen Festplatte oder einem Netzwerklaufwerk und NICHT von einer Shared Disk, das das Setup den Clusterdienst am Ende durchstartet und damit selbst nicht mehr auf seine Quelle kommt.

Formbased Authentication ist nur mit Frontend Servern möglich
834637 The "Enable Forms Based Authentication" check box is unavailable in Exchange Server 2003

Exchange 2010

Mit Exchange 2010 wurde die Thematik Cluster noch mal kräftig umgekrempelt. CCR, LCR und SCR ist nicht mehr und statt dessen gibt es nur noch die Database Availability Group für die Postfachspeicher und LoadBalancer bzw. NLB für die CAS/HT-Rollen.

Exchange 2007

Mit der Verfügbarkeit von Exchange 2007 gibt es eine neue Möglichkeit, Exchange hochverfügbar zu betreiben. Details hierzu finden Sie auf

Exchange 2000/2003 im Cluster

Exchange 5.5. konnte nur auf einen Cluster mit zwei Knoten im Aktiv/Passiv Mode betrieben werden. Dies bedeutet, dass ein Knoten Exchange betrieben hat, während der andere Knoten nur darauf gewartet hat, dass der erste ausfällt.

Exchange 2000 bietet nun Aktiv/Aktiv an, d.h. beide oder alle vier Knoten sind aktive Server. bei einem 4-Knoten Cluster sehen Sie im Netzwerk auch mindestens 8 Server !!. Die vier einzelnen Knoten als Windows 2000 Server und zusätzlich vier Exchange 2000 Server. Aber sie sehen nicht, auf welchen Knoten welcher virtuelle Exchange Server gestartet ist. Im schlimmsten Fall übernimmt der einzige verbliebene Server alle vier virtuelle Server.

Jeder virtuelle Exchange hat dabei seine eigene Festplatte oder mehrere Festplatten, denn aus der Information zur Exchange Datenbank wissen wir, dass Datenbank und Transaktionsprotokolle getrennt sein sollten. Nun ist auch klar, warum Exchange bis zu vier Speichergruppen unterstützt. Für den Betrieb von Exchange im Cluster benötigen zu je Knoten eine Lizenz Exchange 5.5. Enterprise oder Exchange 2000 Enterprise.

Sie dürfen das Exchange Setup erst aufrufen, nachdem der Server schon Mitglied des Clusters ist. Nur dann erkennt das Setup, dass es sich um eine Clusterinstallation handelt. Bei der Installation werden alle Programme auf die lokale Festplatte des Clusters installiert. Die Installation darf NICHT auf den gemeinsamen Festplatte erfolgen.

Erst nach der Installation auf allen Knoten sollte dann die Ressource "Exchange System Aufsicht" eingerichtet werden. Der Assistent richtet dann alle anderen Ressourcen für Sie ein.

Das Bild zeigt einen einfachen 2-Knoten Cluster mit zwei Gruppen. Die erste Gruppe enthält nur den Clusternamen, das Quorum und die dazugehörige IP-Adresse. Die angezeigte zweite Gruppe ist der eigentliche Exchange Server. Es ist sinnvoll dies zu trennen, da damit der Cluster auch funktioniert, wenn z.B. die Exchange Gruppe "offline" ist.

Der primitive Cluster

Zum Einstieg planen wir einen sehr kleinen Cluster. Dieser soll nur die Prinzipien erklären und sollte in der Form nicht installiert werden.

Zwei identische Knoten werden mit einer Netzwerkkarte an das Hauslan angeschlossen und über eine zweite Karte als Heartbeat verbunden. Der Cluster könnte zwar auch ohne diese zweite Verbindung arbeiten, aber dann müsste beim Ausfall des Netzwerks jeder Cluster erst über das Quorum klären, welcher denn nun DOWN ist und welcher nicht. Ein separates Heartbeat Netz ist daher eine Mindestvoraussetzung für einen Cluster. Hierzu reicht aber auch eine 10MBit-Karte mit einem Kreuzkabel, so dass Kosten kein Grund auf einen Verzicht sind.

Weiterhin haben beide Cluster einen SCSI-Controller, der an einen gemeinsamen Speicherbereicht angeschlossen ist. Es gibt unterschiedliche Lösungen, wer nun das "RAID-1" bildet. Sehr einfache Lösungen nutzen den RAID-Controller im Host selbst, um das RAID zu bauen. Etwas bessere Lösungen haben einen eigenen RAID-Controller im Speichersubsystem, der den einzelnen Controllern eine Festplatte simuliert. Die Verbindung kann dabei auf drei Wege erfolgen:

Sie sollten schon zur eigenen Sicherheit nur Komponenten einsetzen, die auf der Windows Cluster HCL aufgeführt sind. Auch bei BIOS-Update ist mit Vorsicht vorzugehen, da einige Controller für den Einsatz im Cluster ein anderes Bios verwenden oder in der Konfiguration der Betrieb an einem Shared BUS explizit zu aktivieren ist.

Da nur eine gemeinsame Festplatte zur Verfügung steht, kann auch nur eine Clustergruppe eingerichtet werden. Dies macht der Assistent zur Clusterinstallation für Sie. In dieser Clustergruppe wird die Systemaufsicht angelegt. Der Assistent erfragt dann gleich die Pfade für die Datenbanken und Protokolldatei. Diese können Später mit dem Exchange System Manager wieder verschoben werden.

In diesem Beispiel ist die gemeinsame Platte aber zumindest in zwei Partitionen getrennt, damit das Laufwerk für die Quorum Disk nicht durch Exchange voll geschrieben werden kann. Best practice ist natürlich, dass die Festplatte für das Quorum eine eigenständige Festplatte ist.

Diese Mustercluster hat einige Defizite, die einer Realisierung widersprechen:

Spätestens jetzt ist klar, dass dieser Cluster nur zum Üben gedacht ist.

Der kleine Cluster

Aber was ist dann der kleinste "richtiger" Cluster ?. Entsprechend der Vorgaben bedeutet eine sinnvoll unsere Grenze, dass

Demnach stellt sich das Bild wie folgt dar: Beide Knoten haben wieder eine Verbindung zum Hauslan und ihren Clusterlink. Das Speichersubsystem ist über getrennte SCSI-Kanäle angeschlossen und drei logische Festplatten werden dem Cluster präsentiert.

Eine RAID1-Disk für das Cluster Quorum und zwei RAID1-Disks für die Exchange Datenbank und Transaktionsprotokolle. Denkbar ist natürlich auch ein RAID5, allerdings sollte sie immer beachten, dass ein RAID5 in der Regel langsamer ist, sie mehr Platteneinschübe brauchen und zwei größere Festplatten nicht unbedingt viel teurer sind als drei kleine Festplatten. Speziell wenn Sie sich damit dann Einschübe für spätere Erweiterungen verbauen.

Der mittlere Cluster

Wenn ihnen der kleine Cluster nicht reicht, dann wird es Zeit etwas mehr zu machen. Die Steigerung bei dem Beispiel besteht darin, dass:

Wenn Sie schon für Hochverfügbarkeit planen, dann sollte es möglichst wenig "Single Point of Failure" geben. Kabel und Karten sind immer gefährdet so dass redundante Wege eine gute Sache sind.

Beachten Sie beim Teaming, dass die meisten Netzwerk kein Loadbalancing Teaming über mehrere Switches unterstützen, sondern nur ein Failover Team. Trotzdem ist dies weiterhin ein Aktiv/Passiv Cluster, weil es nur eine Clustergruppe gibt, in der allerdings zwei Speichergruppen mit mehreren Datenbanken liegen. So haben wir eine gesteigerte Performance und die Unabhängigkeit im Bezug auf Backup etc. (Siehe auch Exchange Sizing - Speichergruppen und Datenbanken).

Einen Aktiv Aktiv Cluster wäre mit dieser Konstellation auch möglich. Allerdings besteht bei einem A/A-Cluster immer das Problem, dass nach einiger Zeit der Speicher doch fragmentiert wird und ein Failover damit nicht mehr sicher gegeben ist. Es gibt immer wieder mal Empfehlungen von Microsoft, dass A/A funktioniert, wenn nicht mehr als 1000 bis 1500 Verbindungen pro Knoten betrieben werden.

Nur zur Erinnerung: Dieser Cluster benötigt mindestens 4 IP-Adressen im Hauslan (Node1, Node2, CLuster und VS1) und die Adressen für den Clusterlink.

Enterprise Cluster

Um, die Hardware besser Auszunutzen kann man aber aus 4 Clusterknoten einen Cluster formen, bei dem drei Knoten aktiv sind und einer passiv bleibt. So funktioniert ein Failover beim Ausfall eines Knotens zuverlässig. Der mittlere Cluster hatte schon sehr viel Dinge hochverfügbar angelegt. Aber bislang ist der Shared Storage immer die Achillesferse der Cluster geblieben. Diese Konfiguration erweitert den Cluster nun um folgende Komponenten:

Damit wird das Bild natürlich etwas umfangreicher und damit sind die Möglichkeiten von Exchange immer noch nicht ausgeschöpft. Exchange 2000/2003 kann ja bis zu 20 Datenbanken betreiben. In diesem Muster sind es "nur" fünf Postfachspeicher und einen Speicher für öffentliche Ordner.

Die doppelten Speichereinheiten stehen natürlich am besten in verschiedenen Räumen, Etagen, Gebäudeabschnitten, Brandabschnitten. Über die beiden FibreChannel Switches und doppelte Anbindungen ist jede Komponente doppelt abgesichert. Wenn Sie aber mal genau zählen, dann werden Sie feststellen dass Sie...

Aber das ist genau das, was Sie sich unter Windows Datacenter vorstellen können. Und seit Exchange 2003 und Windows 2003 können Sie mit dem ganz normalen Enterprise Version sogar einen 8-Knoten-Cluster aufbauen.

Cluster Migration

Ein Exchange Server im Cluster sieht wie ein "normaler" Exchange Server aus. Wenn Sie die Daten ihres bestehenden Server auf einen Cluster bringen wollen, dann sollten Sie die Postfächer verschieben und die Ordner replizieren. Bitte versuchen Sie nicht, einen einzelnen Server mit Exchange nachträglich zum Cluster umzubauen. Das geht höchstwahrscheinlich schief. Sie können dies versuchen, indem sie ihren aktuellen Datenbestand sichern, den Server neu als Cluster installieren und dann ein Restore in den Cluster machen. Aber meist ist der vorhandene Server sowieso älter und nicht Cluster zertifiziert, so dass diese Option recht selten sein sollte.

Wenn Sie sich die Ausführung von oben noch mal durch den Kopf gehen lassen, dann sollten Sie erkennen, dass sie besser den Cluster neu kaufen und installieren und ihren bisherigen Exchange Server einer anderen Verwendung, z.B. als OWA-Server in der DMZ oder als Server für Connectoren zuführen.

Weitere Hinweise

Und dann gibt es noch die üblichen Hinweise, die aber 100% ernst gemeint sind:

Wir betreuen Windows 2000 Dateiserver mit 900 Gigabyte und über 30 Festplatten ebenso wie Exchange Server für 4000 Postfächer mit permanenten Lasten von 10 Nachrichten pro Sekunde und mehreren Gigabyte Transaktionsprotokolle pro Stunde. Sowohl Windows als auch Exchange sind skalierbar, robust und für ernsthafte Anwendungen ausgelegt. aber nicht auf einem PC vom Discounter mit einem Hardwaredesign aus der Bastelkiste.

Cluster und Servicepack

Die Installation eines Servicepack auf dem Cluster ist im Prinzip einfach. Sie verlagern die Ressourcen derart, dass ein Knoten keine Dienste mehr hat und installieren dort das Servicepack. Danach müssen Sie im Cluster Administrator diesen Knoten noch "hochrüsten". Beim Verlagern der Ressourcen auf diesen Knoten werden dann eventuell die Daten auch aktualisiert. Ein Fallback auf Knoten ohne Servicepack ist meist nicht möglich. Also müssen Sie nun auch noch die anderen Knoten nacheinander reihum aktualisieren.

Ob Exchange einen Knoten als "Hier ist Exchange installiert" erkennt, macht er an einem Registrierungsschlüssel  (MSExchange_NodeState und MSExchange_CurrentBuild) fest, welche durch die Installation gesetzt werden.

Suchen Sie besser den Grund, warum, das Setup den Wert nicht gesetzt hat und setzen Sie den Wert nicht manuell. Ein "Setup /Reinstall" und Servicepacks ist die bessere Wahl.

Die Bedeutung der beiden Schlüssel:

Die aktuellen Versionen könne Sie durch die beiden Kommandozeilen erhalten

Anzeige der Exchange Version auf den Knoten:
cluster.exe /node "NODENAME" /priv

MSExchange_CurrentBuild:
NODE1: 500563969
NODE2: 473563136

Anzeige der Version der Systemaufsicht
cluster.exe /res "Name der Systemaufsicht" /priv
System Attendant ResourceBuild:
473563136

Natürlich sind manuelle Änderungen ohne Zusammenarbeit mit Microsoft hier nicht ratsam.

Kleiner Clusterwächter

Wenn Sie nun ihre Cluster installiert haben, dann kann es sein, dass Sie einen Fail-Over eigentlich gar nicht bemerken, besonders wenn dieser außerhalb der Geschäftszeiten statt findet. Hier können Sie sich mit einem einfachen Batch behelfen. Jede Clustergruppe hat eine gemeinsam genutzte Festplatte. Auf dieser  gemeinsamen Festplatte legen Sie einen kleinen Batch "Clusterwatch.cmd" mit folgendem Inhalt an:

echo off
echo %DATE% % TIME% Clustergruppe wurde gestartet >>clusterinfo.txt
echo Info | blat.exe - -server mailserver -to ziel@firma.de -f sender@firma.de -s Clusterschwenk
PAUSE

Dieser kleiner Batch wird nun in der Clustergruppe als Ressource (Generic Application) mit eingebunden.

Befehlszeile : S:\Clusterwatch\clusterwatch.cmd
Aktuelles Verzeichnis: S:\Clusterwatch\

Was nun passiert ist schnell erklärt:

Wenn nun der Cluster aufgrund eines Fehlers schwenkt, wird zwar nicht mehr das "Offline"-Nehmen der Clustergruppe gemeldet, aber das erneute Online-Schalten auf einem anderen Knoten sehr wohl. Das ersetzt zwar kein Monitoring, wie dies z.B. mit MOM2005 möglich ist, aber zumindest ein kleiner Hinweis auf Umschaltvorgänge auf dem Cluster Server.

Wenn Sie übrigens MOM2005 für die Überwachung einsetzen, dann sollten Sie folgende Aussage beachten.

The agent is deployed to the nodes and the Management Pack is deployed to the Virtual Servers.

Dies bedeutet, dass Sie den MOM-Agenten selbst auf jeden Knoten installieren müssen aber das Management nur auf die virtuellen Server anwenden, d.h. in der Computergruppe "Exchange Backend Server" die virtuellen Server addieren und optional die physikalischen Knoten ausschließen.

Cluster Checkliste

Der wichtigste Check für eine bestehende Clusterumgebung ist natürlich ExBPA. Aber einige Eckpunkte sollten Sie im Cluster noch manuell überprüfen, z.B.:

Cluster.exe /prop EnableEventLogReplication = 0

Eine gute Beschreibung hierzu finden Sie auch auf der TechNet unter ms-help://MS.TechNet.2006FEB.1033/exchange/tnoffline/prodtechnol/exchange/exchange2003/proddocs/library/e2k3clst.htm

Cluster Debugging

Eigentlich ist der Status eines Clusters im Clustermanager sehr einfach einzusehen. Wenn aber doch mal ein Failover stattfindet oder andere Probleme genauer zu untersuchen sind, dann ist das Eventlog die erste Anlaufstelle. Beachten Sie dass die Eventlogs zwischen den Clusterknoten repliziert werden, dies aber abschaltbar ist.:

EventID Beschreibung
1203 Start eine Clustergruppe "Offline" zu nehmen. Dies ist meist der Start eines Failovers und erscheint auf dem Cluster, der dann die Gruppe aktiv betreibt
1204 Gruppe wurde erfolgreich offline geschaltet
1200 Start eine Clustergruppe "Online" zu nehmen. Dies Meldung erscheint dann auf dem Knoten, der nun diese Gruppe aktiv betreiben soll.
1201 Gruppe erfolgreich online geschaltet und zeigt das Ende eines Failovers an. Darauf kann man sehr gut filtern, um die Umschaltungen zu finden
1069 Allgemeiner Fehler. Diese Meldung hilft bei der Eingrenzung, welche Ressource für den Failover verantwortlich war

All diese Meldungen helfen aber nicht, wenn der Clusterdienst selbst ein Problem hat. Daher kann manb zusätzlich auch noch ein Debugging einschalten (Siehe Q168801 How to turn on cluster logging in Microsoft Cluster Server). Dabei wird etwas ungewöhnlich über System-Umgebungsvariablen dem Clusterdienst gesagt, wohin und in welcher Detailtiefe er Debug-Ausgaben schreiben soll

In der Datei sollten dann ausreichend Informationen landen, um den Fehler genauer einzukreisen. Wem das immer noch nicht hilft, kann den Clusterdienst auch mit der Option "/debug" starten, so dass in dann geöffneten Fenster weitere Meldungen angezeigt werden.

Weitere Links

Keywords:Cluster Hochverfügbar