Distributed File System (DFS)

Bei einer Distributed File System (DFS) Installation haben unsere Spezialisten wichtige Erfahrungen gesammelt.

Die Einführung von Microsoft Distributed File System (DFS, deutsch: verteiltes Dateisystem) ist in vielen Unternehmen Inhalt eines Migrations- oder Standardisierungs-Projektes. Häufig besteht das Vorurteil, dass es sich dabei nur um einen einfachen File Service handelt, welcher keine großen konzeptionellen Arbeiten voraussetzt. Ohne Plan und Konzept stellt sich meist jedoch nicht der gewünschte Erfolg ein, den man von DFS erwartet.

Grundlagen zu DFS-N und DFS-R

Das Produkt DFS besteht aus zwei voneinander unabhängigen Teilen.

• DFS-N Virtuelle Baumansicht mehrerer File Services (Tree)
• DFS-R Datenreplikation zwischen mehreren File Servern

Beide Produkte können völlig unabhängig voneinander eingesetzt werden. Ein DFS Tree setzt keine DFS Replikation voraus. Viel wichtiger ist jedoch die Erkenntnis, dass eine DFS Replikation auch ohne DFS Baum erfolgen kann.

DFS-N

Der DFS Tree ist die ursprüngliche Funktionsweise von DFS, bevor zusätzliche Funktionen wie die Replikation hinzugefügt wurden. Der DFS Tree fasst verteilte File Service Ressourcen zu einer abstrahierten Ansicht zusammen.

Die Planung eines Distributed File System Baumes setzt voraus, dass die Arbeitsweise der Mitarbeiter im Unternehmen bekannt ist. Der DFS Tree ist für den Endanwender sichtbar und wird seine tägliche Arbeit – hoffentlich positiv – beeinflussen.

Der Schnittpunkt zwischen dem DFS Baum und dem File Service ist die Dateisystem Freigabe (Share). Ein Ordner (Folder) im DFS Baum hat ein oder mehrere Ziele (Folder Targets). Diese entsprechen den Freigaben auf File Servern. Diese Freigaben müssen nicht unbedingt von Windows Servern bereitgestellt werden. Fast jede CIFS (common internet file system) basierte Freigabe kann in den DFS Baum eingebunden werden. Denkbar sind hier diverse NAS Filer, SAMBA Shares oder auch CIFS enabled NetWare Services. Dies gilt jedoch nur für den DFS Baum. Die Distributed File System Replikation setzt zwingend einen Windows Server voraus, da hier ein Microsoft Service installiert wird.

Eine wesentliche Funktion des DFS Baums ist das Umschalten zwischen DFS Folder Targets. Ein Distributed File System Ordner kann ein oder mehrere Shares als Ziel haben (Referrals). Diese Zielserver können sich an verschiedenen Standorten befinden. Der Distributed File System Client auf dem Microsoft Windows PC kann aufgrund der Sites und Services Information im Active Directory, das für ihn günstigste Folder Target auswählen. Diese auf Active Directory Sites und Services Kosten basierte Auswahl kann beeinflusst werden, indem die bevorzugende Folder Targets konfiguriert werden. Diese Einstellung weist alle Clients an, immer das gleiche Folder Target zu nutzen. Erst wenn das primäre Target nicht erreichbar ist, wird zum sekundären Ziel gewechselt.

An dieser Stelle kommt die DFS-R Replikation ins Spiel, denn der Wechsel zwischen Folder Targets ergibt nur einen Sinn, wenn sich dort identische Datenbestände befinden. Die DFS-R Replikation kann Daten zwischen mehreren Windows Servern synchronisieren und basiert auf einem hocheffizienten WAN optimierten Protokoll. Für den dynamischen Wechsel zwischen Folder Targets gibt es leider ein paar Einschränkungen. Das DFS-R Protokoll ist im Wesentlichen abhängig von der zur Verfügung stehenden Bandbreite und der Änderungsrate im Dateisystem. Änderungen werden in eine Warteschlange (backlog queue) gestellt und der Reihe nach abgearbeitet. Dies hat zur Folge, dass keine Replikation in einem gewissen Zeitfenster garantiert werden kann. Ein automatischer Schwenk zwischen Folder Targets kann dazu führen, dass Clients auf unterschiedliche Datenbestände zugreifen. Hier gibt es leider keine eindeutige Support-Aussage von Microsoft.

In einem aktuellen Projekt hat Microsoft den Support für ein Szenario mit zwei aktiven Folder Targets auf zwei per DFS-R synchronisierten Servern verweigert. Hier wurde das inaktive Folder Target deaktiviert und wird im Fehlerfall manuell aktiviert.

DFS-R

Die Datensynchronisation zwischen Windows Fileservern kann mit einem speziellen Übertragungsprotokoll erfolgen: DFS-R. Die DFS-R Replikation setzt keine DFS Baumstruktur voraus und ist von einer bestehenden Distributed File System Struktur unabhängig. Das mit DFS-R replizierte Verzeichnis kann sogar Unterverzeichnisse enthalten, welche in verschiedene DFS-Trees verlinkt sind.

WAN Optimierung für DFS-R

DFS-R wurde sehr stark für den Einsatz im WAN Umfeld optimiert. Im TCP RFC wurde eine maximale TCP Window Size von rund 64kByte festgelegt. Im Zusammenhang mit WAN Verbindungen, welche meist höhere Latenzzeiten aufweisen, stellt sich das 64kByte TCP Window als problematisch dar. Datenpakete müssen zunächst bestätigt werden, bevor weitere Pakete gesendet werden. Bei hohen Latenzzeiten führt dies dazu, dass der effektive Durchsatz stark einbricht. Mit RFC 1323 wurde die „TCP Window Scale Option“ eingeführt. Dies erlaubt eine Vergrößerung des TCP Window auf max 16MByte. Praktisch hat dies zur Folge, dass DFS-R sehr unempfindlich gegenüber Latenzzeiten ist. Bei Latenzzeiten von 500ms können noch bis zu 80% der Bandbreite ausgenutzt werden.

DFS-R Komprimierung

Das DFS-R Protokoll enthält den Komprimierungsalgorithmus RDC (Remote Differential Compression) um Übertragungsbandbreite einzusparen. RDC erkennt unter anderem Änderungen in Office Dokumenten und überträgt nur die Änderungen. Sobald einer der beiden Replizierungspartner mit der Enterprise Edition des Windows Servers betrieben wird, kommt die erweiterte Funktion Cross File RDC zum Einsatz. Sind Dateibestandteile bereits in anderen Dateien auf dem Zielserver vorhanden, nutzt Cross File RDC diese um die zu replizierende Datei lokal zu erzeugen. Bei einer Replikation von gewöhnlichen Office Dokumenten kann mit Cross File RDC eine Ersparnis von 50% – 80% erreicht werden.

Anhand eines Beispiels mit einem Word Dokument wird der Unterschied deutlich. Word speichert Änderungen während der Bearbeitung in einer temporären Datei. Beim Speichern wird daraus eine neue Datei erzeugt. Für das RDC Protokoll ist dies eine neue Datei. Die Änderungen sind nicht zu erkennen, die Datei wird komplett übertragen. Erst das Cross File RDC, welches mit der Enterprise Edition des Servers aktiv wird, kann hier unterstützen. Cross File RDC vergleicht die neue Datei mit bereits replizierten Dateien und setzt sie auf dem Zielserver aus bereits replizierten Teilen zusammen.

File Logging bei DFS-R

DFS-R ist eine Multi-Master Replikation. Änderungen können auf allen Replikationspartnern durchgeführt werden. Der File Logging Status der Dateien wird jedoch nicht repliziert. Wird ein Word Dokument auf beiden Replikationspartnern geändert, so gewinnt die Änderung mit dem aktuellsten Zeitstempel (last writer wins). Daher ist es in der Praxis nicht empfehlenswert mit mehreren für den Schreibzugriff aktivierten Replikationspartnern zu arbeiten. Ein gutes Beispiel für eine Read-Only Replikation ist das Sysvol Verzeichnis einer Active Directory Domain. Hier sind mehrere Replikationspartner für den Lesezugriff verfügbar, es kann keine Änderungskonflikte geben, da Sysvol Read-Only ist. Andere Anwendungsbeispiele sind HUB/SPOKE Implementationen, welche zur Datensicherung genutzt werden. Der SPOKE Server ist für den Schreibzugriff aktiviert, der HUB Server empfängt Änderungen und hat selbst kein aktives Folder Target.

DFS Implementierung

Das gilt es beim Einsatz eines DFS Baumes zu beachten

Der häufigste Anwendungsfall ist der Einsatz eines DFS Baumes, um den Zugriff auf verteilte Fileservice Ressourcen für den Endanwender einfacher zu gestalten. Die DFS-R Replikation kommt häufig zum Einsatz, um die Datensicherung an verteilten Standorten ohne lokale Backup-Infrastruktur zu lösen.

Wichtig beim Design eines DFS Baums ist es, die Arbeitsweise der Endanwender zu kennen. Ein gutes Beispiel ist ein DFS Baum für ein Unternehmen, welches über viele Standorte verteilt ist. Ohne DFS werden Netzwerklaufwerke auf die File Server an den jeweiligen Standorten verbunden. Die dafür nötigen UNC Pfade sind für die meisten Endanwender nur schwer verständlich und lassen sich schlecht merken. Ein DFS Baum kann diese UNC Pfade zu einer abstrakten Baumansicht zusammenfassen und für den Endanwender transparent machen. Der nächste Designschritt fasst zusammengehörige Daten zu virtuellen Knotenpunkten zusammen.

Fallbeispiel

Die Marketingabteilung unseres Beispielunternehmens arbeitet an verschiedenen Standorten:

• Hamburg,
• Frankfurt und
• München.

Ein virtueller DFS Ordner „Marketing“ hat Unterordner mit den Namen der Standorte. Diese zeigen wiederum, für den Anwender transparent, auf die File Server an den Standorten. Somit sind alle Daten der Marketing Abteilung für die Endanwender transparent in einem Knoten zusammengefasst.

Vorsicht ist geboten bei der Auswahl der Ordnernamen. Abteilungskürzel eignen sich in der Regel nicht, da jede Reorganisation eine Anpassung des DFS Baumes zur Folge hätte.

Nun kommt DFS-R ins Spiel. Die IT Infrastruktur an den Außenstandorten soll konsolidiert werden. Im Fokus der Konsolidierung sind die lokalen Backup Server. DFS-R soll genutzt werden, um die Daten in die Zentrale zu replizieren, wo sie gesichert werden. Wichtigster Planungsbaustein ist hier die zu erwartende Änderungsrate. Ein guter Anhaltspunkt kann hier eine Auswertung der vergangen täglichen inkrementellen Datensicherungen sein. Überschlagsrechnung: für die Replikation von 500GByte Daten mit einer täglichen Änderungsrate von 3% und einer Einsparung durch RDC von 50% würde eine dauerhafte durchschnittliche Bandbreite von 0,7 MBit/s benötigt.

In unserem DFS Beispiel sollen die Daten nach Frankfurt repliziert werden. Ein Augenmerk sollte man auf die Eingangsleistung der WAN Anbindung in der Zentrale setzen. Die Eingangsbandbreite sollte mindestens die Summe der Uploads aller zugeordneten Standorte betragen. In Bezug auf Cross File RDC würde sich hier anbieten den DFS Server in der zentrale mit Enterprise Edition Betriebssystem auszustatten. Dies würde dazu führen, dass die beiden DFS Server in Hamburg und München mit Cross File RDC replizieren obwohl sie ohne Enterprise Edition Serverbetriebssystem installiert wurden. Zur Erhöhung der Verfügbarkeit beim Ausfall eines Servers in einem dezentralen Standort wie Hamburg oder München werden zusätzliche DFS Folder Targets konfiguriert. Diese Referrals zeigen auf die mit DFS-R in die Zentrale replizierten Daten. Diese Links werden konfiguriert, bleiben aber inaktiv und werden im Fehlerfall manuell aktiviert. Zum einen um die unsichere Support Frage zu umgehen und zum anderen um ein unkontrolliertes dynamisches Umschalten zu verhindern.

Die Mitarbeiter der Marketing Abteilung haben transparenten Zugriff auf alle Daten ihrer Abteilung, unabhängig davon, an welchem Standort sie sich befinden. Zusätzlich wird die Verfügbarkeit des File Service erhöht, indem die Daten in die Zentrale repliziert werden und im Fehlerfall DFS Links dorthin aktiviert werden. Abschließend kann Backup Infrastruktur an den Außenstandorten eingespart werden, da die Daten mittels DFS-R zur Sicherung in die Zentrale repliziert werden.

Einführung von DFS – Distributed File System

Wir bieten Ihnen gerne Unterstützung bei der Planung und Implementierung von DFS an.
Unsere Consultants sind seit vielen Jahren im Microsoft-Umfeld spezialisiert.