Standby Lösungen

Auch wenn Sie sehr viele Dienste von Exchange und rund um Exchange allein durch die mehrfache Installation schon höher verfügbar machen können, so bleibt ein Punkt weiterhin vorhanden: Der Postfachspeicher.

Es ist mit Mitteln von Exchange und Windows nicht möglich die Inhalte von Postfächern auf andere Server zu replizieren. Damit bleibt der Postfachserver ein "Single Point of Failure", oder anders ausgedrückt: Wenn der Postfachspeicher weg ist, ist der Notfall eingetreten.

Zwar entspannt heute der Outlook 2003 Cached Mode die Situation derart, dass die Anwender dann trotzdem noch auf ihre Informationen zugreifen können aber es werden leider keine Nachrichten mehr übermittelt.

Um nun die Zeit zwischen dem Ausfall und der Wiederherstellung der Funktion zu minimieren gibt es zwischen den beiden Extremen "Neuaufbau" und "Wiederherstellung" weitere Ansätze, die eine schnellere Verfügbarkeit versprechen. Defekte in der Datenbank können aber diese Lösungen ebenso wenig lösen, wie ein Cluster.

Die Ideen

Wenn man weiß, wie Exchange "tickt", dann sind Zwischenlösungen zwischen einem "Exchange Single Server" und einem "Exchange Cluster" denkbar.

Datenbank an Notfallserver

So ist es relativ einfach, eine Exchange Datenbank auf einem anderen Server wieder zu betreiben, selbst wenn dieser anders heißt. Mit geeigneter Hardware, SAN oder NAS, oder physikalisches umhängen von externen Subsystemen kann der Ausfall eines Servers demnach sehr schnell manuell überbrückt werden. Sofern ein Administrator vor Ort ist und es entsprechende Notfalldokumentationen und Ersatzteile gibt, ist der Ausfall eines Servers im Bezug auf Hardware sehr schnell wieder repariert.

Daten und Serverreplikation

Wenn nun aber die Datenbank lokal auf dem ausgefallenen Server liegt, dann kommt ein anderer Ansatz zum tragen. So ist es denkbar, die komplette Festplatte über Zusatzprogramme oder notfalls auch mit einem einem Software RAID und z.B.: iSCSI auf ein anderes System zu kopieren. Fällt nun der Hauptserver aus, könnte (entsprechende HAL vorausgesetzt) dieser Ersatzserver, der bisher als "Festplattensystem" dient, einfach durchgestartet werden und wäre faktisch der Gleiche. Das gleiche System könnte natürlich auch einfach nur "virtuell" vorhanden sind (VMware etc.).

Andere Lösungen verfeinern diesen Ansatz dadurch, dass Sie automatische Überwachungen und auch umschaltungen einbauen, das Betriebssystem komplett spiegeln oder sogar den zweiten Server "online" lassen. Ein Treiber auf der Netzwerkarte verhindert, dass der Server im LAN aktiv wird, d.h. er steht fast komplett fertig da und wartet nur darauf, im Falle eines Defekts der Hauptmaschine die Blockade auf der Netzwerkkarte zu entfernen und die Exchange Datenbanken zu starten.

EMC Replistor hingegen nutzt einen Ansatz, bei dem auf beiden Server ein vollwertiger Exchange Server installiert wird und ein Server davon passiv ist, d.h. die Dienste sind gestoppt. Die Datenbanken werden über einen Filtertreiber auf den zweiten Server repliziert. Fällt der produktive Server aus, dann starten auf dem neuen Server einfach die Dienste mit den Datenbanken. Damit die Clients den neuen Server nutzen, werden bei den Benutzern einfach die Attribute für den Homeserver und die Datenbank geändert.

Keine Empfehlung
Leider kann ich keine Produktempfehlung aussprechen, da auch hier die Entwicklung sehr rasant verläuft und eine neutrale Übersicht nicht möglich ist.

Produkte

Diverse kommerzielle Produkte versprechen eine Mittellösung zwischen Cluster und Einzelsystem, in dem sie die Datenzugriffe "spiegeln" und beim Ausfall den zweiten Server mit der Konfiguration des ersten Servers starten. Dies ist kein Cluster nach dem Verständnis von Microsoft aber ein mehr oder minder automatisches Failover bei einem Hardwaredefekt. Produkte hierzu sind:

• 895847 Multi-site data replication support für Exchange 2003 and Exchange 2000
• DoubleTake
  http://www.nsisoftware.com
  http://www.nsisoftware.com/pro/doubletake
  WhitePapers http://www.nsisoftware.com/sup/dtappnotes.asp
  Doubletake basiert primär auf der Replikation von Dateien eines Servers auf den zweiten Server über einen Filtertreiber, der blockweise die Daten auf das Ziel kopiert und im Falle eines Ausfalls auch wieder zurückkopieren kann. Um den zweiten Server als "Ersatz"-Server zu starten, sind aber mehr Schritte erforderlich. So muss der zweite Server ebenfalls Exchange installiert haben und die Datenbanken sind gestoppt. Ein Failover bedeutet, dass die replizierten Datenbanken auf dem Zielsystem "online" geschaltet werden und ein Prozess die Felder bei den betroffenen Benutzern (HomeMTA, HomeMDB etc.) ändert. (Siehe auch EMC Replistor)
• EMC Replistor, ehemals Legato StandBy Server (Ehemals Vinca StandBy Server)
  EMC Replistor
  http://www.legato.com/products/costandbyserver
• neverfail heartbeat für exchange
  http://www.neverfailgroup.com/products/nfexchange.asp
  Nutzt zwei identische Server mit gleichem Namen. Der zweite Server wird mit NTBACKUP restauriert und ein Filtertreiber verhindert dessen Erscheinen auf dem LAN. Fällt der erste Server auf, übernimmt der zweite Server
• SteelEye's LifeKeeper (ehemals NCR)
  http://www.steeleye.com
• BrightStor High-Availability Manager
  Web: http://www.ca.com
• Legato Octopus für Windows NT and 2000 4.2
  http://www.legato.com/products/replistor
• VERITAS Cluster Server 2.0 für Windows 2000
  http://www.veritas.com
• Software für Hardwarefailover
  http://www.legato.com/products/costandbyserver
• www.stratus.com
  Besondere Hardware, die eine hohe Verfügbarkeit gewährleisten soll.
• WANSync für Exchange Replication and Exchange Disaster Recovery
  http://www.xosoft.com/products/f_WANSyncExchange.shtml
  Mittlerweile von CA gekauft. www.ca.com/de
• www.marathontechnologies.com
  Marathon baut mit 4 Servern einen virtuellen synchronen Server ohne Ausfall auf. Sehr interessant, da es keinen Single Store gibt, sondern ähnlich NetWare SFTIII eine Trennung von I/O und Verarbeitung besteht und eine Komponente den Abgleich der Daten und Verarbeitung kontrolliert.
  Aktuell reichen dazu auch zwei Systeme ohne proprietäre Karten um bis zu  99.999% uptime zu erreichen.
• SonaSoft
  http://www.sonasoft.com/products/exchange.asp
  Produkt repliziert Postfachinhalte per MAPI in PST-Dateien, welche dann auf einem Recovery Server (eigener Forest, gleicher Organisationsname etc.) wieder eingespielt werden. Regelmäßige "Updates" der Quelle zum Ziel versprechen einen aktuellen Datenbestand, der für Wiederherstellungen (Mails per Exmerge kopieren, Datenbank komplett kopieren) zur Verfügung steht. Mich irritiert, dass in den Whitepapers das Wort "Backup" verwendet wird, obwohl es ein MAPI Export ist und die Quelldatenbank nicht wirklich nach Exchange Standards gesichert wird, d.h. es findet keine ESE-Prüfung und keine Transaktionsprotokollverarbeitung statt.

Zumindest wenn man den Herstellern glauben darf, sollen hiermit mit Standard Hardware und wenige Geld eine hohe Verfügbarkeit erreicht werden. Einige basieren auf der Replikation von Inhalten auf Festplatten I/O's, während andere logisch die Daten auf einem zweiten Server kopieren. Im Fehlerfall, den alle Produkte selbst mehr oder weniger intelligent ausfindig machen müssen, werden meist durch Skripte die Kopien gestartet. Einige erlauben dabei auch eine Replikation zwischen unterschiedlicher

Trotzdem bleiben meine Aussagen von Anfangs gültig, dass ein gutes Design und klare Abhängigkeiten ebenfalls die Verfügbarkeit erhöhen und eine zusätzliche Software die Komplexität erhöht und damit auch negativen Einfluss auf die Zuverlässigkeit hat. Schöpfen Sie daher erst alle anderen "Standardmittel" aus, um Fehler und Ausfälle zu reduzieren, ehe Sie Geld für kleine oder große Clusterlösungen investieren.