Geografische Cluster

Unter geografischen Clustern verstehen die meisten Firmen eine Hochverfügbarkeit, bei denen auch großräumigere Probleme überstanden werden können. Das kann ein zweites Rechenzentrum in einem anderen Brandabschnitt der gleichen Firma sein, das kann aber auch ein Ausweichrechenzentrum sein, welches weniger Kilometer oder sogar Kontinente entfernt sind.

Und mit der Bedeutung von Mail als firmenkritischer Bestandteil werden immer mehr Firmen hier nach Lösungen für Exchange suchen. Dabei reicht es aber nicht, nur den Exchange Server und die Optionen einer Duplizierung zu betrachten. Auch die komplette Infrastruktur (DNS, WINS; NTP, Active Directory etc.) muss entsprechend ausgelegt wird. Wäre doch schade, wenn der primäre Server aufgrund Hochwasser samt dem Gebäude, in dem er steht, ausfällt und der sekundäre Knoten vielleicht noch starten will aber keinen Domaincontroller, DNS Server o.ä. mehr hat. Aber selbst wenn er startet, müssen immer noch die Clients diesen Server erreichen können. Häufig wird genau diese kleine Stelle beim Design übersehen. Alle Server laufen dann aber es gibt keine Verbindung zu den Clients mehr.

Besonderheiten Geocluster

Eigentlich ist über das Thema "Cluster" schon viel geschrieben. Beim Einsatz geografisch verteilter Systeme gibt es aber zwei Dinge die solche Szenarien immer wieder interessant machen:

  • Laufzeit
    Je "länger" die Leitung ist, desto länger wird auch die Laufzeit. Zum Glück hat dies direkt proportional mit der Bandbreite zu tun. Was gerne als "Breite" bezeichnet ist ist in Wirklichkeit die "Schrittgeschwindigkeit" und damit direkt proportional zur Laufzeit der Signale.
    Das ist besonders dann wichtig, wenn Daten zwischen zwei Servern repliziert werden und die Anwendung erst dann ein "OK" bekommt, wenn diese auf beiden Servern (synchron) geschrieben wurden.
  • Datenmenge
    Der zweite Killer ist natürlich allein die Datenmenge. Kaum ein Server rechnet heute noch in Kilobyte und damit werden auch auf einem Server meist mehrere Megabyte, manchmal innerhalb von Sekunden, verändert. Auch diese Änderungen müssen möglichst schnell oder sogar gleichzeitig auf beiden Systemen erfolgen. Damit ist dann der Durchsatz und auch die garantierte Bandbreite (QoS) relevant.
    Einige Systeme replizieren dabei per Ethernet ihre Änderungen aus Anwendungsebene (wie z.B. Cluster Continuous Replication) während andere auf Hardwareebene die Festplatten blockweise spiegeln (RAID1 etc.) oder sogar Hauptspeicherinhalte abgleichen.
  • Namensauflösung und Routing
    Wenn wirklich ein kompletter Standort ausfällt und ein anderer Standort übernimmt, dann müssen natürlich auch die externen Hostname (owa.firma.tld etc.) aber auch interne Dienste (z.B.: CAS) mit geschwenkt werden. Fragen dazu sind dann natürlich zu stellen wie: DNS-Cache Timeout bei neuen Adressen, IP-Routingtabellen und redundante Anbindung, AD-Sites über Standorte aufspannen, Zuordnung von Clients zu Servern wenn diese logisch "ein Netz" sind etc.

Also sind die beiden wichtigen Fragen, wie eine Lösung mit beschränkter Bandbreite und längeren Laufzeiten für Pakete umgehen kann.

Exchange "geografisch" geclustert

Microsoft kennt mit Exchange 2007 gleich mehrere Möglichkeiten, Informationen auf mehrere Standorte zu replizieren oder zu kopieren. Nicht alle hier vorgestellten Optionen scheinen "sinnvoll" zu sein aber regen doch zu Überlegungen an. Sehen Sie es als "Quiz" an, ob ihnen eine noch bessere Lösung einfällt. Ich habe absichtlich sowohl automatische als auch manuelle Lösungen aufgeführt, sofern der Failover nicht zu einem "Restore von Band" ausartet. Allerdings sind keine "Dritthersteller" aufgelistet, die oft die ein oder andere Lösung einfach besser umsetzen.

Bei der Replikation von Exchange Datenbanken ist natürlich zu berücksichtigen, dass Exchange sowohl "Transaktionsprotokolle" als auch die Datenbank ändert. Wird daher die "DISK" kopiert, dann müssen meist beide Schreibbefehle auch remote ausgeführt werden. Anders ist dies, wenn nur die Transaktionsprotokolle übertragen werden müssen.

Neben der neuen Lösung CCR und den schon lange bekannten Optionen eines "Single Copy Cluster" mit Replikation durch das SAN sind alle anderen Wege eher theoretischer Natur:

Lösungsansatz Daten Beschreibung

Klassischer Cluster mit SAN Replikation
Cluster mit SAN Replikation

WriteDB
WriteLog

Seit Exchange 5.5 erlaubt Microsoft das Clustern von Exchange mit MSCS. Allerdings nutzt Exchange dazu eine Shared Disk. Von Geocluster ist da nichts zu sehen. Ein RAID1 mit dynamischen Datenträgern ist unter Cluster nur mit Add-Ons von Drittherstellern (Veritas Volume Manager) möglich. Allerdings gibt es Hersteller von SAN-Speicher, die transparent für den Server die Daten auf zwei Subsysteme abspeichern und replizieren. Damit ist es dann möglich, die Daten wirklich auf beiden Seiten vorzuhalten

RAID1 per iSCSI/FC
RAID1 mit iSCSI

WriteDB
WriteLog

Windows 2003 R2 erlaubt von Hause aus die Anbindung von iSCSI-Festplatten und per SAN. Bei einem Standardserver ist es damit denkbar, per Software (RAID1) eine Kopie der Daten auf einem weiter entfernt stehenden Speicher vorzuhalten. Beim Failover reicht es dann, auf einem anderen Server flugs Exchange zu installieren und die vorhandene Datenbank weiter zu nutzen.
Der Einsatz auf einem Microsoft Cluster Server ist aber auch hier nicht möglich

LCR mit iSCSI/FC
LCR mit iSCSI

WriteLog
ReadLog
WriteDB

Erst Exchange 2007 kennt eine Funktion "LCR". Eigentlich kann damit auf dem Server selbst eine zweite Kopie der Datenbank anlegen, um im Fehlerfall darauf umschalten zu können und beim Backup nicht die produktive Festplatte zu belasten.
Dieser Massenspeicher muss für Windows nur wie eine "lokale Festplatte" aussehen. Auch diese Festplatte muss natürlich nicht im Server eingebaut sein. Eine entfernte Festplatte kann problemlos eine Kopie tragen. Im Fehlerfall besteht also auch hier eine Option über ein Desaster Recovery einen neuen Server mit den Daten dieser Kopie zu starten.
Allerdings ist LCR dazu aufgrund der IO-Last eigentlich nicht wirklich geeignet, da sowohl die Logfiles geschrieben und wieder gelesen und in die Datenbank eingebaut werden.

CCR
CCR

WriteLog

Daher ist CCR der eigentlich beste Weg heute einen geografisch verteilten Cluster aufzubauen. Es werden nur die Logdateien zum Zielsystem übertragen, welches daraus die Datenbank nachführt. Im Fehlerfall übernimmt der vorher passive Knoten die Funktion komplett mit minimalem Datenverlust.

Sowohl beim Einsatz von CCR als auch durch replizierte SANs ist immer ein Windows Enterprise Server für die Funktion "Cluster" erforderlich.

Alle anderen hier angedachten Lösungen schaffen es maximal, die Datenbank, die natürlich die signifikante Datenmenge bei einem Notfallrestore ausmacht, auf einem weiteren Festplattensystem abzulegen. Ein automatisches Failover geht hier mit nicht. Allerdings ist es sehr einfach einen Exchange Server wieder zum leben zu erwecken, wenn die Konfiguration im Active Directory vorhanden ist und die Datenbank nicht restauriert werden muss. Dann reicht z.B. ein schnelles Restore des Systemstate und selbst eine Desaster-Installation ist bei entsprechender Vorbereitung in weniger als einer Stunde zu schaffen.

Unterstützung durch Net at Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach an.

Failover und dann ?

Häufig wird aber vernachlässigt, was bei einem erfolgreichen Failover nun mit der Umgebung passiert. Der aktive Server steht nun im Idealfall in einem anderen Rechenzentrum. Nun stellt sich natürlich die Frage, ob auch alle anderen Systeme und vor allem die Clients den neuen Server weiterhin erreichen können.

Zudem wird nun offensichtlich, wenn die Bandbreiten nicht ausreichend dimensioniert sind. Wenn bei einem CCR-Cluster über eine WAN-Leitung vielleicht 10 Megabit/Sek in den Backupstandort repliziert werden, so müssen nach einem Failover nicht nur die Rückreplikation durch die Leitung, sondern auch alle Zugriffe der Anwender müssen eventuell ebenfalls durch dieses Nadelöhr.

Muss der ausgefallene Server sogar komplett neu aufgebaut werden, dann steht noch einmal die Replikation der kompletten Datenbank (Seeding) über die Leitung an. Eine gute Planung mit dem Durchspielen der verschiedenen Szenarien ist erforderlich.

3rd Party Produkte

Dritthersteller haben natürlich diese "Lücke" auch gesehen und sind mit entsprechenden Produkten am Markt, die eine höhere Verfügbarkeit eines Exchange Servers versprechend ohne dass Sie dazu besondere Hardware (z.B. SAN Speicher mit Replikation) oder Microsoft Cluster Services benötigen.

Ich möchte hier jedoch keine Empfehlung für oder Kritik an einem speziellen Produkt aussprechen. Dazu habe auch ich nicht den kompletten Marktüberblick. Kontrollieren Sie einfach selbst, ob solche eine Software ihnen die versprochene Verfügbarkeit liefert. Software alleine ist nie die Lösung. Schulung, Hardware und die gesamte Kette aller Komponenten muss passend sein.

Weitere Links