Distributed File System Replication

Lesezeit
3 Minuten
Bis jetzt gelesen

Distributed File System Replication

01.12.2017 - 14:15
Veröffentlicht in:
Die Distributed File System Replication ist seit vielen Server-Versionen ein probates Mittel, um freigegebene Dateibestände hochverfügbar zu machen oder bandbreitenschonend zwischen Standorten zu replizieren. Doch ganz ohne Hürden kommt die Technologie nicht daher.
Die Distributed File System Replication (DFS-R) ist eine mit Windows Server 2003 R2 als Nachfolger des "File Replication Service" (FRS) vorgestellte Replikationstechnologie, um Paare von Ordnern miteinander synchron zu halten, die sich auf unterschiedlichen Fileservern befinden. Im Gegensatz zu FRS werden Dateien bei Änderungen nicht vollständig kopiert. Stattdessen kommt die Remotedifferenzialkomprimierung (RDC) zum Einsatz.

Der praktische Einsatz von DFSR geschieht in der Regel in einem von zwei typischen Szenarien:

  • Ein Dateibestand wird gleichzeitig auf mehreren Servern freigegeben, um Lastverteilung, Ausfallsicherheit und Standortnähe zu gewährleisten. DFS-R sorgt für den synchronen Stand der Dateien. Für das Auffinden des passenden Servers kommt fast immer DFS Namespace (DFS-N) zum Einsatz. Ein Beispiel ist die Replikation der SYSVOL-Freigabe zwischen Domänencontrollern.
  • Freigegebene Dateibestände werden – in der Regel über WAN – an einen anderen Standort repliziert, wo sie zwar nicht produktiv genutzt, dafür aber als Sicherungskopie oder als Quelle für das Backup auf externe Medien verwendet werden.

Beide Szenarien haben jedoch ihre typischen Fehlerbilder. Wenn die entsprechende Konstellation in Ihrer Umgebung zum Einsatz kommt, müssen Sie sie schnell erkennen, überwachen und entstören können. Verteilter Zugriff und Konflikterkennung DFS-R arbeitet filebasiert, eine Datei ist hierbei das kleinste "unteilbare Teilchen".

Auch wenn nur Teile von Dateien dank RDC tatsächlich durch die Leitung geschickt werden, so hat DFS-R dennoch nicht die Fähigkeit, parallele Änderungen an ein und derselben Datei zusammenzuführen. Auch verfügt DFS-R über keinen "distributed locking"-Mechanismus, um geöffnete Dateien in einer Ordner-Kopie gegen Änderung in anderen Ordner-Kopien zu sperren.

Konflikte durch parallele Änderungen
Dies kann dann dazu führen, dass parallele Änderungen an unterschiedlichen Kopien ein und derselben Datei vorgenommen werden. In DFS-R kann es aber nur einen Versionsstand geben. Wird eine neue Version zur Übertragung vorgelegt, während die lokale Kopie noch gesperrt ist, erkennt DFS-R auf einem Fileserver daher einen Konflikt.

Ein Konflikt wird auch festgestellt, wenn während eines Replikationsintervalls Änderungen an zwei Kopien derselben Datei vorgenommen wurden, sodass sie zum Zeitpunkt der nächsten Replikation zwar beide nicht mehr gesperrt, aber unterschiedlich sind. Die Auflösung der Konflikte in DFS-R folgt fast immer der "last writer wins"-Logik. In den frühen DFSR-Versionen gab es eine Konstellation, in der eine ältere Kopie gewonnen hat. Dies war für die Nutzer und Administratoren jedoch so verwirrend, dass Microsoft dieses Verhalten im November 2010 durch einen Hotfix geändert und in dem dazugehörigen KB-Artikel als "logic error" bezeichnet hat.

Bis inklusive Windows Server 2012 waren Versionen, die bei der Konflikterkennung verloren haben, offiziell verloren. Als (präventive) Abhilfe führte Microsoft die Continuous Data Protection mit SCDPM oder Volume Shadow Copies an. Auch gab es ein im TechNet veröffentlichtes und offiziell nicht unterstütztes Skript "restoredfsr.vbs", das als letzter Ausweg angeboten wurde.

Das Skript ist wirklich krude, der Blick in den Quellcode verrät aber etwas ganz Wesentliches über das Verhalten von DFS-R: Die offiziell als verloren deklarierten Versionen werden nicht sofort gelöscht, sondern in das Unterverzeichnis "DFSRPrivate\ConflictAndDeleted" des replizierten Ordners verschoben. Von dort können sie dann an einen anderen Ort wiederhergestellt, untersucht und anschließend gegebenenfalls als separate Version abgelegt werden.

Mit Server 2012 R2 hat Microsoft dieses Verhalten offiziell verfügbar gemacht. Sie können nun pro Ordnerkopie entscheiden, ob für diese die unterlegenen Versionen aufgehoben werden sollen und wie viel Speicherplatz dafür zur Verfügung steht. Gleichzeitig wurde aus einem "normalen" Ordnerpfad eine symbolische Verknüpfung, deren Ziel im Ordner "System Volume Information" liegt und daher nicht ohne weiteres erreicht werden kann.

Gleichzeitig wurde den Administratoren ein offizieller Weg zur Verfügung gestellt, um auf die "Opfer" der Konfliktauflösung zuzugreifen: Mit dem PowerShell-Cmdlet "Get-DFSRPreservedFiles" können Sie die lokal abgelegten Kopien auflisten, mit "Restore-DFSRPreservedFiles" in einem anderen Pfad wiederherstellen. Angesichts des oben vermerkten Speicherpfades wird der Zugriff natürlich nur gelingen, wenn Sie die Cmdlets mit erhöhten Rechten ("Als Administrator ausführen") starten.

Monitoring über Protokolleinträge
DFS-R schreibt die wichtigsten Konfigurationsänderungen, Start- und Stopmeldungen sowie Fehler in das EventLog "Anwendungs- und Dienstprotokolle / DFS-Replikation". Treten dort Fehlereinträge auf, sollten Sie diesen Hinweisen in jedem Fall nachgehen, auch wenn das Problem sich noch nicht in Gestalt eines Support-Tickets manifestiert hat.

Als letzte Instanz sollten Sie für das DFSR-Troubleshooting die ausführlichen Protokolle des Dienstes bemühen. Sie müssen diese auch nicht extra aktivieren – DFS-R schreibt standardmäßig ein sehr detailliertes Log in "%SYSTEMROOT%\ Debug\dfsr#####.log" mit fortlaufender Nummerierung. Das Protokoll wird rotiert, ältere Versionen als GZ-Datei komprimiert. Der Detailgrad der dort enthaltenen Informationen ist so hoch, dass diese Protokolle nur für ganz spezielle Troubleshooting-Fälle geeignet sind, wo die anderen oben beschriebenen Mittel versagen.

Doch falls Ihr Problem so komplex sein sollte, dass diese Informationen immer noch nicht ganz ausreichend sind, können Sie mit wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set debuglogseverity=5 den Log Level von standardmäßig "4" (Debug) auf das Maximum von "5" (Trace) hochsetzen.

Fazit
DFS-R ist eine in verteilten Umgebungen extrem nützliche Technologie, bedarf aber ständiger Überwachung und Pflege. Microsoft liefert dafür zahlreiche Werkzeuge, für deren erfolgreichen Einsatz jedoch das Wissen über die Funktionsweise des DFS-R unabdingbar ist. Hin und wieder sollten Sie auch das Replikations- und Zugriffsdesign auf den Prüfstand stellen und gemäß den Anforderungen Ihrer Nutzer anpassen.

Evgenij Smirnov/dr

Tags

Ähnliche Beiträge

Speicherreplikation in Windows Server

Eine der wichtigsten neuen Funktionen in Windows Server 2016 ist die Speicherreplikation, von Microsoft als Storage Replica bezeichnet. Mit dieser Technologie lassen sich ganze Festplatten blockbasiert zwischen Servern replizieren, auch zwischen verschiedenen Rechenzentren sowie der Cloud und einem Rechenzentrum. Wir erklären, was Storage Replica zu bieten hat und wie sie funktioniert.

Storage Management

Der Begriff Storage Management bezeichnet die Technologien und Prozesse, die in Unternehmen zu Einsatz kommen, um die Leistungsfähigkeit und Produktivität der Speichersysteme zu maximieren. Im besten Fall soll die Datenablage auch einfacher werden, zudem ist Zukunftsfähigkeit gefragt. All diese Anforderungen bereiten den IT-Abteilungen oft Bauchschmerzen. Modernisieren Unternehmen ihre Speichersysteme, können sie mit Funktionen wie Auto Tiering und Speichervirtualisierung mehr Leistung aus ihrem Speicher herausholen. Nicht zuletzt automatisieren sie so idealerweise auch typische Aufgaben. Nicht immer jedoch lässt sich die Komplexität in gleichem Maß senken.