Wer kennt nicht das Problem, Dateien an mehreren Standorten synchron zu halten? Ab Windows Server 2003R2 gibt es eine einfache und gut skalierbare Technologie die dies ermöglicht. Das “Distributet File System”, kurz DFS, das bereits seit NT4 teil von NT Server ist, wurde in WindowsServer2003 R2 gründlich überarbeitet. Replikation sollte jeder vom AD her kennen, allerdings brachte es bei größeren Ordnern mehr Probleme als es nützte. R2 enthält eine völlig überarbeitete Version der Replikationsdienste. Innerhalb eines AD Forrest können Daten zwischen belibigen Servern bidirektional repliziert werden. Die Konfiguration erfolgt über die ebenfalls neue DFS-Verwaltung. Die Replikation nutzt eine vom AD unabhängige Replikationstopologie, was die Skalierbarkeit extrem erhöht. Die Technologie basiert auf Replikationsgruppen, diesen können Zeit und Bandbreitenpläne zugewiesen werden. Ist die Gruppe erstellt, fügt man die in dieser Gruppe beteiligten Server hinzu, konfiguriert die Verbindungen (entweder eine vorgegebene Topologie, oder manuell) und fügt der Gruppe replizierte Ordner hinzu. Dabei muss nicht jedes Mitglied in der Gruppe ein replikat jedes Ordners enthalten, auch hier ist man wieder völlig flexiebel. So kann man zb. 20 Server aus 20 Standorten in einer Gruppe hinzufügen und von jedem einen Ordner an einen Zentralen Standort replizieren ODER einen Ordner am Zentralem standort pflegen und auf alle 20 Server an 20 Standorten replizieren. Auch das Mischen dieser Methoden ist möglich. So kann zb. ein Ordner auf den Servern 1-15, ein weiterer auf 16-20 und wieder ein anderer Ordner auf allen Servern verfügbar gemacht werden. Und das alles in einer Replikationsgruppe mit einem Gruppenzeitplan und einer Topologie. Mehrere Topologien machen nur bei verschiedenen Anwendungen Sinn. Zb. kann man eine Gruppe mit einer Hub-Sproke Topologie konfigurieren, um Dateien von und an Remotestandorte von einem Zentralem Hub aus zu verteilen und eine weitere als Full-Mesh zur Standort-zu-Standort Replikation nutzen. Benutzerdefinierte Topologien eignen sich am besten, wenn nicht jeder Standort nur mit dem Hub, sondern auch mit anderen Standorten verbunden ist. Die Technologie selbst verwendet eine Forrestweite AD-Partition zur Ablage der Konfiguration sowie XML-Dateien auf den einzelnen Knoten. Die Kommunikation erfolgt über Dynamische RPC’s, kann aber auf einen Port eingegrenzt werden (Firewallfreundlicher, aber langsamer). Zur änderungserkennung wird NTFS Journaling verwendet, die Datenbank verwendet das vom NTFRS bekannte ESE.
Was allerdings noch fehlt, ist ein Standortübergreifender Dateio-locking Mechanismus. So müsste es zb. möglich sein, Dateien an Remotestandorten zum schreiben zu öffnen und diese am Zentralem Hub zu sperren das während der Bearbeitung bzw. Replikationsverzögerung kein anderer diese Datei ändern kann. Mit einer solchen Technologie könnte man Standortübergreifendes Arbeiten extrem vereinfachen. Ich bastle gerade mit dem Einfall, die Ordner über einen speziellen Explorer am Client anzeigen zu lassen und beim öffnen einer Datei, diese am Hub in einer Datenbank als “gesperrt” zu markieren. Sobald nun ein weiterer User an einem anderem Standort diese versucht zu öffnen, prüfe der “explorer” ob der Hash der Datei dem in der Datenbank gleicht und falls nicht (was bedeuten würde das die Replikation an diesem Standort noch nicht abgeschlossen ist) kann diese Datei nur schreibgeschützt oder unter einer neuen Version geöffnet werden. Das ganze ist noch reine Theorie, aber evt. finden sich ja Programmierer die so etwas umsetzen können.
Ansonsten kann ich nicht viel an der Technologie aussetzen. Die Replikation von 2 TB (ca. 1Mio. Files) über mehrere Standorte in unterschiedlichen Domänen (ein Forrest) ist absolut kein Problem und funktioniert durch die komprimierung (Remote Differential Compression, RDC) sehr schnell und zuverlässig. DFSR wird übrigends ebenfalls Bestandteil von Windows Server 2008.
Fazit: Empfehlenswert