Bents Blog

 

Ein IT Blog mit Themen aus dem Windows Server Umfeld.

DataKeeper – Block-basierte Spiegelung von Volumes über das Netzwerk

In meinem heutigen Beitrag möchte ich ein Produkt vorstellen, welches ich in meiner mittlerweile 11-jährigen Eigenschaft als Hochverfügbarkeitsberater in sehr vielen Kundenprojekten erfolgreich eingesetzt habe. Ich bin kein Freund von Schleichwerbung, wenn ich allerdings von einem (kostenpflichtigen) Produkt überzeugt bin, dann empfehle ich selbiges auch weiter.

Bei dem Produkt handelt es sich um den DataKeeper des Herstellers SteelEye Technology Inc. (inzwischen SIOS Technology Inc.) – einer Replikationslösung, um Volumes block-basiert über das Netzwerk zu spiegeln. Nun existieren verschiedenste Produkte für die Daten-Replikation am Markt, auch Microsoft bietet bereits mit dem DFSR (Distributed File System Replication) eine Variante, um Daten zwischen Servern zu synchronisieren. Es existieren aber oft genug Szenarien, in denen bspw. der Einsatz von DFSR über- oder auch unterdimensioniert ist.

Versionen

Der DataKeeper kann in Windows Server Umgebungen (unabhängig von einer Domäne) unter Windows Server 2003 bis hin zu Windows Server 2008 R2 eingesetzt werden. Dabei werden alle Editionen unterstützt, auch der Einsatz mit dem Microsoft Hyper Server R2 ist so beispielsweise möglich. Die Software (aktuelle Version 7.2.0) gibt es in zwei Ausprägungen:

  • DataKeeper Standard Edition
  • DataKeeper Cluster Edition

Die Cluster-Edition bietet als Besonderheit (einziger Mehrwert im Vergleich zur Standard Edition) die Unterstützung für die Windows Server Failover Clustering Dienste (WSFC) im Windows Server 2008 (R2). Durch den DataKeeper kann hier auf den Einsatz eines externen Speichersystems verzichtet werden und so auch „stretched“ Cluster (weit entfernte Systeme) aufgebaut werden. Dieser Version werde ich zukünftig einen eigenen Beitrag widmen.

In der Standard Edition wartet der DataKeeper für die Replikation von Volumes zwischen 2 oder mehreren Systemen mit den folgenden Funktionen auf:

  • Host-basierte Replikation auf Ebene kompletter Volumes
  • Synchrone oder asynchrone Spiegelung
  • Anwendungs-Unabhängigkeit
  • mögliche Einbindung in die eigene Clusterlösung LifeKeeper von SteelEye

Ich persönlich mag keine ellenlangen „Feature“-Listen, weshalb ich diese recht kurze Aufzählung aus technischer Sicht ausführlich beleuchten werde. Allerdings will ich auch gleichzeitig die Einschränkungen des Produktes aufzählen:

  • keine Replikation von System-Volumes, Wechseldatenträgern oder Volumes auf denen eine Auslagerungsdatei liegt
  • nur Volumes mit dem NTFS Dateisystem werden unterstützt

Installation

Die Installation des DataKeeper gestaltet sich einfach und schnell. Das Installationspaket ist mit etwa 22 MByte relativ klein und beinhaltet einen Filtertreiber, den DataKeeper Dienst und die grafische Benutzeroberfläche in Form einer MMC 3.0. Letztere kann auch auf einem anderen System installiert werden, um die DataKeeper Server remote zu verwalten (bspw. bei einer Installation auf Windows ServerCore). Für die Funktionen der MMC wird das .NET Framework 3.5 benötigt. Nach der Installation muss das betreffende System neu gestartet werden, damit der Filtertreiber geladen werden kann.

Einrichtung einer Replikation

Im einfachsten Beispiel soll ein einzelnes Volume zwischen zwei Servern repliziert werden. Als Voraussetzung müssen beide Server über eine Netzwerkverbindung (TCP/IP) miteinander kommunizieren können. Sowohl das Quell- als auch das Ziel-Volume sollten die gleiche Größe besitzen, zumindest muss das Ziel-Volume – logischerweise – größer als das Quell-Volume sein. Ob sich die Platten der Volumes lokal in den Servern befinden oder auf einem externen Speichersystem (bspw. über iSCSI) ist für den DataKeeper nicht von Bedeutung.

Nach dem Aufruf der MMC DataKeeper meldet man sich zunächst am Quell- und am Ziel-System an:

Die möglichen Volumes die für eine Replikation in Frage kommen, zeigt der DataKeeper nun automatisch an – in meinem Beispiel das Volume mit dem Laufwerksbuchstaben [D]:

Für dieses Volume kann nun ein neuer Replikations-„Job“ definert werden:

Der Assistent fragt nun nach dem Quell-System, der zugehörigen IP-Adresse und dem Volume:

Im zweiten Schritt werden diese Informationen für das Ziel-System bestimmt:

Im letzten Fenster des Assistenten werden nun die Eigenschaften der Replikation definiert:

Dabei kann die zu nutzende Bandbreite für die Replikation beschränkt, der Modus synchron oder asynchron gewählt und eine Kompressionsrate eingestellt werden. Von der Komprimierung der zu replizierenden Daten sollte man allerdings keine Wunder erwarten, da nur jeder einzelne Block und kein gesamter Stream „gepackt“ werden kann. Die maximal nutzbare Bandbreite ist abhängig von der Netzwerkverbindung.

Da die Endpunkte des Spiegels auf IP-Adressen beschränkt sind, können auch gebündelte (Trunking, Link Aggregation) Netzwerkadapter für die Replikationsverbindung verwendet und so die Bandbreite erhöht werden. Außerdem ermöglicht die Nutzung von IP-Adressen (Routing) eine einfache und flexible Replikation über WAN- oder VPN-Strecken.

Nach der Erstellung des Spiegels wird nun das Quell-Volume mit dem Ziel-Volume automatisch synchronisert:

Dabei repliziert der DataKeeper nur die belegten Dateisystem-Blöcke des Quell-Volumes – unabhängig von dessen Gesamtgröße, eine sehr effiziente Funktionalität. Sobald diese Blöcke übertragen wurden, wechselt der Zustand des Spiegels in „Mirroring“ – Quell- und Ziel-Volume sind nun identisch:

In diesem Zustand verbleibt der Spiegel, solange keine administrativen Aktionen ausgelöst werden. Alle Daten (Blöcke) die nun auf dem Quell-Volume geschrieben werden, repliziert der DataKeeper automatisch auf das Ziel-Volume. Auf dem Ziel-System selbst, wird das Volume durch den DataKeeper für alle Zugriffe gesperrt:

Dadurch wird die Konsistenz des Ziel-Volumes sichergestellt.

Funktionsweise

Die Funktionsweise des DataKeeper ist so einfach wie genial. Der installierte Filtertreiber befindet sich dabei aus logischer Sicht zwischen dem Dateisystemtreiber (nfts.sys) und dem Volume. Wird nun auf dem Quell-Server ein Block geschrieben (gleich von welcher Anwendung), so wird dieser über das Netzwerk auf das Ziel-System übertragen:

In Bezug auf die Geschwindigkeit bietet der DataKeeper zwei verschiedene Betriebsarten (die separat für jede Replikation wählbar ist): synchron oder asynchron.

Synchroner Modus des DataKeeper

Im synchronen Modus wird jede Schreib-Anforderung des Dateisystems (bspw. Datenbanken oder Dateioperationen) zuerst lokal auf dem Quell-System geschrieben, danach auf das Ziel-System übertragen und erst nach dessen Rückmeldung als vollständig gemeldet:

Der Vorteil dieser Betriebsart ist ein – zu jeder Zeit – identischer Datenbestand. Allerdings steht diesem Vorteil die geringere (Schreib-)Performance des Volumes negativ gegenüber. Jeder Block wird lokal geschrieben, über das Netzwerk übertragen und erst dann „fertig“ gemeldet. Das kostet Zeit (Latenz des Netzwerks) und Rechenleistung (da jedes Paket den Prozessor belastet). Besonders I/O-lastige Anwendungen – wie etwa Datenbanken – reagieren äußerst „träge“, wenn selbige ihre Datenbankdateien (und Transaktionsprotokolle) nicht schnell genug schreiben können.

Achtung: Diese Einschränkung gilt nur für den schreibenden Zugriff, da beim Lesen von Blöcken der DataKeeper nicht mit dem Ziel-System kommuniziert.

Asynchroner Modus des DataKeeper

Im asynchronen Modus verwendet der DataKeeper eine sogenannte „Bitmap“-Datei auf dem Quell-System. Diese Datei speichert für jeden verfügbaren Block des Volumes nur zwei mögliche Zustände: dirty (zu replizieren) oder clean (bereits repliziert). Erfolgt eine Schreib-Anforderung auf dem Quell-System, so wird der Block auf dem Quell-Volume sofort geschrieben und „fertig“ zurückgemeldet, der Block wird in der Bitmap-Datei als dirty markiert, in eine Warteschlange gestellt und anschließend im Hintergrund übertragen. Dadurch wird die Geschwindigkeit der Quell-Volumes quasi nicht mehr beeinflusst:

Da die Replikation asynchron erfolgt, kann es allerdings bei Ausfall des Quell-Systems passieren, dass die Daten des Ziel-Volumes nicht vollständig identisch sind, da zum Zeitpunkt der Replikationsunterbrechung nicht alle Blöcke der Warteschlange vollständig übertragen wurden.

Partielle Resynchronisation

Grundsätzlich führt der DataKeeper die „Bitmap“-Datei immer bei Unterbrechung der Replikationsverbindung mit – also auch im synchronen Modus. Durch diese Funktion kann bei der Wiederherstellung der Verbindung eine partielle Resynchronisation durchgeführt werden – es werden somit nur die Blöcke zum Ziel-System transferiert, die seit der Unterbrechung auf dem Quell-System geschrieben (und so geändert) wurden. Das ermöglicht eine komfortable Verwaltung der Spiegel und Server (siehe Abschnitt Verwaltung), ohne die Volumes vollständig neu synchronisieren zu müssen.

Write Order Consistency

Der DataKeeper gewährleistet grundsätzlich die Einhaltung der Schreib-Reihenfolge. Das bedeutet, dass alle Blöcke, die vom Dateisystem geschrieben werden, in derselben Reihenfolge auf das Ziel-System übertragen werden. Nur so kann die Konsistenz (crash consistent) eines Volumes sichergestellt werden, um bei Ausfall des Quell-Systems, zu jedem Zeitpunkt nutzbare Daten auf dem Ziel-System garantieren zu können.

Verwaltung

Mit dem DataKeeper erstellte Spiegel lassen sich über die GUI bequem verwalten. Dabei gibt es die folgenden Möglichkeiten:

  • Pause and unlock mirror (Synchronisation wird gestoppt, das Ziel-Volume wird verfügbar)
  • Continue and lock mirror (Synchronisation wird fortgesetzt, Ziel-Volume gesperrt)
  • Break mirror (Aufbrechen eines Spiegels und Stoppen der Synchronisation)
  • Resync mirror (Vollständige Re-Synchronisation eines Volumes)
  • Switchover Mirror (Änderung der Spiegelrichtung, Quelle wird Ziel)

Mit diesen Funktionen lassen sich sehr vielfältige Einsatzszenarien umsetzen, zumal alle Befehle auch über ein Kommandozeilen-Tool ausgeführt werden können, wodurch die Steuerung des DataKeeper Skript-fähig wird.

Zusätzliche Informationen

Der DataKeeper bietet auch die Möglichkeit, Spiegel „über Kreuz“ aufzubauen – so ist es möglich, ein Volume D von Server 1 zu Server 2 und gleichzeitig ein Volume E von Server 2 zu Server 1 zu replizieren. Weiterhin kann auch ein Quell-Volume gleichzeitig auf mehrere Ziel-Systeme übertragen werden (one-to-many).

Lizenziert wird der DataKeeper pro System, bei zwei Servern (Quelle und Ziel) werden also zwei Lizenzen fällig. Die Kosten für eine Standard Edition (für 2 Server) belaufen sich dabei auf etwa 2.200 € inkl. Support. Für die gebotene Funktionalität – nach meiner Meinung – ein fairer Preis.

Für diejenigen, die sich das Produkt einmal selber anschauen wollen, weiterführende Informationen oder Projekt-Anfragen haben, empfehle ich eine Kontaktaufnahme mit der Firma (www.cc-dresden.de), für die ich arbeite. Hier erhält jeder Interessent eine voll funktionsfähige, zeitlich begrenzte Version zur Evaluierung zur Verfügung gestellt.

Fazit

Der DataKeeper von SteelEye ist ein feines Produkt wenn es um die Replikation von Daten über das Netzwerk geht. Ich kann hier aus meiner eigenen Erfahrung sprechen und habe seit mehreren Jahren nur positive Resonanzen erhalten. Wer Fragen zum Produkt hat kann diese hier als Kommentar hinterlassen, wer Interesse an der Lösung hat, meldet sich besser gleich in der Firma für die ich arbeite.

Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.