Vier Failover-Systeme im Vergleich

28.07.2006
Von 
Dipl. Inform. Johann Baumeister blickt auf über 25 Jahre Erfahrung im Bereich Softwareentwicklung sowie Rollout und Management von Softwaresystemen zurück und ist als Autor für zahlreiche IT-Publikationen tätig. Sie erreichen ihn unter jb@JB4IT.de
Um IT-Dienste verfügbar zu halten, bieten sich unterschiedliche Verfahren an. Die COMPUTERWOCHE untersuchte vier Tools, die Daten und auch Dienste im Störfall auf einen Ersatz-Server übertragen.

Detailliert getestet wurden die Failover-Systeme "Double-Take", "Neverfail Heartbeart", "WANSync" und "Rescudo". Alle vier Tools replizieren die Daten im Störfall auf das Zweitgerät. Die Funktionsfähigkeit des primären Servers wird dabei in der Regel durch "Watchdogs" und Timer überwacht.

Fazit

• Die Failover-Werkzeuge verhielten sich im Test so, wie es die Anbieter beschreiben. Nach dem Entfernen der jeweiligen Primär-Server vom Netz übernahmen die Partnersysteme die aktive Rolle.

• Installation und Betrieb müssen gut geplant werden, stellen dann aber keine besonderen Anforderungen.

• Die Werkzeuge erfüllen ihren Zweck. Wer kein vollwertiges Clustering oder die herkömmliche Datensicherung durch Bänder oder Disk benötigt, findet in diesen Failover-Tools eine schnelle und sinnvolle Möglichkeit, den dauerhaften Betrieb der unterstützten IT-Systeme sicherzustellen.

Pro und Kontra

Double-Take

Breite Applikationsunterstützung.

Kein Vorort-Service/Support nur via E-Mail und Telefon.

Neverfail Heartbeat

Out-of-the-Box-Einsatz/keine Konfiguration, da applikationsspezifisches Setup.

Nur 1:1-Verbindungen möglich.

Rescudo

Für alle Applikationen einsetzbar.

Geringe Replikationsrate führt zu hohem Datenverlust.

WANSync

Kaskadierte Replikationsszenarios realisierbar.

Nur für wenige Applikationen verfügbar.

Die Leistungsmerkmale im Überblick

Produkt Rescudo Notfallserver Double-Take Neverfail Heartbeat 4.6 WANSync

Hersteller NetS GmbH Double Take Software Neverfail Xosoft

Gesamturteil 7,2 (gut) 8,3 (sehr gut) 8,4 (sehr gut) 7,5 (gut)

Architektur:

Verfügbar für die Betriebssysteme Windows 2000, 2003, XP Windows NT 4, 2000, 2003 Windows 2000, 2003 Windows 2000, 2003

Absicherung / Master : Replikat (1:1/1:n/n:1) 1:1; 1:n; n:1 1:1; 1:n; n:1; n:n 1:1 1:1; 1:n; n:1

Abgesicherte Systeme kaskadierbar nein ja demnächst ja

Identische Hardware für nein nein gleich sein müssen: HAL, Anzahl nein Master und Replikat erforderlich NIC's, HDD-Aufteilung

Identische Software identisches OS nicht bei Replikation, nur Betriebssystem mit gleichem nein für Master und Replikat erforderlich ja für Failover Service-Pack und Hotfixes

Applikationsspezifisch nein nein ja ja

Failover mit Replikation der folgenden Dienste:

Dateidienste unter MS-Windows ja, da applikationsunabhängig ja, da applikationsunabhängig FileServer FileServer

SQL Server ja, da applikationsunabhängig ja, da applikationsunabhängig Version 2000, 2005 Version 2000, 2005

Exchange ja, da applikationsunabhängig ja, da applikationsunabhängig Version 2000, 2003 Version 2000, 2003

Weitere ja, da applikationsunabhängig IIS, SharePoint, Blackberry, Oracle, SAP Progress, Oracle, Lotus Domino

Automatischer Failover/manueller Switchover/Switchback nein/ja/ja ja/ja/ja ja/ja/ja ja/ja/ja

Scriptierung möglich beim Failover/Switchover ja ja ja ja

Replikation und Failover über LAN/WAN ja/ja ab August 2006 ja/ja ja/ja ja/ja

Logik zur Erkennung eines Ausfalls des Masters ja, eigene ICMP PING und UDP ICMP PING ICMP PING

Zentrale Management-Konsole für alle Module ja ja ja ja

Integration in System-Mangement-Tools nein geplant: für MOM ab Juni 2006 Email-Versand und Popup BMC Patrol, IBM Tivoli

Preis in Euro:

1 Master/1 Replikat 1980 5990 5545 6000

10 Master/10 Replikate 4990 59 900 55 450 60 000

Service und Support:

Handbuch (Sprache) Deutsch Englisch Englisch Englisch

Software (Sprache) Deutsch / Englisch Englisch Englisch Englisch

Support durch ACP IT Solutions AG Sunbelt Software ProSoft (deutsch) Atemp GmbH

Internet-Adresse www.rescudo.de/ www.sunbelt-software.com/ www.prosoft.de www.xosoft.com

Hotline 0049/80 61-90 89-0 069/95 92 52 46 081 71/40 53 00 0800 verfügbar

*Bewertung: Unter 4,9 nicht akzeptabel; 5,0 bis 5,9 dürftig; 6,0 bis 6,9 befriedigend; 7,0 bis 7,9 gut; 8,0 bis 8,6 sehr gut; 8,7 bis 10 exzellent.

Die Unterschiede

Soweit die Gemeinsamkeiten. Unterschiede weisen die Produkte im Tempo der Replikation sowie im Hinblick auf die Hardware, die Absicherung und die Automatik beim Umschalten auf das Backup-System auf. Während einige Toolsets eine Eins-zu-eins-Abbildung des Primärgeräts verlangen, sind andere flexibler und kommen sogar damit zurecht, dass ein Sicherungs-Server für mehrere Primärgeräte eingesetzt wird. Diese Eins-zu-n-Abbildung spart Hardware- und Lizenzkosten, indem sie die Absicherung mehrerer Server-Systeme erlaubt.

Auch im Hinblick auf die Logik der Datenreplizierung gibt es Unterschiede: Meist klinken sich die Failover-Werkzeuge in das Ein-/Ausgabesystem des Betriebssystems oder der abzusichernden Softwarekomponente ein und greifen neue Schreiboperationen schnell ab. Wie das geschieht, hängt davon ab, ob eine Datenbank, ein Mail- oder ein Dateisystem zu sichern ist. Folglich gibt es Werkzeuge für Microsofts SQL Server, Exchange und das NTFS-Dateisystem von Windows. Die Tools sichern keine Domänen-Controller ab und dürften daher auch nicht direkt darauf ausgeführt werden.

Failover oder Switchover?

Das eigentliche Umschalten im Fehlerfall lässt sich unterschiedlich handhaben. Ein vollautomatisches Failover ohne Zutun des Administrators ist zwar bei allen Tools möglich, wird von den Herstellern aber nur bedingt empfohlen. Das Problem dabei ist die korrekte Erkennung des Fehlerfalls. Hierzu fragt der Replikat-Server regelmäßig seinen Master ab. Ist dieser für einen gewissen Zeitraum nicht erreichbar, wird dies als Indiz dafür gewertet, dass er nicht mehr aktiv am Netz ist. Die Abfrage erfolgt über eine "Heartbeat"-Funktion sowie mit Hilfe von Skripten. Zwar kann der Anwender sowohl das Intervall dieser Abfragen als auch die Zeitdauer, die als Indiz für einen Ausfall gewertet wird, selbst einstellen, dennoch bleibt hier ein Restrisiko: Fällt etwa ein Switch zwischen Erst- und Zweitgerät aus oder ist das Netz temporär überlastet, könnte dies bereits einen Failover auslösen. Für definitive Aussagen ist eine eigene Programmierung unerlässlich.

Jedes Umschalten, ob manuell oder automatisch, führt zu Unterbrechungen und mitunter auch zu geringfügigen Datenverlusten. Zudem ist, sofern der Replikat-Server fortan nicht dauerhaft als Master weiterbetrieben wird, eine Rückübertragung zum wieder funktionierenden Primärgerät erforderlich. Die Entscheidung zwischen automatischem Failover oder manuellem Switchover lässt sich demnach nicht generell, sondern nur nach der jeweiligen Umgebung treffen. Bei relativ einfachen Dateireplikationen mit geringer Änderungsrate und abgegrenzten Dateneinheiten wie Texten und Mail-Einträgen können vollautomatische Mechanismen taugen. Geht es jedoch darum, Datenbanken zu replizieren, die eine Vielzahl offener Benutzer-Sessions aufweisen und deren referentielle Integrität durch Log-Einträge abgesichert werden muss, darf nicht irrtümlich ein Failover initiiert werden. Zudem nimmt mitunter das Replikat die Identität (Computername, Host-Name, IP-Adresse) des Masters an, was - sollte dieser wieder aktiv werden - fatale Konsequenzen hätte.

Die Testumgebung

Double-Take, Neverfail Heartbeat und WANSync sind in Aufbau und Funktion vergleichbar: Sie replizieren die Daten vom Primärsystem schnell auf das Zweitgerät und klinken sich hierzu tief in die Betriebssystemfunktion ein. Dafür sind diese Produkte eng mit der abzusichernden Applikation verbunden. Rescudo vollzieht die Replikation erst mit mehreren Stunden Verzögerung, ist dafür aber auch unabhängig von der Anwendung.

Aus Gründen der Vergleichbarkeit wurden die ersten drei Produkte in ihrer Basisversion, der Absicherung von Dateien im Dateisystem, betrachtet. Rescudo wurde in Verbindung mit MS Exchange getestet. Als Betriebssystem diente Windows Server 2003 - teilweise virtuell sowie als physische Implementierung.

Double-Take von Sunbelt Software ist auf dem Active/Passive-Prinzip aufgebaut, wobei die Daten permanent abgeglichen werden. Es benötigt keine Eins-zu-eins-Struktur zwischen Quelle und Ziel, sondern erlaubt die Sicherung mehrerer Quell- durch einen einzigen Ziel-Server. Dafür muss das Sicherungssystem allerdings performant genug sein, um jedem der abgesicherten Server-Dienste für den Notfallzeitraum hinreichend Leistung zur Verfügung zu stellen.

Das Failover-Werkzeug ist an keine bestimmte Netztopologie gebunden: Es unterstützt LAN, WAN, VPN und NAT gleichermaßen. Wird der Ziel-Server über das WAN angesprochen, lassen sich damit unter Berücksichtigung der zur Verfügung stehenden Netzbandbreite geografisch verteilte Hochverfügbarkeitssysteme aufbauen. Double-Take ist applikationsunabhängig und unterstützt derzeit Server-Systeme unter Windows NT, 2000 und 2003.

Das Setup

Master und Replikat waren im Test als Domänenmitglieder eingerichtet. Das ist kein Muss, vereinfacht aber die Rechteverwaltung durch die Domänenbenutzer. Double-Take erzeugt beim Setup zwei Benutzergruppen ("Double-Take Admin", "Double-Take Monitor"). Dort sind die Benutzer zu registrieren, die als Double-Take Admins autorisiert werden sollen. Nach dem Setup wird ein "Configuration Wizard" gestartet, der bei der Ersteinrichtung des Systems unterstützt. Die zu replizierenden Daten werden in einem "Replication Set" beschrieben, einer frei wählbaren Zusammenstellung von Dateien und Verzeichnissen. Hierbei ist jedoch zu beachten, dass die zu replizierenden Verzeichnisse bereits existieren müssen, wenn der Assistent läuft. Auch zeigt das Tool als Quelle stets nur das Laufwerk an, selbst wenn darin Unterverzeichnisse zur Replikation ausgewählt wurden. Nach dem Setup erfolgt eine Eins-zu-eins-Replikation aller Quelldaten auf den Ziel-Server, später werden nur noch die jeweiligen Änderungen übertragen.

Im Test wurden einige Gigabyte an Daten transferiert, eine Verzögerung bei der Datenbearbeitung auf dem Master ist auf dem Replikat nicht erkennbar. Werden allerdings zwei Replication-Sets zwischen einem Master und einem Target eingerichtet, so sind manche Angaben - etwa die Anzahl transferierter Bytes - in der Konsole für beide Sets gleich. Eine tatsächliche Unterscheidung findet demnach nicht statt - laut Dokumentation werden stets Target-Werte geliefert.

Verteilte Administration möglich

Nach dem Datenabgleich schaltet das Tool in den Überwachungsmodus. Hierzu liefert der Hersteller ein eigenes "Failover Control Center", das den Quell-Server kontrolliert. Zwar sind dessen Funktionen auch in der "Management Console" integriert, dank dieser Separation lässt sich jedoch eine verteilte Administra- tion aufbauen. Ferner kann die Überwachung durch SNMP-Traps (Simple Network Management Protocol) in die gängigen System-Management-Werkzeuge eingebunden werden. Zudem kommt vom Anbieter ein Integrationspaket ("Management Pack") für den Microsoft Operations Manager (MOM).

Für den Test wurde der Master vom Netz genommen und war damit für das Target nicht mehr erreichbar. Das Sunbelt-Produkt erkannte und meldete dies nach einer vordefinierten Zeitspanne. An dieser Stelle lässt sich der Failover nun abbrechen oder fortführen. Er erfordert keinen Neustart und ist demnach in wenigen Minuten erledigt. Hinzu kommt das skriptgesteuerte Starten der Applikation. Die Wiederherstellung des ursprünglichen Zustands, das Failback, kann auch aus dem Failover Control Center heraus angestoßen werden. Im Test verliefen Failover und Failback flott und ohne Zwischenfälle.

Kostengünstige Absicherung

Über eine Reihe von Konfigurationsparametern etwa zum Netz, der konsumierten WAN-Bandbreite, den Ports, dem Logging und der Heartbeat-Frequenz lässt sich die Arbeitsweise des Produkts beeinflussen. Für jede der möglichen n-zu-n-Beziehungen wird ein Heartbeat eingerichtet. Dieser operiert mit einer wählbaren IP-Adresse sowie separater Netzkarte.

Double-Take ermöglicht durch die Mehrfachzuordnung eines Backup-Systems zu mehreren produktiven Mastern eine kostengünstige Absicherung. Allerdings darf dabei nur ein Primärsystem ausfallen. Soll auch der Ausfall eines zweiten Systems abgesichert werden, relativiert sich dieser Vorteil. Unterstützung für Support und Installation bietet der Hersteller derzeit nur via E-Mail und per Telefon.

Neverfail Heartbeat von Neverfail bildet das als "Primary" bezeichnete Produktivsystem eins-zu-eins auf das Backup-System, das "Secondary", ab. Letzteres übernimmt schnell die Daten, ist ansonsten als Standby-Gerät inaktiv und überwacht das Primärsystem durch einen einstellbaren Heartbeat.

Das Secondary muss in puncto Software genauso aufgebaut sein wie das Primärgerät. Das gilt für das Betriebssystem, seine Service-Packs und die Anwendungspakete gleichermaßen. Ebenso müssen sich Laufwerksbuchstaben und Verzeichnisstruktur entsprechen. Der Aufbau dieses Clones erfolgt allerdings beim Setup durch das Werkzeug selbst. Somit stellt das Secondary eine eins-zu-eins-Kopie des Primary dar. Da Neverfail nur einen einzigen Primär-Server absichert, muss das Sicherungssystem auch nur maximal dessen Leistungsdaten aufweisen. Eine identische Hardware ist nicht notwendig. Ein Speicherausbau ab 512 MB RAM reicht laut Hersteller aus.

In der Testumgebung wurde mit Systemen gearbeitet, deren CPU, Mainboard, Speicher sowie Netz- oder Grafikkarte sich unterschieden. Das Setup ist vergleichsweise detailliert und erfordert etliche Einstellungen, die von einem Assistenten abgefragt werden. Hier gilt es allerdings aufzupassen, denn die grafische Oberfläche führt den Benutzer nicht immer eindeutig. Immerhin bietet Neverfail eine nützliche Animation mit den einzelnen Installationsschritten.

Unerklärlicherweise meldete Windows beim Hochfahren des Masters mitunter, den Neverfail-Dienst nicht aktivieren zu können, obgleich er wenige Minuten später lief. Neverfail Heartbeat dupliziert nach dem Setup zuerst eins-zu-eins das Primary. Dies erfolgt aus einem Assistenten heraus, der mit Hilfe des Windows-eigenen Backup-Tools eine Sicherungskopie des Gesamtsystems erzeugt. Diese ist dann auf das Replikat zu kopieren und dort zu restaurieren. Da der Secondary als Eins-zu-eins-Kopie nun die gleiche IP-Adresse aufweist, muss er vom Netz genommen werden, bis die Adresse angepasst ist. Nach diesen Schritten folgt die Online-Replizierung der Daten.

Hierzu müssen die zu sichernden Verzeichnisse angewählt und mit weiteren Kommunikationsoptionen versehen werden. Um die Daten zeitnah aus dem Primärsystem abgreifen und auf das Zweitsystem spiegeln zu können, werden spezielle Treibermodule, die "Application Modules", benötigt. Diese gibt es derzeit für die Dateidienste von Windows, den Exchange Server, den SQL Server, den Sharepoint Portal Server und die IIS-Dienste sowie den Messaging-Server von Blackberry.

Zentrale Verwaltung

Die Verwaltung von Primary und Secondary erfolgt über eine zentrale Konsole. Auch Neverfail Heartbeat bietet eine Vielzahl von Konfigurationseinstellungen für Übertragung, Bandbreite, Disk-Nutzung oder Primary-Überwachung. Letztere wird über einen Heartbeat zwischen den Systemen realisiert, der über eine eigene Netzkarte und -verbindung geschleust wird und somit unabhängig von den Nutzerzugriffen auf den Server agiert. Im Test ließ sich dies durch die Windows-Betriebsmittel einfach kontrollieren. Für den Einsatz des Tools im WAN wird eine dritte Netzkarte empfohlen, um die WAN-Strecke abzusichern. Für den automatischen Start der Anwendungen auf dem Secondary beim Failover bietet das Werkzeug eine Reihe von Skripten.

Schritt für Schritt

Neverfail schaltet in mehreren Schritten von Primary auf Secondary: Ist das Primärsystem noch aktiv, wird zunächst die darauf laufende Applikation gestoppt. Anschließend werden die restlichen Daten auf den Secondary übertragen, um dann die Netzverbindung des Primary zu kappen. Der Secondary, der ja zum aktiven Server werden soll, verbindet sich dann mit dem Netz und startet skriptgesteuert die Applikation.

Im Test zeigten sich bei der Umschaltung keine Probleme, sowohl die Daten als auch die Applikation waren vorhanden. Neverfail eignet sich vor allem dann, wenn eine Eins-zu-eins-Abbildung erwünscht ist, und stellt vergleichsweise geringe Anforderungen an die Backup-Hardware.

WANSync 3.72.58 von Xosoft. Unter dem Begriff WANSync bietet der Hersteller eine ganze Produktfamilie für den Failover-Einsatz. Im Hinblick auf den technischen Umfang lassen sich die Varianten "WANSync", "WANSyncHA" und "WANSyncCD" unterscheiden. Während die Basisversion WANSync lediglich die Replizierung der Daten umfasst, bietet WANSyncHA, die High-Availability-Version des Produkts, einen automatisierten Failover. WANSync- CD schließlich ist für die Verteilung von Dateiinhalten (Content Distribution), die vor allem bei Web- oder Dokumenten-Management-Servern erforderlich sind, vorgesehen. Differenziert wird ferner nach den unterstützten Basissystemen. Dabei wird derzeit die Replikation von Dateien, der Datenbankinhalte des SQL Server 7 oder 2000 und Oracle 88 und 9i sowie der Inhalte von Microsoft Exchange in den Versionen 5.5, 2000 und 2003 unterstützt. Die Architektur setzt sich aus Master- und Replica-Server zusammen. Dabei kann jedes teilnehmende System zugleich für einen Server als Datensenke und für einen anderen als Datenquelle fungieren. So lassen sich die Daten von Rechner zu Rechner weiterreplizieren.

Bei WANSync muss der Replikat-Server die gleiche Konfiguration aufweisen wie der Master, inklusive aller Service-Packs oder Hot Fixes. Ferner müssen sich beide in derselben Domäne befinden. WANSyncHA ermöglicht sowohl einen automatischen Failover als auch einen manuellen Switchover.

Übersichtliche Parameter

Die Verwaltung von WANSync erfolgt durch den "WANSync Manager" oder ein CLI (Command Line Interface). Der Manager stellt eine grafische Verwaltungsoberfläche bereit. Die Installation warf in der Testumgebung einige Fragen auf, die via E-Mail und Telefonsupport gelöst wurden, verlief dann aber reibungslos. Die nachfolgende Konfiguration wird durch die Verwaltungsoberflächen unterstützt, in denen die Parameter übersichtlich dargestellt sind.

Für den Test wurde eine Replikation von Verzeichnissen konfiguriert. Die Dateien wurden binnen Sekunden auf das Replikat kopiert, die Löschung von Files ging ebenso flott. Anders als beim Master landet eine gelöschte Datei beim Replikat allerdings nicht im Papierkorb. Geprüft wurde das Failover, indem der Master vom Netz genommen wurde.

Dabei erhält der Replikat-Server nach dem Umschalten den Host-Namen des Master-Systems. Nach dem Failover wird der Replikat-Server dann automatisch gebootet. Auch hier darf der Master aufgrund des Namenskonflikts nun nicht mehr im Netz erscheinen. Optional ist es auch möglich, die IP-Adressen auszutauschen sowie die DNS-Funktionen umzulenken. Beides ist jedoch in der Regel nicht erforderlich, da die Zuordnung der Clients zum Replikat-Server bereits durch die Auflösung des Computernamens erfolgen sollte.

Für komplexe Strukturen

Um die Funktionsfähigkeit des Masters durch das Replikat zu prüfen, wird für reine Datei-Server ein "Ping" herangezogen. Für weitergehende Prüfungen kann der Benutzer aber auch eigene Skripte erstellen. Ferner können Skripte beim Fail- oder Switchover angestoßen werden. Ähnliches gilt für die Funktion des Rechners. Für einfache Dateidienste sind keine weiteren Anpassungen erforderlich. Werden jedoch spezielle Services wie FTP, HTTP oder Datenbankdienste benötigt, müssen auch diese über Scripte gestartet werden.

WANSync bietet viele weitere Optionen, die eine detaillierte Einstellung bei der Replikation und dem Umschalten ermöglichen. Im Test zeigten sich keine Probleme, das Tool arbeitet wie beschrieben, und die Verwaltungsoberfläche ist gut strukturiert. Vor allem für komplexere beziehungsweise kaskadierte Strukturen hat das Werkzeug seine Stärken.

Rescudo von der NETS GmbH wurde in der Vergangenheit als "Notfall-Server" vertrieben. Das Konzept des von dem deutschen Unternehme entwickelten Produkts gleicht eher einem Imaging beziehungsweise schnellen Restore der gesamten Systemumgebung als den bekannten Hochverfügbarkeits-Funktionen. Das liegt nicht zuletzt daran, dass die Datenreplizierung in Rescudo mit weit geringerer Frequenz erfolgt als bei den anderen Produkten und zur Umschaltung lediglich ein manueller Switchover empfohlen wird. Nach Angaben des Vertriebspartners lässt sich für dateibasierende Einsatzzwecke ein Replikationsintervall von etwa zwei Stunden realisieren, für Exchange-Datenbestände wiederum sind zirka vier Stunden angesetzt. Der Vorteil: Rescudo ist applikationsunabhängig und lässt sich in jeder Systemumgebung einsetzen. Gebunden ist das Tool allerdings an das Betriebssystem - es unterstützt derzeit Windows und OS/2.

Im Test wurde das aktuelle Release 1.6 unter Windows 2003 verwendet. Zu sichern war eine Version von MS Exchange 2003, dessen Server auch die DNS-Dienste trug. Als Notfall-Server empfiehlt der Hersteller ein Windows-2003-System, dafür kann Rescudo mehrere Server absichern, allerdings nicht gleichzeitig. In der sonstigen Arbeitsweise ähnelt das Produkt den anderen Testkandidaten. Die Konfiguration ist bei Rescudo aufgrund der Besonderheit des Imaging am einfachsten. Beim Setup wird eine vollständige Kopie des abzusichernden Systems gezogen und auf dem Notfall-Server hinterlegt. Dies erfolgt durch Rescudo selbst, der Administrator hat hier lediglich eine überwachende Funktion.

In einem zweiten Schritt, der "Konfigurationsanpassung", wird das erzeugte Image um die spezifischen Gegebenheiten des Notfall-Servers ergänzt. Auch dies erledigt das System. Im Test gab es dabei nichts zu beanstanden. Für die Verwaltung steht eine grafische Oberfläche, aber auch ein Kommandozeilen-Interface zur Verfügung. Beide kennen, verglichen mit den drei Konkurrenzprodukten, nur wenige Einstellungen.

Rescudo operiert derzeit noch auf der File-Ebene und wertet das Datum der letzten Dateiänderung aus. Demnach wird die Datei bei einer Modifikation stets vollständig übertragen. Da dies bei vielen Änderungen zur Überlastung des Netzes führen würde, wird eine zeitverzögerte und periodische Übertragung der modifizierten Dateien empfohlen. Die Folgeversion soll auch Block-Level-Replikation bieten, die für den WAN-Einsatz geeignet ist.

Kein automatisches Failover

Der zweite wesentliche Unterschied betrifft die Umschaltung, die stets als manueller Switchover erfolgen soll. Eine Automatisierung ist zwar technisch machbar, wird aber vom Hersteller nicht empfohlen. Rescudo verwendet keinen Heartbeat, verfügt aber über eigene Kommunikationsprozesse, die den Notfall-Server mit den Zustandsinformationen der abzusichernden Geräte versorgen: So prüft das Tool per Ping, ob der Master erreichbar ist. Antwortet dieser 20 Minuten lang regelmäßig, findet kein Switchover statt. Reagiert er jedoch schon nach den ersten ICMP-Paketen (Internet Control Message Protocol) nicht mehr, erfolgt der Switchover sofort. Dazu werden die auf dem Notfall-Server befindlichen Images verwendet. Die Umschaltung erfolgt durch den Neustart des Systems. Im Test verlief diese korrekt. Danach wies der ehemalige Notfall-Server sämtliche Merkmale des übernommen Systems (etwa Computername, Domäne und IP-Adresse) auf. Auch der Kommunikationsdienst von Rescudo, ursprünglich auf dem Server ausgeführt, war wieder aktiv.

Da der Rescudo Notfall-Server in relativ langen Intervallen repliziert, eignet er sich für andere Anwendungsgebiete als die drei konkurrierenden Produkte. Die Inbetriebnahme und das laufende Management sind in jedem Fall einfach gelöst und erfordern keine großen Änderungen an der Systemumgebung. (kf)