Ausfallsicherheit durch kontinuierliches, inkrementelles Imaging

Double-Take bietet Cluster-Lösung gegen ungeplante Ausfallzeiten

13.08.2007 | Autor / Redakteur: Johann Baumeister / Rainer Graefen

Anwender, die einen Exchange-Server absichern möchten, müssen nur wenige Konfigurationsparameter eingeben.
Anwender, die einen Exchange-Server absichern möchten, müssen nur wenige Konfigurationsparameter eingeben.

Gutes Disaster Recovery ist eine Gratwanderung zwischen zumutbarer Ausfallzeit und Kosten. Ein passiver Standby-Server erweist sich so in vielen Fällen als akzeptable Alternative zur Spiegelung des kompletten Rechenzentrums. Das Standby-Konzept ist mit gewissen Modifikationen sogar zur Absicherung mehrerer Rechner geeignet. Einer der Anbieter in diesem Segment ist Double-Take. Im Test haben wir untersucht, was deren Produkte können – oder auch nicht.

Double-Take liefert zur Absicherung von Serversystemen eine gleichnamige Produktfamilie. Das Basisprodukt sichert das aktive Serversystem durch einen passiven Standby-Rechner, der im Fehlerfall automatisch aktiviert wird. Double-Take spricht dabei von dem aktiven Quellserver und dem passiven Zielserver. Das passive Standby-System benötigt für den Einsatzfall eine initiale Kopie des aktiven Systems mit allen Softwarekomponenten, also Betriebssystem, alle Patches und alle Anwendungen.

Sofern sich an der Software-Konfiguration des abzusichernden Servers nichts ändert, weil keine neuen Applikationen oder Patches hinzu kommen, so ist dieser initiale Systemabgleich ein einmaliger Vorgang. Sollten auf dem Server auch Daten gespeichert sein, so werden diese ebenso zu Beginn dupliziert. Da sich Daten häufiger ändern, werden sie laufend vom primären System auf den Standby-Rechner kopiert. Diese Replikation der Daten vom primären System zum sekundären Rechner passiert über ein software-basiertes Replikations-Verfahren. Es arbeitet unabhängig von der Netzwerktopologie und kann gleichermaßen im LAN, WAN oder über NAT und VPN verwendet werden.

Bei der Zuordnung des Quell- zu seinem Zielserver muss nicht unbedingt eine 1:1-Abbildung zwischen einer Quelle und einem Ziel eingehalten werden. Vielmehr erlaubt das Konzept auch eine „M zu N“-Konfiguration, das heißt mehrere Quell- können auf mehrere oder auch nur einen Zielserver repliziert werden. Beachtet werden muss dabei, dass ausreichend Bandbreite und Plattenkapazität auf dem Zielserver vorhanden sein muss, um im Fehlerfall die Last zu stemmen.

In unserem Test prüften wir das Basis-Konzept von Double-Take auf seine Praxistauglichkeit und Fehleranfälligkeit. Das Testszenario bestand aus je einem Windows Server 2003 als Quell- und Zielsystem. Sie befanden sich beide zusammen mit den Windows-Basisdiensten wie etwa DHCP, WINS und DNS in einer eigenen Domäne. Prinzipiell stellt Double-Take keine besonderen Anforderungen an die Systeme und unterstützt alle Windows Server Betriebssysteme ab Windows NT 4.0 bis Windows Server 2003 ebenso wie die Cluster-Version von Windows 2003 mit bis zu acht Knoten.

Mit dem Failover Control Center die Ausfallzeit im Griff

Zum Einrichten und Verwalten des Failover-Tools liefert der Hersteller zwei Konsolen: Die Management Console und das Failover Control Center. Mit der Management Console konfiguriert der Administrator Quell- und Zielserver. Das Failover Control Center überwacht hingegen den gesamten Cluster und startet im Fehlerfall den Standby-Server. Der erste Schritt beim Aufbau eines Failover-Szenarios und so auch in unserem Praxistest, liegt im Einrichten eines Replication Set. Es beschreibt, welche Verzeichnisse und Daten von der Quelle zum Ziel repliziert werden sollen. Das beinhaltet auch die Sicherung von Datenbanken und ihrer Log-Dateien, sowie des Mailspeicher von Exchange. Nach dem Einrichten des Replication Set erfolgt die Spiegelung der Daten vom Quell- auf den Zielserver.

Anschließend schaltet das Tool in den Überwachungsmodus. Nun werden nur noch die Änderungen in den Quelldateien auf den Zielserver übertragen. Dieser Abgleich der Daten erfolgt durch spezielle Treiber, die sich in die Ein- und Ausgabeoperationen des Quellsystems einklinken und dort alle Änderungen abgreifen und zeitnah zum Zielsystem transportieren. Dieser Abgleich arbeitet über asynchrone Kommunikation, die, wie oben erwähnt, auch über beliebige IP-Strecken erfolgen kann. Verfahren dieser Art werden derzeit auch unter dem Begriff der Continuous Data Protection geführt. Im Gegensatz zu den CDP-Systemen, die nur die Daten absichern, übernimmt Double-Take aber auch das Umschalten auf den Zielserver, falls der Quellserver nicht mehr erreichbar ist. Zu den weiteren Konfigurationsparametern dieser Datensynchronisation gehören Angaben über das Netzwerk, Ports, Verzeichnisse, das Logging, die Heartbeat-Frequenz oder die Replikations-Warteschlange.

Das Failover Control Center überwacht die Verfügbarkeit des Quellservers. Es steuert auch das Umschalten auf den Zielserver im Fehlerfall. Im Test simulierten wir den Ernstfall durch das Entfernen des Quellservers aus dem Netzverbund. Da nun der Zielserver keine Synchronisation mehr mit der Quelle mehr hat, leitete er erwartungsgemäß, nach dem Ablauf einer einstellbaren Zeitspanne, den Failover ein. Dabei werden alle Identifikationsmerkmale, über welche die verbundenen Clients ihren Server finden, umgestellt. Dies sind die IP-Adresse, der Hostname, freigegebene Ressourcen, die Einträge im Directory und die internen Tabellen für DNS- und WINS-Namensauflösung.

Prinzipiell kann dieser Umschaltvorgang auf zwei Wegen erfolgen. Beim Switchover leitet der Administrator die Übergabe manuell ein und kann damit alle Vorgänge kontrollieren und eventuell verwerfen. Der Failover steht für den vollautomatisierten Umschaltprozess. Hierbei werden die Applikationen auf dem Zielserver durch Skripts gestartet. Dennoch muss natürlich beachtet werden, dass bei einem Ausfall eines Server in jedem Fall der Administrator die Situation prüfen sollte. Ein Automatismus wird daher nur bei einfacheren Szenarien, wie der Absicherung des Filesystem angeraten sein. Im Test konnten wir sowohl den manuellen als auch den automatischen Ablauf jederzeit beeinflussen.

Mehrfachabsicherung durch Imaging

Durch die Funktionen von Double-Take nach dem oben beschriebenen Verfahren, erreicht man eine Absicherung eines einzigen Servers und dessen Daten. Dabei muss zu Beginn der Zielserver mit einer identischen Systemkonfiguration ausgestattet werden. Dieser Systemzustand bleibt dann eingefroren. Die Daten hingegen werden immer aktuell vom Quell- auf den Zielserver kopiert. Wenngleich Double-Take n:1-Replikationsverfahren erlaubt, so gilt das immer nur für die Daten. Bezüglich des Betriebssystems und der Applikationen kann ein Zielserver im Failover natürlich nur als Ersatz für ein Quellserver dienen. Das bedeutet aber auch, dass jedem abzusichernden Quellserver ein inaktiver und redundanter Zielserver beiseite gestellt werden müsste. Double-Take bietet mit der Server Recovery Option (SRO) eine preiswerte Lösung für Umgebungen an, die allerdings nicht unter der Anforderung „hochverfügbar“ stehen dürfen.

Die SRO-Variante erlaubt es, mehrere Serversysteme auf einem gemeinsamen Ersatzserver zu konservieren. Der Aufbau diese Konzeptes ist wie folgt. Im ersten Schritt erfolgt ein Abzug der Systemimages aller bestehenden Quellserver. Diese Images werden allesamt auf einem gemeinsamen Imaging-Server hinterlegt. Im Gegensatz zur oben beschriebenen Basisversion von Double-Take ist dieses Image jedoch nicht fest und eingefroren. Stattdessen werden auch die Änderungen an der Systemkonfiguration aller gesicherten Quellserver als Deltas auf den Image-Server übertragen. Dies gilt auch für alle Applikationen und Patches. Werden also an einem der Quellserver Änderungen vorgenommen, so spiegelt Double-Take diese auf den Image-Server. Durch das inkrementelle Update des System-Images sind also die Applikationssysteme gegen Änderungen abgesichert.

Disaster Revocery mit planbaren Ausfallzeiten

Was passiert nun mit den Daten? Auch sie werden, wie schon im traditionellen Verfahren, allesamt auf dem Image-Server repliziert. Dieser Image-Server umfasst somit die Daten und Applikation von mehreren abzusichernden Servern und hält diese auch durch die laufende Replikation aktuell. Tritt nun ein Fehler mit einem der Quellserver auf, so erfolgt, gesteuert durch einen Administrator, die Neueinrichtung des ausgefallen Servers auf ein ausreichend leistungsfähiges Ersatzsystem. Dieser wird im Fehlerfall mit dem Image des ausgefallenen Rechners bespielt und gestartet. Die dafür benötigt Zeitdauer zur Übertragung des Images hängt im Wesentlichen von der Größe des Images, also der Datenmenge, ab. Double-Take gibt an, dass pro Stunde ungefähr 40 GByte über ein GBit-LAN übertragbar seien. Für einen Datenbankserver mit 100 GByte Nettodaten plus der Applikationen beträgt der gesamte Vorgang damit in etwa drei Stunden. Dies ist natürlich weitaus länger als die reine Umschaltzeit und der Reboot bei der Standard-Version von Double-Take. Dafür erfolgt hierbei allerdings eine Absicherung mehrerer Server durch zwei weitere, den Image-Server und den im Notfall einzurichtenden Recovery-Server.

Im Test stellten wir auch dieses Szenario nach. Zur Verwaltung der SRO-Erweiterung liefert Double-Take eine weitere Verwaltungskonsole. Diese verlangt im Fehlerfall, also bei einem geplanten Recovery eines Servers auf den bereitgestellten Server, drei Angaben. Den Imaging-Server, das wiederherzustellende Image und den Recovery-Server. So einfach dies scheinen mag, Probleme gab es im Testlauf dennoch. Aufgrund einer fehlenden Berechtigung (Benutzername und Passwort) wurde der Imaging-Vorgang nicht begonnen. Nach dessen Richtigstellung brach das Imaging wegen unterschiedlichen Zeiten zwischen den beiden Servern erneut ab. Zwar sind beide Fehler nicht Double-Take anzulasten, dennoch wäre eine vorhergehende Prüfung der Systemvoraussetzungen nicht falsch, zumal das Verwaltungswerkzeug ohnehin zu Beginn diverse Prüfungen durchführt. Nach der Richtigstellung der Zeitdifferenz funktioniert auch das Imaging wie erwartet. Der Recovery-Server stand nach dem Reboot im System zur Verfügung. Er erhielt wie gefordert, Rechnernamen und IP-Adresse des ursprünglichen Quellservers.

Im Test konnte das SRO-Konzept überzeugen. Zwar ist das Imaging von Systemen nicht neu und wird seit Jahren von vielen Anbietern verfolgt, aber die Kombination aus dem Imaging, mit einer automatisierten Ergänzung aller Systemänderungen, des Systemstatus und schließlich der Online-Replizierung der Daten ist eine interessante Neuerung. Hinzu kommt eine automatisierte Übertragung des Images im Fehlerfall auf das Notfallsystem und der Integration in das Netzwerk durch die Anpassung des Rechnernamens und der IP-Adresse.

Als Fazit bleibt festzuhalten das die Basisversion von Double-Take durchaus geeignet ist, einzelne Serversysteme mit einer kurzen Ausfallzeit abzusichern. Auch Double-Take SRO erfüllt den Zweck des Disaster Revocery, wobei allerdings der Zeitaufwand für das Kopieren des kompletten Images zu berücksichtigen ist. Für hochkritische Anwendungen, die ohne Unterbrechung weiterarbeitn müssen, ist weder SRO noch die Basisversion geeignet. Der Test zeigt aber auch, und das sollte für Disaster Recovery-Verfahren ohnehin selbstverständlich sein, dass Notfallszenarien vorher durchgespielt werden müssen.

Kommentare werden geladen....

Was meinen Sie zu diesem Thema?

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2006511 / Notfallplanung)