Die Anbieter von Disaster-Recovery-Produkten versprechen Abhilfe für eine ganze Palette von Problemen. Vor allem lässt sich durch eine Replikation von kritischen Daten auf ein Reserve-System die Datenverfügbarkeit deutlich erhöhen. Insbesondere File-Server, aber auch Datenbank- und Mail-Systeme profitieren dabei von verkürzten Wiederherstellungszeiten. Bei einem Totalausfall des primären Servers übernimmt idealerweise ein Reservesystem die Dienste des ausgefallenen Rechners und stellt dessen Applikationen innerhalb kürzester Zeit wieder zur Verfügung.
RepliStor, ursprünglich unter dem Namen Octopus entwickelt, war eines der ersten Replikationstools für Windows überhaupt und stand bereits vor mehr als 10 Jahren für frühe Versionen von Windows NT zur Verfügung. Am Grundkonzept des Produktes hat sich im Laufe der Jahre nicht allzuviel verändert. RepliStor erlaubt Systemverwaltern, beliebige Dateien und Verzeichnisse, aber auch Verzeichnisfreigaben und Registry-Einträge eines Windows-Quellsystems auf eines oder mehrere andere Zielsysteme zu spiegeln und für Redundanz im Desasterfall zu sorgen. Derzeit werden Windows XP, 2000 und 2003 Server unterstützt. In weiten Teilen sind die Funktionen des Produktes über die Betriebssysteme identisch. Lediglich unter Windows 2003 Server kann der Systemverwalter zusätzlich die Volume Shadow Copy Services (VSS) des Betriebssystems nutzen, um konsistente Kopien der Daten eines Volumes anzufertigen. Diese Schattenkopien können bei Bedarf gemountet werden, um die Wiederherstellung eines konsistenten Datenbestandes zu ermöglichen.
Zusätzlich zur reinen Datenspiegelung kann der Systemverwalter RepliStor so konfigurieren, dass beim Ausfall des aktiven Systems ein Spiegelserver den Netzwerknamen des ausgefallenen Knotens übernimmt sowie ausgewählte Dienste startet. Auf diese Weise stehen sowohl Daten als auch benötigte Applikationen innerhalb weniger Augenblicke wieder für den Zugriff bereit. Auch für bestehende Microsoft-Cluster erlaubt RepliStor die Spiegelung von Daten aus der bestehenden Konfiguration heraus auf ein separates Plattensubsystem beziehungsweise einen zweiten Cluster.
Die Replikation geschieht über sogenannte «Specifications». Diese legen die Quell- und Zielverzeichnisse mit den entsprechenden Übertragungsparametern fest. Sobald sich eine Änderung an einer Datei ergeben hat, schreibt RepliStor eine Kopie davon in ein Log-File. Anschliessend übermittelt das Tool den Inhalt des Sende-Logs an das Zielsystem. Insbesondere für Replikation von Datenbanken ist dieses Verhalten zu beachten, denn die Zwischenspeicherung kann unter Umständen dazu führen, dass das Zielsystem über einen inkonsistenten und somit unbrauchbaren Datenbestand verfügt. Alternativ kann die Replikation auch grundsätzlich zeitgesteuert in bestimmten Intervallen erfolgen. Die Datenspiegelung funktioniert in jede mögliche Richtung, das heisst, es werden One-to-One-, One-to-Many-, Many-to-One- und Many-to-Many-Konfigurationen unterstützt. Um das Produktivnetz zu entlasten, bietet RepliStor zudem die Option, die Bandbreitennutzung einzuschränken.
Im Praxistest fiel zunächst die recht einfache und problemlose Installation von RepliStor auf, die lediglich ein kurzes Handbuchstudium erforderte. Um die Funktionsweise von RepliStor zu verifizieren, wurde auf dem Quellserver eine Verzeichnisstruktur mit Berechtigungsstrukturen bestehend aus lokalen Gruppen angelegt. Im nächsten Schritt sollten zunächst einzelne Verzeichnisse auf das Zielsystem gespiegelt werden. Die Einrichtung der entsprechenden Spezifikationen bereitete keine nennenswerten Schwierigkeiten, auch wenn die Handhabung der RepliStor-Bedienoberfläche zunächst etwas gewöhnungsbedürftig war. Nach der Initialsynchronisation der Testdaten fiel auf, dass auf dem Zielsystem die Berechtigungen nicht korrekt übernommen worden waren. Abhilfe schaffte die Option, die Berechtigung nicht als Security Identifier (SID), sondern als Name zu replizieren.
Netzwerkunterbrechungen erkannte RepliStor, nahm aber nach der Wiederherstellung der Netzwerkverbindung die Datenübertragung nicht wieder selbsttätig auf. Die Konfiguration der FailoverFunktion bereitete nach kurzer Lektüre der Dokumentation für einfache Szenarien keine nennenswerten Schwierigkeiten. Der Aufwand für komplexe Umgebungen kann allerdings aufgrund der Notwendigkeit für die Programmierung von Skripten recht hoch werden.
Ähnlich wie RepliStor ist auch Double-Take des US-Herstellers NSI ein Produkt, das auf eine lange Vergangenheit zurückblicken kann. Auch vom Grundkonzept ähneln sich beide Mitbewerber. Double-Take, das unter den jeweiligen Serverversionen von Windows NT/2000 und 2003 lauffähig ist, führt eine Datenreplikation zwischen einem Quell- und einem Zielsystem durch. Bei Bedarf kann zudem ein Failover der IP-Adresse sowie der Dienste eines ausgefallenen Servers auf dem Zielsystem konfiguriert werden. NSI hat für diesen Fall eine ganze Reihe von Failover-Szenarien mit umfangreichen Dokumentationen und, soweit erforderlich, Zusatztools entwickelt, die der Systemverwalter kostenlos über das Internet beziehen und einsetzen kann. Abgedeckt sind dabei beispielsweise Konfigurationen für Microsoft Exchange, SQL Server und SharePoint Portal Server, aber auch Oracle-Datenbanken und Lotus Notes. Die Microsoft Volume Shadow Copy Services unterstützt Double-Take derzeit nicht.
Die Replikations- und FailoverMechanismen stellt Double-Take nicht nur in einer direkten One-to-One-Konfiguration zur Verfügung, sondern auch in beliebig komplexen One-to-Many-, Many-to-One- und Many-to-Many-Konstellationen. Neben einer asynchronen Quasi-Echtzeit-Replikation kann Double-Take auch so konfiguriert werden, dass es Datenänderungen über einen längeren Zeitraum zwischenspeichert und diese erst zu bestimmten vom Administrator konfigurierbaren Intervallen überträgt. Um konsistente Backups auf dem Zielsystem zu ermöglichen, kann sich der Systemverwalter sogenannter In-Band-Commands bedienen. Diese Kommandos lassen sich quasi in den Datenstrom einfügen und können unter anderem dafür sorgen, dass auf dem Zielsystem ein Backup gestartet wird, sobald der Datenbestand dort konsistent ist.
Um die zur Verfügung stehende Bandbreite bei der Replikation nicht über Gebühr zu belasten, hat NSI verschiedene Funktionen implementiert. Zunächst einmal überträgt Double-Take nach einer Initial-Datenspiegelung nur noch geänderte Datenblöcke. Zusätzlich kann der Systemverwalter verschiedene Kompressionsstufen wählen. Schliesslich steht noch eine Bandbreitenbegrenzung zu Verfügung.
Die Daten werden in jedem Fall vor Übertragung vom Quellsystem gepuffert, damit auch bei der Unterbrechung der Netzwerkverbindung sichergestellt ist, dass die veränderten Daten zu einem späteren Zeitpunkt auf dem Zielsystem nachgeführt werden können und so die Datenkonsistenz sichergestellt ist. Problematisch wird es jedoch unter Umständen, wenn ein Failover stattfindet, während der Datenbestand auf dem Zielsystem inkonsistent ist. Insbesondere Datenbanken reagieren hierauf empfindlich.
Installation und Grundkonfiguration von Double-Take stellen den Systemverwalter vor keine allzugrosse Herausforderung. Nicht einmal ein Handbuchstudium war nötig, um ein Replication Set einzurichten, das die Daten eines zuvor angelegten Verzeichnisses vom Quell- zum Zielserver transferiert. Probleme hatte Double-Take allerdings zunächst bei der Replikation von Verzeichnisberechtigungen, die über lokale Gruppen vergeben waren. Erst als die Option «Replicate NT Security by Name» aktiviert wurde, klappte die Replikation der Berechtigungsstruktur. Etwas mehr Mühe bereitete die Einrichtung einer Failover-Konfiguration. Hierbei sind doch einige, im Handbuch allerdings recht gut beschriebene Schritte notwendig, um ein zuverlässiges Umschalten auf das Reservesystem zu ermöglichen. Positiv fiel auf, dass sich die Failover-Konfiguration aufgrund der Einbindung von Scripts sehr flexibel, aber auch komplex gestaltete. Vermisst haben wir eine Funktion zur Replikation von Registry-Einträgen, die für einen Failover von Applikationen häufig eine wichtige Rolle spielen.
Symantec bietet mit dem von Veritas übernommenen Replication Exec eine Lösung, die weniger Funktionen aufweist als die meisten Mitbewerber, dafür aber auch deutlich weniger Kosten verursacht. Das Symantec-Produkt beherrscht ebenso wie RepliStor oder Double-Take ausschliesslich eine asynchrone Datenreplikation und läuft unter Windows XP, Windows 2000/2003 und Windows Storage Server. Die Replikation kann entweder mit kurzem Zeitversatz unmittelbar im Anschluss an eine Schreiboperation erfolgen oder in vom Systemverwalter festgelegten Intervallen. Dabei bedient sich Replication Exec eines Zwischenspeichers, um die zu übertragenden Daten zu puffern und dann vom Quell- auf das Zielsystem zu übertragen. Aufgrund der konzeptionellen Ähnlichkeiten zu den Mitbewerberprodukten von EMC und NSI, hat natürlich Replication Exec auch in Sachen Datenkonsistenz mit vergleichbaren Herausforderungen zu kämpfen. Um die Netzwerkbandbreite nicht über Gebühr zu belasten, kann der Systemverwalter für jeden Job eine Begrenzung konfigurieren. Im Gegensatz zu den anderen Herstellern in diesem Test kann Symantec nicht mit einer eigenen FailoverFunktion aufwarten. Das Produkt unterstützt allerdings sowohl Microsoft- als auch Veritas-Cluster-Installationen und kann bei Bedarf mit diesen kombiniert werden.
Was die Replikationsarchitektur anbelangt, so unterstützt Replication Exec sämtliche Varianten, das heisst One-to-One, One-to-Many, Many-to-Many und Many-to-One. Das Produkt kann sowohl über eine grafische Bedienoberfläche als auch über ein Command Line Interface bedient werden. Vor allem beim Reporting und Melden von Fehlerzuständen bietet die grafische Oberfläche nur eingeschränkte Möglichkeiten. Auch eine VSS-Unterstützung, die in der Lage wäre, Daten in einem konsistenten Zustand zu replizieren, sucht man vergebens.
Im Test überzeugte Replication Exec zunächst durch seine ebenso einfache wie schnelle Installation. Von Vorteil war zudem, dass sich das Produkt von der Administrations-Konsole des ersten Servers aus auch auf dem zweiten System installieren liess. Anhand der übersichtlichen und einfach gestalteten Benutzeroberfläche bereitete auch die Konfiguration von Replikationsjobs keine Probleme. Ein Assistent fragte alle notwendigen Parameter ab, und innerhalb kürzester Zeit wurde das erste Testverzeichnis vom Quell- auf das Zielsystem übertragen. Dabei überzeugte die Fähigkeit des Programms, lokale Berechtigungsgruppen mit zu übernehmen. Einzige Voraussetzung hierfür war das Vorhandensein identischer Gruppennamen auf dem Quell- und dem Zielsystem.
Auch kurzfristige Aussetzer der Netzwerkverbindung zwischen Quell- und Zielserver verkraftete Replication Exec klaglos. Verbesserungspotential zeigte sich aber im Bereich des Monitorings. Über die Admin-Konsole war es möglich, den Status abzufragen, etwaige Probleme sowie Fehlerursachen zeigten sich jedoch bestenfalls im Log-File, das Replication Exec für jeden Job anlegt.
Einen gänzlich anderen Weg als die Mitbewerber dieses Tests beschreitet US-Hersteller Marathon Technologies mit seiner EverRun HA-Lösung. Diese bedient sich eines Virtualisierungsansatzes, um die Verfügbarkeit von Daten und Applikationen sicherzustellen. Als Basis fungieren zwei Intel-Server mit Windows 2003 Server als Basisbetriebssystem. Über einen «Redirector» klinkt sich EverRun in das Basisbetriebssystem ein und stellt dessen Ressourcen in Form von CPU, Hauptspeicher, Netzwerkkarten, Plattenplatz und sonstigen Laufwerken einer virtuellen Serverinstanz, dem Virtual Application Environment, zur Verfügung. Innerhalb dieser virtuellen Umgebung läuft wiederum eine eigene Kopie von Windows 2003 Server, die zwar Ressourcen des darunter liegenden Betriebssystems nutzt, aber unabhängig von diesem agiert. Die zu schützende Applikation wird ebenfalls innerhalb der virtuellen Serverinstanz installiert. Fällt eine Hardwarekomponente eines physikalischen Servers aus, übernimmt die entsprechende Komponente des zweiten Servers deren Aufgabe. Auf diese Weise kann jeglicher Single-Point-of-Failure eliminiert werden. Das Virtual Application Environment arbeitet selbst dann noch weiter, wenn auf beiden physikalischen Systemen gleichzeitig wichtige Komponenten ausfallen. Voraussetzung hierfür ist, dass die beiden physikalischen Server über zwei dedizierte Gigabit-Ethernet-Verbindungen miteinander gekoppelt sind. Mit Hilfe dieser Verbindungen formt EverRun HA aus den beiden physikalischen Servern eine fehlertolerante virtuelle Hardware.
Trotz aller Redundanz ist jedoch eines zu bedenken: Bei EverRun HA wird das Virtual Application Environment nur auf einem physikalischen Server ausgeführt. Fällt dieser aus, fällt auch der virtuelle Server zunächst aus. Er wird jedoch vom Standby-System innerhalb weniger Augenblicke neu gestartet und steht dann wieder zur Verfügung. Für Wartungszwecke kann das Virtual Application Environment aber auch im laufenden Betrieb vom aktiven Server auf das Standby-System verschoben werden. Über die beiden Gigabit-Ethernet-Verbindungen überträgt EverRun HA dann sämtliche Inhalte des Hauptspeichers und der CPU auf das Standby-System und führt so eine Online-Migration durch. Die Benutzer können während dieser Zeit mit dem virtuellen System weiterarbeiten und bemerken nichts von diesem Vorgang.
Dieser Ansatz bietet eine Reihe weiterer Vorteile. So müssen Applikationen nicht mehr explizit für einen Cluster-Betrieb geeignet sein oder mit Hilfe von Scripts und Programmen Cluster-tauglich gemacht werden. Die Applikation kann wie auf einem herkömmlichen Einzelsystem betrieben werden und ist trotzdem sofort hochverfügbar. Durch die Kopplung von zwei physikalischen Servern und der damit verbundenen Redundanz treten auch keine Probleme mit inkonsistenten Datenbeständen auf. Alle Schreiboperationen erfolgen stets synchron. Damit ist sichergestellt, dass auf jedem Server jederzeit dieselben Daten vorhanden sind.
EverRun HA hat aber auch ein paar Nachteile. So kann die Distanz zwischen den beiden physikalischen Servern nicht beliebig gross werden. In der Regel wird die Lösung auf Campusumgebungen mit Distanzen bis 10 Kilometer beschränkt sein. Eine asynchrone Datenreplikation über grössere Distanzen ist nicht möglich. Weiterhin kann Marathon EverRun HA nur in Verbindung mit einem englischprachigen Windows 2003 eingesetzt werden. Zudem hat Marathon recht hohe Anforderungen an die Hardware. So setzt der Hersteller mindestens eine 2,4-GHz-Pentium-4-CPU mit Hyperthreading und ein Gigabyte Hauptspeicher voraus. Zudem werden vier Netzwerkanschlüsse je Server empfohlen, wobei zwei in Gigabit-Ethernet-Technologie ausgeführt sein müssen.
Wenn alle Hardwarevoraussetzungen erfüllt sind, bereiten Installation und Konfiguration von EverRun HA keine nennenswerten Schwierigkeiten. Auffallend war, dass die Lösung trotz ihrer Komplexität über eine klar gegliederte Benutzeroberfläche einfach zu bedienen war. Alle wichtigen Betriebsstati liessen sich auf einen Blick erkennen. Das Virtual Application Environment verhielt sich gegenüber Applikationen genau wie ein physikalischer Server. Testweise provozierte Ausfälle einzelner Hardwarekomponenten auf beiden physikalischen Servern zeigten keine Auswirkungen auf die Verfügbarkeit. Erst ein Ausschalten des aktiven Servers verursachte einen kurzen Unterbruch, bis das Virtual Application Environment auf dem Standby-System neu gestartet war.
Disaster-Recovery-Tools im Überblick
Dipl.-Ing. Dirk Pelzer ist Mitglied im Bundesverband Deutscher Sachverständiger und Fachgutachter und arbeitet als Consultant und Journalist.
(dirk.pelzer@pelzer-consulting.de).
