Grundlagen

Distributed File System Replication

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.
1.12.2017/Evgenij Smirnov/dr

Nachrichten

Geschützte und deduplizierte Daten [23.11.2020]

Die Purity-Betriebsumgebung für Pure Storage FlashArray unterstützt jetzt das mit Windows kompatible EncryptReduce. Es nutzt die Vormetric Transparent Encryption von Thales, um die Blockspeicherung auf FlashArray zu sichern, ohne die Vorteile der ständig aktiven Datendeduplizierungstechnologie im Array zu verlieren. [mehr]

Flash-Speicher für Hyperscale-Umgebungen [6.11.2020]

KIOXIA Europe hat sein Portfolio an Client-, Enterprise- und Rechenzentrums-SSDs um die Serie KIOXIA XD6 mit SSDs im Formfaktor E1.S erweitert. Die SSDs der XD6-Serie entsprechen dem E1.S-Standard und sind so auf die Anforderungen von Hyperscale-Anwendungen zugeschnitten, einschließlich der Performance-, Strom- und Kühlanforderungen der "NVMe Cloud SSD Specification" des Open Compute Projects. [mehr]

Datenbankjongleur [9.10.2020]

Tipps & Tools

Consumer vs. Enterprise-SSDs [14.11.2020]

Solid-State-Drives sind ja in zwei Varianten erhältlich: Client-SSDs für den Consumer-Bereich und Enterprise-SSDs für Server. Da der Preisunterschied doch recht groß ist, fragt sich so mancher Admin, ob er in weniger kritischen Speichersystemen auch die günstige Variante einsetzen kann. Deutliche Unterschiede sprechen jedoch dagegen. [mehr]

Energieverbrauch und Verlustleistung von Online-Storage [12.11.2020]

Getrieben von Trends wie Big Data und Industrie 4.0 wächst der Bedarf an schnellem und kostengünstigem Online-Storage rasant. Zu den wichtigsten Auswahlkriterien für Online-Speichersysteme gehören die Kosten, die Leistung, der Energieverbrauch und der Platzbedarf. Untersuchungen zeigen, dass es möglich ist, einen Online-HDD-Speicher mit einer Kapazität von 1 PByte mit einer Leistungsaufnahme von weniger als 500 Watt zu betreiben – und zwar mithilfe moderner 16-TByte-HDDs in einem vier Höheneinheiten großen JBOD. [mehr]

Buchbesprechung

Windows 10 Pannenhilfe

von Wolfram Gieseke

Anzeigen