Mit der Softwarelösung "Double Take" des gleichnamigen Herstellers lassen sich vergleichsweise einfach hochverfügbare Windows-Umgebungen aufbauen. Das Werkzeug repliziert die Daten vom Quell-Server über eine IP-Verbindung auf das Zielsystem. Es ist auch möglich, mehrere Quellsysteme auf denselben Ziel-Server zu replizieren. Dies hält die Kosten für die benötigte Hardware niedrig. Double Take kann die Daten zudem vom Ursprungssystem auf mehrere Ziel-Server vervielfältigen, was zum Beispiel für Testzwecke oder für die Offline-Datensicherung nützlich ist.

Wenn Microsoft-Exchange- oder -SQL-Server repliziert werden, sollte auf dem Zielsystem die E-Mail- oder Datenbanksoftware in derselben Version installiert sein wie auf dem Quell-Server. Denn nur dann kann Double Take beim Ausfall des primären Systems einen Failover auf den Replica-Server vornehmen.

Testnetz mit File-, Exchange- und SQL-Servern

Für den computerwoche-Test wurde ein Windows-Netzwerk aus einem Domänen-Controller und jeweils zwei File-, Exchange-2003- und SQL-2005-Servern aufgebaut. Auf allen Maschinen lief Windows Server 2003 als Betriebssystem. Auf einem Windows-XP-Rechner wurde der "Double Take Application Manager" installiert. Mit diesem Tool lassen sich Replikation und Fail-over für File-, Exchange- und SQL-Server von einer zentralen Konsole aus konfigurieren und überwachen.

Eine Variante schützt VMware und die Virtual Infrastructure

Der Hersteller bietet weitere Module an, die in diesem Test nicht berücksichtigt werden konnten. Hierzu zählen Versionen für den Windows Storage Server 2003 und den Small Business Server (SBS), eine Geo-Cluster-Ausführung für die Überbrückung sehr großer Entfernungen, eine Server Recovery Option zur vollständigen Wiederherstellung von Windows-Servern, eine Variante für den Schutz von virtuellen VMware-Servern sowie ein Tool zur Sicherung kompletter Virtual-Infrastructure-Umgebungen (VMware VI3).

Damit ein Server Daten zu einem anderen Rechner replizieren kann, muss die Double-Take-Software auf beiden Systemen installiert sein. Beim Setup kann der Administrator wählen, ob nur die Server-Komponenten oder auch der Client für die Verwaltung von Replikation und Fail-over eingerichtet werden. Er entscheidet auch, wie viel Arbeits- und Festplattenspeicher das Programm maximal für das Zwischenspeichern der zu replizierenden Daten nutzen darf. Standardmäßig verwendet das Tool den gesamten vorhandenen freien Plattenplatz, lässt aber mindestens 50 MB frei. Im Test wurde die für die Replikation nutzbare Speicherkapazität auf 10 GB begrenzt und die Minimalgrenze von 50 MB auf 100 MB erhöht. Wenn eine Datei verändert wurde, kann Double Take sie entweder komplett zur Replica übertragen oder nur die geänderten Bytes. Letzteres ist in der Regel die bessere Methode, da sich das zu übertragende Datenvolumen reduziert.

Zuverlässige Erkennung vorhandener Server

Die Basisinstallation des Tools war nach wenigen Minuten abgeschlossen. Nun ging es daran, die gewünschten Replikationen und Failover-Szenarien einzurichten. Mit Hilfe der Auto-Discovery-Funktion erkannte Double-Take im Test alle neu hinzugekommenen Server auf Anhieb. Die Konfiguration der Replikations- und Failover-Settings lässt sich entweder mit den klassischen Werkzeugen Management-Konsole und Failover Control Center oder mit dem Application Manager vornehmen. Letzterer liefert insbesondere für den Schutz von Exchange- und SQL-Servern nützliche Hilfestellungen. Für den Test wurde jeweils eine Eins-zu-Eins-Replikation zwischen den beiden File-, Exchange- und SQL-Servern eingerichtet, wobei die File-Server mit der Management-Konsole und die Anwendungs-Server mit dem Application Manager konfiguriert wurden.

Teil der Management-Konsole ist ein Assistent, der den Administrator dabei unterstützt, das Programm einzurichten. Als Erstes wählt er das Quell- und das Zielsystem aus. Dabei legt er unter anderem fest, ob die initiale Spiegelung aller Quelldaten sowie die Replikation der Änderungen sofort oder zu einem späteren Zeitpunkt beginnen sollen. Bei den Spiegelungsoptionen kann er darüber hinaus einstellen, ob alle Dateien zum Ziel übertragen werden sollen, oder nur diejenigen, die noch nicht vorhanden sind, oder alle Dateien, die einen anderen Zeitstempel beziehungsweise eine andere Größe aufweisen.

Beschränkte Bandbreite für WAN-Replikation

Der Administrator kann die von Double Take verwendete Bandbreite begrenzen. Dies ist insbesondere hilfreich, wenn die IP-Replikation über eine schmalbandige Weitverkehrsverbindung erfolgt. Die Menge der übertragenen Daten lässt sich mit Hilfe einer integrierten Kompression reduzieren. Allerdings kostet dies einiges an CPU-Ressourcen und sollte deshalb mit Bedacht eingesetzt werden.

Die Software ist in der Lage, Daten entweder nahezu in Echtzeit oder nur zu bestimmten Zeiten zu replizieren. Die "Transmission Limits" erlauben eine fein abgestufte Zeitsteuerung. Mit dieser Funktion kann der Administrator die Datenreplikation nur zu den gewünschten Zeitpunkten oder in regelmäßigen Intervallen ausführen lassen. Des Weiteren lässt sich festlegen, dass der Abgleich immer dann erfolgt, wenn die Warteschlange auf dem primären System einen bestimmten Schwellwert überschritten hat.

Zeitgesteuerte Snapshots als zusätzliche Absicherung

Durch regelmäßige Snapshots der Daten auf dem Zielsystem, zum Beispiel im Stundenrhythmus, kann der Administrator sicherstellen, dass immer ein (älterer) konsistenter Datenbestand vorhanden ist. Ob die replizierten Daten auf dem Zielsystem unbeschädigt angekommen sind, lässt sich mittels einer Check-Summenprüfung verifizieren. Orphan Files, bei denen das replizierte Gegenstück nicht mehr vorhanden ist, kann der Administrator von Double Take löschen oder in ein Resteverzeichnis verschieben lassen.

Um den Überblick nicht zu verlieren, empfiehlt es sich, gleichartige Server zu Gruppen zu sortieren, zum Beispiel jeweils die File-, SQL- und Exchange-Server. Die Server lassen sich anschließend bequem per Drag and Drop der passenden Gruppe zuordnen. Zusätzlich zu den grafischen Oberflächen stellt Double Take mit dem "Text Client" ein textbasierendes sowie ein Kommandozeilen-Werkzeug zur Verfügung.

Transparente Übernahme nach einem Server-Crash

Die Hochverfügbarkeitsfunk-tionen aktiviert der Administrator entweder im Failover Control Center oder über den Application Manager. Für die beiden File-Server wurde hierfür das Failover Control Center verwendet. Ein Ausklappmenü listet die für einen Failover verfügbaren Ziel-Server auf. Nachdem hier der zweite File-Server gewählt worden war, ging es daran, die Fail-over-Settings zu konfigurieren.

Fällt ein Server aus, kann das Programm den Replica-Server automatisch so umkonfigurieren, dass er den DNS-Namen, die IP-Adresse und die Verzeichnisfreigaben des ausgefallenen Systems übernimmt und über das Netzwerk zur Verfügung stellt. Deshalb greifen die Anwender mit der bisherigen IP-Adresse und den alten Share- und Server-Namen weiterhin auf die Ressourcen des ausgefallenen Systems zu. Im Test klappte diese Übergabe reibungslos: Der primäre File-Server wurde hart ausgeschaltet, und bereits nach wenigen Sekunden war der Zugriff auf die Shares des ausgefallenen Servers über das Netzwerk mit den alten Pfadangaben wieder möglich.

Nützliches Tool für Exchange- und SQL-Server

Um die Replikation und die Fail-over-Einstellungen für die beiden Exchange- und SQL-Server zu konfigurieren, kam der Application Manager von Double Take zum Einsatz. Dieses Tool bietet eine hilfreiche Validierungsfunktion mit integrierter Reparaturoption. Mit der getesteten Ver-sion 4.2 ist es nun auch mög-lich, SQL-Server zu schützen, die sich in einer Workgroup befinden. Zuvor muss der Anwender von der Website des Herstellers die Komponente "SQLDMO" herunterladen und installieren. Wenn Cluster-Systeme geschützt werden sollen, ist zudem das "Microsoft Admin Pack" erforderlich.

Der Administrator wählt im Application Manager aus, ob er einen Exchange-, SQL- oder File-Server schützen möchte. Dann gibt er das gewünschte Quell- und Zielsystem an und legt fest, ob das Standby-System die replizierten Ressourcen nach einem Ausfall unter dem Namen und der IP-Adresse des primären Servers online bringen soll. Das Tool kann auch überprüfen, ob die Replikation korrekt konfiguriert wurde und zum Beispiel alle für eine erfolgreiche Replikation erforderlichen Dateien und Dienste auf dem Zielsystem vorhanden sind.

Beim Aufsetzen der Replikation zwischen den beiden Exchange-Servern stellte das Werkzeug fest, dass die Exchange-Services auf dem Zielsystem bereits gestartet und auf "automatisch" eingestellt waren. Damit der Failover funktioniert, müssen diese Dienste aber auf "manuell" stehen und gestoppt sein. Durch einen Mausklick auf die Schaltfläche "Fix All" passte der Application Manager alle Einstellungen so an, dass Replikation und Failover korrekt eingerichtet wurden.

Zügiger Exchange- und SQL-Failover

Um den Exchange-Failover zu testen, wurde der primäre Exchange-Server vom Netzwerk getrennt. Das Standby-System hatte innerhalb von etwa zwei Minuten die Exchange-Services gestartet und alle Funktionen des ausgefallenen Servers übernommen. Die Testbenutzer erhielten eine Warnmeldung, dass sie das E-Mail-Programm von Microsoft neu starten mussten, um normal weiterarbeiten zu können. Nach dem Neustart des Outlook-Clients konnten sie wie gewohnt auf ihre Postfächer zugreifen sowie E-Mails versenden und empfangen. Das Standby-System hat den Namen und die IP-Adresse des ausgefallenen Exchange-Servers übernommen und verhielt sich nach außen wie dieser Server. Nach dem Failback auf den primären Server erschien derselbe Warnhinweis, und nach dem Schließen und neu Öffnen von Outlook standen alle Messaging-Funktionen wieder über das primäre System zur Verfügung. Der Failover des SQL-Servers verlief ebenfalls zügig. Nach etwa einer Minute war der Zugriff auf die Datenbank über das Ersatzsystem möglich.

Wenn bei einer Replikation oder einem Failover Fehler auftreten, meldet Double Take diese an das "Application Log" von Windows. Dadurch lassen sich die Verfügbarkeit der Systeme und der Schutz der Daten mit gängigen Monitoring-Tools überwachen. (kk)