15.4 Verteiltes Dateisystem – Distributed File System (DFS)

Eine sehr interessante Möglichkeit im Windows-Umfeld ist DFS, das verteilte Dateisystem (Distributed File System). Viele Administratoren denken beim Stichwort DFS vor allem an »verschiedene Server unter einer Freigabe«, was ja auch durchaus richtig ist. Da DFS aber viel universeller eingesetzt werden kann, wird dieser Abschnitt zunächst einige planerische Aspekte vorstellen und dann die Konfiguration eines Szenarios zeigen.

15.4.1 Grundfunktion

Die Grundfunktion von DFS ist die Bereitstellung von Freigaben unterschiedlicher Server unterhalb einer gemeinsamen Freigabe.

Abbildung 15.51 zeigt ein Beispiel. In diesem Szenario ist jedes Jahr ein neuer Dateiserver aufgesetzt worden – vielleicht kein ganz realistisches Szenario, aber Sie erkennen, wie DFS funktioniert:

• Der Client verbindet sich mit dem DFS-Root. Im Fall eines Domänenstammes ist dies der Name der Domäne und des DFS-Stammes, also \\alpha.intra\Daten .
• In dieser Freigabe sieht man diverse Unterverzeichnisse, die jeweils auf die Freigabe eines Servers verweisen.
• Datenpfade: Der Zugriff auf die Daten des Dateiservers erfolgt direkt – nicht über den Server, der den DFS-Root führt.

Abbildung 15.51 DFS im Einsatz: Freigaben verschiedener Server werden unterhalb einer DFS-Freigabe gefunden.

Die Freigaben, auf die verwiesen wird, müssen übrigens nicht zwingend Windows-Server sein. Prinzipiell wäre hier auch eine NetWare- oder NFS-Share möglich. Allerdings müssen alle Clients, die zugreifen sollen, das entsprechende Protokoll unterstützen, also beispielsweise über NFS-Client-Software verfügen.

Betriebsmodi

Unter der Voraussetzung, dass ein Active Directory in Ihrer Umgebung vorhanden ist, können Sie einen Domänenstamm oder einen eigenständigen Stamm erstellen:

• Auf einen DFS-Domänenstamm greifen Sie wie in dem zuvor gezeigten Beispiel zu, also über \\domain.int\stammname.
• Ein »eigenständiger Stamm« ist immer an »seinem« Server aufgehängt. Der Zugriff erfolgt über \\computername\stammname.

Die Verwendung eines Domänenstammes bietet einige Vorteile, insbesondere in Hinblick auf Redundanz und Replikation. Ein paar Zeilen später erfahren Sie mehr über die dahinterstehenden Konzepte.

Voraussetzungen

In Tabelle 15.1 ist aufgetragen, welche Betriebssysteme als DFS-Client, -Root oder -Ziel verwendet werden können. Kurz zu den Begrifflichkeiten:

• DFS-Client: Diese Betriebssysteme können als Client auf DFS-Shares zugreifen.
• DFS-Root: Ein DFS-Root ist der primäre Anlaufpunkt, wenn ein Client auf eine DFS-Struktur zugreifen möchte.
• DFS-Ziel: Diese Server stellen Ressourcen (Freigaben) innerhalb des DFS-Stammes zur Verfügung.

Tabelle 15.1 Betriebssysteme als DFS-Client, -Root und -Ziel

Betriebssystem	DFS-Client	DFS-Root	DFS-Ziel
Windows Server 2008/R2/2012/R2	Ja	Ja	Ja
Windows Vista/7/8/8.1	Ja	Nein	Ja
Windows Server 2003 (Web, Standard, Enterprise, Datacenter)	Ja	Ja	Ja
Windows XP	Ja	Nein	Ja
Windows 2000 Server	Ja	Ja	Ja
Windows 2000 Professional	Ja	Nein	Ja
Windows NT4 Server	Ja	Ja (kein Domain-Mode)	Ja
Windows NT4 Workstation	Ja	Nein	Ja
Windows 98/Me	Ja (kein Domain-Mode)	Nein	Ja

15.4.2 DFS und DFS-Replikation

Abbildung 15.52 Eine DFS-Verknüpfung verweist auf mehrere inhaltsgleiche Dateifreigaben.

Einige interessante Nutzungsmöglichkeiten bietet die Kombination aus DFS und der DFS-Replikation. Das Grundprinzip ist simpel (Abbildung 15.52):

• Eine DFS-Verknüpfung verweist nicht nur auf ein Ziel, sondern auf mehrere Ziele, die auf verschiedenen Servern zu finden sind; es wird also auf mehrere Freigaben verwiesen.
• Durch geeignete Maßnahmen werden die Freigaben synchron gehalten.

15.4.3 Ausfallsicherheit

Generell ist in einer IT-Umgebung die Ausfallsicherheit eines der wichtigsten Merkmale. Klassischerweise verwendet man einen Cluster, um die Verfügbarkeit von Fileservern zu erhöhen. Das Distributed File System (DFS) kann durchaus eine Alternative sein, denn auch hiermit lassen sich redundante Umgebungen aufbauen.

Wenn Sie die vorherigen Abschnitte gelesen haben, wird Ihnen klar sein, dass DFS an zwei Stellen empfindlich bzw. gefährdet ist:

• am DFS-Root, also an der »Anlaufstelle« der Clients, an denen überhaupt die über DFS bereitgestellten Ziele dargestellt werden
• an den DFS-Zielen (d. h. den Freigaben auf den Servern) selbst

Damit Sie die Architektur von domänenbasiertem DFS besser verstehen können, habe ich die bisherigen Zeichnungen ein wenig erweitert (Abbildung 15.53) und beschreibe nochmals den Zugriff des Clients:

• Der Client ermittelt durch eine Active Directory-Anfrage den nächstgelegenen DFS Root-Server. Ist ein DFS Root-Server nicht verfügbar, suchen die Clients einen weiteren.
• DFS leitet die Clients nun zu den DFS-Zielen (Targets), also den Servern mit den entsprechenden Freigaben. Wenn ein solcher Server ausfällt, leitet DFS die Clients zu einem Server, dessen Freigabe als DFS-Target für dieselbe DFS-Verknüpfung konfiguriert ist.

Die Voraussetzungen für eine redundante Dateiserver-Umgebung mit DFS sind:

• Verwendung eines DFS-Domänenstamms
• Redundante Active Directory-Domänencontroller: Steht kein Active Directory zur Verfügung, finden die Clients gar nichts!
• Redundante DFS-Roots: Dies kann im DFS-Snap-In konfiguriert werden (die DFS-Roots könnten beispielsweise von den Domänencontrollern bereitgestellt werden). Wichtig: Roots für domänenbasiertes DFS können nicht auf Clustern liegen!
• Redundante DFS-Ziele: Für jede DFS-Verknüpfung müssen mindestens zwei Ziele (also Dateiserver mit entsprechenden Freigaben) eingerichtet werden, die optimalerweise durch DFS-Replikation synchron gehalten werden.

Abbildung 15.53 Zugriff auf einen domänenbasierten DFS-Stamm

Bei der Bewertung der Verfügbarkeit während eines schweren Störfalls schneidet diese Umgebung übrigens recht gut ab, da die Daten tatsächlich redundant vorhanden sind. Wichtig ist natürlich, dass die replizierten DFS-Ziele (Server mit Freigaben) in Räumen stehen, die zu verschiedenen Brandabschnitten gehören. Ebendies gilt natürlich auch für Domänencontroller und DFS-Roots.

15.4.4 Verteilen von Daten – standortübergreifendes DFS

In einer Organisation, die über mehrere Standorte verteilt ist, könnte es Datenbereiche geben, auf die alle Benutzer zugreifen müssen: beispielsweise auf Formulare aller Art, auf Produktdokumentationen, Richtlinien etc.

Da es nun recht unschön wäre, wenn die Benutzer in den Außenstandorten jeweils über WAN-Strecken auf die Zentrale zugreifen müssten, könnte man mit DFS und DFS-Replikation die Daten auf Server an den jeweiligen Standorten bringen.

In Abbildung 15.54 ist eine entsprechende Landschaft gezeigt: Jeder Standort verfügt über einen Domänencontroller, einen DFS-Root und einen Dateiserver als DFS-Ziel.

Abbildung 15.54 Verteilte Umgebung mit jeweils einem DFS-Root und DFS-Ziel (DFS Target) an den Standorten

Die DFS-Ziele, die unterhalb einer DFS-Verknüpfung definiert sind, werden über die DFS-Replikation synchron gehalten. Anmerkung: Es ist sehr wichtig, dass Sie im Vorfeld genau den zu erwartenden Verkehr (d. h. das Volumen der Änderungen) analysieren, damit Sie die WAN-Strecken nicht zu stark belasten.

Unter der Voraussetzung, dass jeder Standort als separater Active Directory-Standort (Site) definiert ist, gelten folgende Aussagen:

• Der Benutzer wird jeweils zu dem DFS-Root an seinem Standort geführt.
• Der Benutzer wird jeweils zu dem DFS-Ziel (Freigabe auf Fileserver) an seinem Standort geführt.
• Falls DFS-Root oder DFS-Ziel ausfallen, gibt es zwei Möglichkeiten:
  • Sofern ein weiterer Server am Standort vorhanden ist, wird der Benutzer auf diesen geleitet.
  • Ist kein weiterer Server am Standort, wird der Benutzer zu einem Server an einem entfernten Standort geführt.

Die Replikation funktioniert in alle Richtungen, was bedeutet, dass auf allen Servern Dateien geändert werden können und diese dann auf die anderen DFS-Ziele repliziert werden. Sofern eine Datei auf zwei Servern geändert wird, »gewinnt« die Datei mit dem jüngeren Datum. Dieses Verhalten bietet durchaus Potenzial für Datenverlust! Durch organisatorische Maßnahmen sollte also sichergestellt sein, dass bei replizierten Dateisystemen klar geregelt ist, welche Benutzer Dateien ändern dürfen! Das gilt letztendlich für jedes Dateisystem. In replizierten Umgebungen ist aber die Wahrscheinlichkeit wesentlich höher, dass entsprechende Problemsituationen auftreten!

15.4.5 Sicherung von Daten

Quasi ein »Abfallprodukt« der zuvor geschilderten Vorgehensweise der standortübergreifenden Verwendung von DFS ist die Möglichkeit, die Daten der Außenstellen auf Dateiserver in der Zentrale zu replizieren und dort zu sichern. Der Vorteil hierbei wäre, dass Sie auf eine Bandsicherung der Produktivdaten in den Außenstellen verzichten könnten – zumindest, was die Dateifreigaben betrifft!

Die Vorgehensweise ist einfach:

• Richten Sie einen Domänen-DFS-Stamm ein. In den Standorten sollte jeweils ein DFS-Root vorhanden sein.
• Legen Sie für die Dateifreigaben der Standorte jeweils Verknüpfungen im DFS-Stamm an.
• Legen Sie die Dateifreigabe des Standorts und eine Dateifreigabe in der Zentrale als DFS-Ziel an, und richten Sie die Replikation mittels DFS-Replikation ein.
• Sichern Sie die Dateifreigabe in der Zentrale im Rahmen der »normalen« Datensicherung der Zentrale.

Bei diesem Konzept gibt es einige Dinge zu beachten:

• Auch wenn Sie die Produktivdateien nicht in der Außenstelle sichern müssen, müssen Sie dennoch ein Wiederherstellungskonzept für die Server vorhalten.
• Datenbanken (z. B. Exchange, SQL) lassen sich über die DFS-Replikation nicht sichern. Diese sind schließlich stets offen und werden deswegen nicht von der Replikation erfasst. Sie könnten natürlich die Datenbanken nachts in das Dateisystem sichern. Wenn diese Datenbanken allerdings »groß« sind, werden eventuell mehrere Hundert Megabyte über eine schmalbandige WAN-Strecke geschoben – das ist nicht so glücklich. Ansonsten gilt: Planen Sie ein Wiederherstellungskonzept, und testen Sie es!
• Sollte der Dateiserver oder der DFS-Root ausfallen, werden die Clients automatisch auf die entsprechenden Server in der Zentrale zugreifen. Ein »Mini-Störfallkonzept« ist also bereits integriert.

15.4.6 DFS installieren

Die eigentliche Installation von DFS ist unkompliziert. Letztendlich müssen Sie lediglich die Rollendienste des verteilten Dateisystems installieren (Abbildung 15.55).

Abbildung 15.55 Fügen Sie diese Rollendienste hinzu, um DFS zu verwenden.

Alle weiteren Einstellungen werden mit dem Verwaltungswerkzeug aus Abbildung 15.56 durchgeführt. Im Gegensatz zur Situation bei Server 2008/R2 erledigt der Installationsassistent unter Server 2012/R2 keine grundlegenden Konfigurationsarbeiten.

Abbildung 15.56 Die Administration erfolgt später im DFS-Verwaltungs-Snap-In.

15.4.7 Basiskonfiguration

Die Konfiguration von DFS ist nicht schwierig. Die Arbeiten werden mit einem Snap-In für die Microsoft Management Console vorgenommen.

Namespace konfigurieren

Die Konfigurationsarbeiten im DFS-Verwaltungs-Werkzeug beginnen mit dem Hinzufügen eines Namespace. Wie bereits zuvor beschrieben, ist dieser Namespace der virtuelle Bereich, unter dem alle unter DFS bereitgestellten Freigaben zu finden sind.

In Abbildung 15.57 ist zu sehen, dass neben dem Erstellen eines neuen Namespace weitere Funktionen zur Verfügung stehen, nämlich das Hinzufügen eines bestehenden Namespace oder die Delegierung von Verwaltungsberechtigungen.

Im ersten Dialog des Assistenten müssen Sie einen Server auswählen, der der Namespaceserver werden soll. Dieser stellt sozusagen die Wurzel der Freigabe bereit, unterhalb der dann die Freigaben der übrigen Server eingehängt werden. Dieser Server muss drei Voraussetzungen erfüllen:

• Er muss mit einem Serverbetriebssystem laufen, beispielsweise Windows Server 2012, 2008; alternativ sind Windows 2000 Server und Windows Server 2003 möglich, natürlich auch die Clients XP/Vista/7/8/8.1. Freigaben von Clientbetriebssystemen (Vista/7/8/8.1, XP etc.) können zwar integriert werden, ein Rechner mit einem Clientbetriebssystem kann allerdings nicht Namespaceserver werden.

  

  Abbildung 15.57 Die DFS-Konfiguration beginnt mit dem Erstellen eines neuen Namespace.

• Die DFS-Funktionalität muss auf dem Server installiert werden. Sie findet sich in der Rolle Dateiserver.
• Der DFS-Dienst muss ausgeführt werden. Das Starten des Diensts kann vom Assistenten erledigt werden (Abbildung 15.58).

Wenn der Namespaceserver ausgewählt und betriebsbereit ist (d. h., der DFS-Dienst läuft), wird der Name des DFS-Namespace angegeben. Unter diesem sind alle untergeordneten Freigaben zu erreichen.

Für die Wurzel der Freigabe (also z. B. \\ubexec.ads.boddenberg.de\projekte) muss ein freigegebener Ordner existieren, auf den im Normalfall alle Benutzer nur Leseberechtigung haben sollten (Abbildung 15.59). Schließlich sollen die Daten in den untergeordneten Freigaben gespeichert werden und nicht im Wurzelverzeichnis. Trotzdem muss dieses existieren. Standardmäßig wird auf dem Namespaceserver unterhalb von c:\DFSRoots ein Verzeichnis mit dem Namen des DFS-Namespace angelegt und freigegeben. Wie in Abbildung 15.59 zu sehen ist, können Sie den Speicherort und die Rechte, mit denen er freigegeben wird, anpassen. Im Normalfall sollte dies aber nicht notwendig sein. Um es nochmals zu betonen: In diesem Verzeichnis sollen keinerlei Daten gespeichert werden, es ist »einfach nur da«.

Abbildung 15.58 Wenn der DFS-Dienst auf dem ausgewählten Server noch nicht läuft, kann der Assistent ihn starten.

Abbildung 15.59 Der Name des DFS-Namespace und einige Einstellungen für den obersten Ordner werden mit diesem Dialog festgelegt.

Der nächste Konfigurationsschritt ist das Festlegen des Typs des Namespace. Zur Auswahl stehen (Abbildung 15.60):

• Domänenbasierter Namespace: Der Vorteil dieses Typs ist, dass ein solcher DFS-Namespace nicht an einen bestimmten Server gebunden ist und somit relativ einfach redundant ausgelegt werden kann.
• Eigenständiger Namespace: Dieser Typ ist fest einem Server zugeordnet, kann also auch verwendet werden, wenn ein Active Directory nicht zur Verfügung steht. Um einen solchen DFS-Namespace redundant auszulegen, müsste der Server geclustert werden.

Abbildung 15.60 Hier legen Sie fest, ob Sie einen domänenbasierten oder einen eigenständigen Namespace anlegen möchten.

Im Allgemeinen wird man einen domänenbasierten Namespace wählen, sodass der DFS-Stamm Projekte über \\ubinf.intra\Vertrieb aufgerufen wird.

Ordner anlegen

Nachdem der DFS-Namespace angelegt ist, müssen Sie Ordner anlegen. Ein DFS-Ordner ist, wie bereits zu Beginn dieses Abschnitts beschrieben wurde, eine Dateifreigabe eines anderen Servers. Um einen neuen Ordner anzulegen, rufen Sie im Kontextmenü des Namespace die entsprechende Funktion auf (Abbildung 15.61).

Abbildung 15.61 Ein neuer DFS-Ordner wird im Namespace angelegt.

Das Anlegen eines neuen DFS-Ordners ist nahezu trivial, wie Sie in Abbildung 15.62 sehen können. Sie tragen einen Namen für diesen DFS-Ordner ein und fügen die Dateifreigaben hinzu, auf die verwiesen werden soll (Ordnerziele). Sie können auf mehrere Dateifreigaben verweisen. Dies wird weiter unten in Abschnitt 15.4.8, »Konfiguration der Replikation«, besprochen.

Abbildung 15.62 Das Anlegen eines neuen DFS-Ordners

An dieser Stelle möchte ich nochmals deutlich betonen, dass die DFS-Clients direkt auf die Ziel-Dateifreigabe geleitet werden: Der eigentliche »Nutzdatenstrom« läuft nicht über den Namespaceserver oder eine andere DFS-Komponente. Prinzipiell kann in einem DFS-Ordner auch auf eine NFS-Share (oder Netware-Share etc.) verwiesen werden. In diesem Fall benötigt der zugreifende Client eine geeignete NFS-Clientsoftware. DFS übernimmt keine »Übersetzungsarbeit«.

Abbildung 15.63 Ist der freigegebene Ordner auf dem Zielserver nicht vorhanden, bietet der Assistent direkt die Erstellung der Freigabe an.

DFS im Active Directory

In dem zuvor gezeigten Beispiel ist ein domänenbasierter Namespace angelegt worden. Somit dürfte ein Blick hinter die Kulissen nicht uninteressant sein, um die »Mechanismen« ein wenig genauer zu verstehen. »Mechanismen« bedeutet in diesem Fall, dass das Active Directory Ziel der Betrachtung wird. Um dem AD einige Interna zu entlocken, kommt wie immer ADSI-Editor zum Einsatz.

Die domänenbasierten Namespaces finden sich im Domänennamensraum im Container System und dort unterhalb von Dfs-Configuration. In Abbildung 15.64 ist dies zu sehen: Dort sind die Eigenschaften des Namespace Projekte angezeigt.

Abbildung 15.64 Die Namespaces werden im Domänennamensraum des Active Directory gespeichert.

Wenn ein Client einen Ordner im Namespace \\ubinf.intra\Projekte aufruft, wird in dem Domänennamensraum des Active Directory der entsprechende Eintrag gesucht – und werden die weiteren Schritte unternommen. Die Liste der Dateifreigaben finden Sie übrigens im Attribut remoteServerName.

DFS-Informationen sind des Weiteren unterhalb von DFSR-GlobalSettings zu finden. Hier finden sich die Informationen zur Replikation zwischen den Fileshares eines Ordners.

Zugriff!

Nun werde ich Ihnen vorführen, wie ein Client auf einen DFS-Namespace zugreift. In diesem Beispiel wird auf einen domänenbasierten Namespace zugegriffen, der zwei DFS-Ordner enthält (Abbildung 15.65; in der Abbildung ist übrigens noch zu sehen, dass pro Ordner ein recht umfangreiches Kontextmenü vorhanden ist).

Abbildung 15.65 Der DFS-Namespace, auf den in diesem Beispiel zugegriffen wird, enthält zwei Ordner.

Um auf einen DFS-Namespace zuzugreifen, beginnen Sie mit dem Zuordnen eines Netzlaufwerks. Streng genommen wäre dieser Schritt nicht notwendig, ein zugeordnetes Netzlaufwerk ist für Benutzer allerdings einfacher zu handhaben als »nur« ein in der Netzwerkumgebung vorhandener Verweis auf einen Netzwerkspeicherort. Das in Abbildung 15.66 gezeigte Windows 8.1 verfügt über einen integrierten DFS-Client, der einen »nahtlosen« Zugriff auf einen DFS-Namespace ermöglicht. Das heißt, der Benutzer bemerkt keinen Unterschied zwischen Ressourcen, die via DFS bereitgestellt wurden, und solchen, die »konventionell« bereitgestellt wurden.

Abbildung 15.66 Der erste Schritt für den Zugriff auf einen DFS-Namespace ist das Zuordnen des Netzlaufwerks (hier unter Windows 8.1).

Abbildung 15.67 Beim Zuordnen eines Netzwerkordners gibt es keinerlei Unterschied zwischen einer »normalen« Fileshare und einer DFS-Ressource.

Abbildung 15.68 DFS ist für den Benutzer völlig transparent, d. h., der Benutzer merkt nicht, dass DFS verwendet wird.

Anzumerken wäre, dass Clientbetriebssysteme ab Windows 2000 auf DFS zugreifen können. NT4 Workstation kann dies prinzipiell auch, mit diesem Betriebssystem ist aber kein Zugriff auf einen domänenbasierten DFS-Namespace möglich.

Bei dem in Abbildung 15.67 gezeigten Zuordnen eines Netzwerkordners wird als Ordner der Name des DFS-Namespace angegeben. Bei einem domänenbasierten Namespace wird der Domänenname dem Namespacenamen vorangestellt. In einem eigenständigen DFS-Namespace wird stattdessen der Servername vorangestellt.

Abbildung 15.68 ist der Beweis, dass DFS für den Benutzer völlig transparent ist. Das Laufwerk Z: ist mit dem Namespace Projekte verbunden. Innerhalb des Namespace finden sich zwei Ordner, die auf eine Dateifreigabe verweisen. Die Dateifreigaben können auf unterschiedlichen Servern liegen, wovon der Benutzer nichts merken wird.

15.4.8 Konfiguration der Replikation

Der eine Vorteil von DFS ist die Bereitstellung von Freigaben unterschiedlicher Server innerhalb eines Namensraums, der zweite große Vorteil ist, dass die Daten redundant gespeichert werden können – dass also ein DFS-Ordner über beliebig viele Server repliziert wird. Hier sind verschiedene Anwendungsfälle denkbar, die von doppelter Datenhaltung bis zu Sicherungskonzepten reichen, bei denen die Daten der Niederlassungen in die Zentrale konsolidiert und dort gesichert werden.

Das DFS-Management-Werkzeug verfügt über einen Knoten Replikation, unterhalb dessen neue Replikationsgruppen angelegt und bestehende verwaltet werden können.

Wir immer führen mehrere Wege zum Ziel. In diesem Fall ist das Ziel die Einrichtung der Replikation zwischen zwei oder mehr Servern, die beide bzw. alle die Daten eines DFS-Ordners speichern sollen. Genauer gesagt bedeutet es, dass jeder dieser Server über eine Dateifreigabe verfügt, die mit einer Dateifreigabe eines oder beliebig vieler anderer Server repliziert werden soll.

Die beiden möglichen Vorgehensweisen sind:

• Sie wählen in der DFS-Verwaltung gezielt das Anlegen einer neuen Replikationsgruppe aus (Abbildung 15.69).
• Alternativ können Sie eine neue Replikationsgruppe aus dem Kontextmenü eines DFS-Ordners erstellen (Abbildung 15.70).

Der zweite Weg ist generell einfacher, da Sie etwas weniger Einstellungen vornehmen müssen. In Abbildung 15.70 ist ansonsten zu erkennen, dass für den Ordner bereits mehrere Freigaben angelegt sind – sonst wäre ja auch keine sinnvolle Replikation möglich.

Abbildung 15.69 Sie können entweder die Erstellung einer »Neuen Replikationsgruppe« aus diesem Kontextmenü aufrufen ...

Abbildung 15.70 ... oder den Assistenten aus dem Kontextmenü des DFS-Ordners starten.

Wir werden nun kurz einen Blick auf den Assistenten werfen, mit dem die DFS-Replikation eingerichtet wird. Auf dem ersten Screenshot (Abbildung 15.71) ist zu erkennen, dass Sie zunächst einen Namen für eine Replikationsgruppe und den Namen des zu replizierenden Ordners eintragen müssen. Die »richtigen« Werte sind vorbelegt, wenn der Assistent über den Menüpunkt aus Abbildung 15.70 gestartet wird.

Abbildung 15.71 Auf der ersten Dialogseite führen Sie lediglich einige grundlegende Arbeiten durch.

Auf der zweiten Dialogseite wird überprüft, ob die potenziell an einer zukünftigen Replikation beteiligten Server überhaupt dazu bereit sind. Die Server werden aus der DFS-Konfiguration ermittelt. Es werden die Server angezeigt, die in der Konfiguration des DFS-Ordners eingetragen sind (Abbildung 15.72).

Abbildung 15.72 Der Assistent prüft, ob die für die Replikation benötigten Server dafür konfiguriert sind.

Nun kann (bzw. muss) ein Server für den Replikationsprozesses als primäres Mitglied definiert werden. Dies geschieht ganz einfach mittels der Combobox in dem Dialog aus Abbildung 15.73.

Abbildung 15.73 Für die Replikation muss ein Server als primäres Mitglied festgelegt werden.

In vielen Fällen existiert bereits ein Server, auf dem die entsprechende Freigabe mit Daten »gefüllt« ist; dieser sollte bzw. muss dann als primäres Mitglied ausgewählt werden.

Diese Einstellung hat keinen Einfluss darauf, dass im »normalen« Betrieb die Replikation bidirektional erfolgt.

Der nächste Dialogschritt bezieht sich auf die Topologie, die für die Replikation zwischen den Dateifreigaben erzeugt wird, die gemeinsam einen DFS-Ordner bilden. Es gibt drei Möglichkeiten (Abbildung 15.74):

• Nabe und Speiche (Hub and Spoke): Eine solche Topologie könnte sinnvoll sein, wenn alle Daten von einem Server in der Firmenzentrale ausgehen. Diese Topologie ist in der Abbildung nicht anwählbar, da in unserem Beispiel lediglich zwei Server vorhanden sind – zu wenige, um eine solche Topologie aufzubauen.
• Vollständig vermaschtes Netz (Full Mesh) bezeichnet die Vermaschung aller an der Replikation beteiligten Server, d. h., jeder repliziert mit jedem. Die Struktur ist nur bis zu einer gewissen Obergrenze von Servern sinnvoll anzuwenden. Der von Microsoft angegebene Wert liegt bei 10.
• Keine Topologie bedeutet schlicht und ergreifend, dass der Administrator die Replikationstopologie später manuell erzeugen muss.

Abbildung 15.74 Die Replikationstopologie wird festgelegt.

Zur Konfiguration einer Replikation gehören auch die Aspekte der nutzbaren Bandbreite und der Zeitfenster, die für die Replikation verwendet werden. Abbildung 15.75 zeigt die Einstellmöglichkeiten:

• Die erste Option bewirkt, dass kontinuierlich beim Auftreten einer Änderung repliziert wird, wobei die maximal zu verwendende Bandbreite festgelegt werden kann.
• Die zweite Variante gestattet die Eingabe eines Replikationszeitplans. Wenn beispielsweise nur in der Nacht repliziert werden soll, kann das in der Konfiguration entsprechend hinterlegt werden.

Nach Abschluss des Assistenten wird das neue Replikationsobjekt unterhalb des Knotens Replikation zu sehen sein (Abbildung 15.76). Auf der Registerkarte Verbindungen können Sie nachvollziehen, welche Server momentan verbunden sind. Aus dem Kontextmenü des Replikationsobjekts können Sie verschiedenste Diagnose-, Konfigurations- und Wartungsfunktionen aufrufen.

Abbildung 15.75 Auf dieser Seite geben Sie an, wann und mit welcher Bandbreite repliziert werden soll.

Abbildung 15.76 Auf der Registerkarte »Verbindungen« im Überblicksdialog über das Replikationsobjekt können Sie die verbundenen Server betrachten.

15.4.9 Redundanz des Namespaceservers

Im vorigen Abschnitt haben Sie gesehen, wie man einzelne Ordner innerhalb eines domänenbasierten DFS-Namespace redundant auslegt – es wird eine Replikation zwischen mehreren Freigaben eingerichtet, die die Daten des Ordners enthalten.

Der DFS-Namespace steht allerdings nicht redundant zur Verfügung, wenn nur ein einziger Namespaceserver vorhanden ist. Im Kontextmenü des Namespace findet sich eine Funktion zum Hinzufügen von zusätzlichen Namespaceservern (Abbildung 15.77). Damit ein Server DFS-Namespaceserver sein kann, muss der Rollendienst DFS-Namespaces installiert sein.

Abbildung 15.77 Es sollten nach Möglichkeit redundante Namespaceserver vorhanden sein.

Auf der Registerkarte Namespaceserver in der Übersicht eines Namespace werden die für diese Verwendung konfigurierten Systeme angezeigt, sodass Sie einen schnellen Überblick darüber erhalten können, ob Redundanz (d. h., es gibt mehrere Server) besteht.

---

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.