Einrichtung DFS-Replikation mit DFS-Share

[gnoovy 10]

Hi zusammen,

ich bin gerade für einen Kunden dabei die DFS-Replikation mit anschließender Freigabe des Replikationsverzeichnisses im DFS-Share zu evaluieren. Ist folgende Vorgehensweise korrekt? Eure Meinung wäre mir wichtig...

 

1) Testumgebung ähnlich Kundenumgebung

- W2k3 R2 Enterprise Domänencontroller namens Dc1 mit Windows 2003 Gesamtstrukturmodus

- W2k8 R2 Enterprise SP1 MemberServer namens Member1

- W2k8 R2 Enterprise SP1 MemberServer namens Member2

 

2) Installation

- Installation DFS-Namespace und Replikation auf beiden MemberServern

- Angabe bei Installation, dass der Namespace später eingerichtet wird

 

3) Konfiguration

- Wechsel in DFS-Verwaltung auf Member1

- Auswahl "Neue Replikationsgruppe"

- Auswahl "Mehrzweckreplikationsgruppe

- Vergabe Replikationsname und Auswahl Member1 und Member2 zur Replikationsgrupe

- Topologieauswahl "vollständig vermaschtes Netz"

- Auswahl Replikation rund um die Uhr

- Auswahl Member1 als primäres Mitglied für die Replikation

- Auswahl des Ordners auf Member1, dessen Inhalt repliziert werden soll

- Analog Auswahl des Verzeichnisses auf Member2 für die Replikation

-Wechsel in den Replikationsbereich der DFS-Verwaltung und Wechsel in die Registerkarte "Replizierte Ordner"

- Auswahl des oben konfigurierten Ordners für die Replikation und Auswahl des Punktes "Freigeben und in Namespace veröffentlichen"

- Auswahl "Replizierten Ordner in einen Namespace freigeben und veröffentlichen"

-Erstellung Verzwichnisfreigabe auf Member1 und Member2

- Auswahl DC1 als Host für das AD integrierte DFS-Share

 

4) Testlauf

- Auswahl des DFS-Shares von einem Client über \\<domäne>\<dfs-share>\<freigabe>

- Auswahl dortiges Testdokument und Änderung

- Speicherung erfolgreich und Replikation zwischen Member1 und Member2 erfolgreich

[olc 18]

Hi gnoovy,

 

das Vorgehen sieht auf den ersten Blick ganz gut aus. Du kannst überlegen, ob der DC wirklich auch DFSN Namespace Server sein soll. Es hat ggf. Sinn das auf die Member-Server zu legen - auf beide, um etwas Redundanz zu haben.

 

BTW: Ist wirklich nur 1 DC in der Umgebung vorhanden? Falls ja: Es ist definitiv zu empfehlen, einen zweiten DC dort zu promoten.

 

Die Frage, die sich mir stellt, ist was Du mit der DFS( R )-Replikation erreichen möchtest? Als "Cluster-Ersatz" ist DFSR mit Vorsicht zu genießen, auch wenn es häufig so genutzt wird. Die beiden vorgesehenen DFSR Nutzungsszenarien sind im Kern die Datenverteilung (etwa für WDS Images) und die Datensammlung (etwa für Backups). Alles andere kann Probleme in Bezug auf Datenaktualität, verteilte Datennutzung auf unterschiedlichen Systemen bis hin zum Datenverlust nach sich ziehen.

 

Daher meine Rückfrage: Was ist das Szenario, für welches DFSN + DFSR genutzt werden soll?

 

Viele Grüße

olc

bearbeitet 29. Dezember 2012 von olc

[gnoovy 10]

Hi Olc,

 

keine Angst, nur in der Testumgebung gibt es 1 DC. In der Produktivumgebung gibt es mehrere. Somit würde ich auf mindestens zwei Domänencontrollern ein Namespaceserver einrichten. Was genau mit der DFS-Replikation erreicht werden soll kann ich nicht im Detail sagen.

Mein Teamleiter meinte lediglich, dass er eine Synchronisation mittels DFS haben möchte für gewisse Qluik-View-Dateien. Hat meine ich was mit Datenbankdateien zu tun. Ich sollte lediglich eruieren wie DFS mit DFS-Replikation konfiguriert werden muss.

Wenn ich mehrere Domänencontroller als Namespaceserver einrichte, hab ich ja ebenfalls Redundanz oder? Ich möchte halt, dass mein DFSRoot mit dem freigegebenen Verzeichnis direkt angezeigt wird wenn ich \\<Domäne> im Windows-Explorer eingebe.

Bei Angabe der Member-Server als Namespaceserver wird ja mein DFSRoot nach Eingabe von \\<Domäne> nicht angezeigt. Ich kann zwar trotzdem über \\<Domäne>\<DfsRoot> drauf zugreifen aber finde die direkte Anzeige schöner.

[olc 18]

Hi gnoovy,

 

Klar ist es "schöner" den Namespace bei Aufruf der Domäne sehen zu können, aber Du zahlst eben auch einen Preis dafür. Nämlich die Abhängigkeit des DFSN Dienstes in Bezug auf die DCs. Wenn Du zu Troubleshooting Zwecken einmal DCs demoten musst, Migrationen anstehen usw., kosten Dich diese Abhängigkeiten Zeit, Nerven und verursachen häufig Probleme. Ich würde es also eher nicht von der Sichtbarkeit von Namespace abhängig machen, sondern von der Integration in Eure Umgebung (=keine Abhängigkeiten schaffen).

 

Bezüglich des Hintergrunds der Anfrage: Datenbanken mit DFSR replizieren zu wollen geht meist in die Hose, da DBs mit file-locks arbeiten, die für Blockaden bei der DFSR Replikation sorgen. Die Folge sind Replikationsprobleme als auch schlimmstenfalls Dateninkonsistenz, sofern auf beiden Seiten der Replikationsgruppe gearbeitet wird.

 

Daher noch einmal explizit der Hinweis, dass Ihr das ganze Konzept noch einmal überdenken solltet. Die Boardsuche zum Thema DFSR sollte einiges dazu zu Tage fördern.

 

Viele Grüße

olc

[gnoovy 10]

Hi Olc,

 

erstmal vielen Dank für die bisherige Hilfe. Ok aber hab ich nicht ähnliche Probleme wenn ich den Namespace auf die Member-Server lege und diese migrieren muss? Würde ich nicht Probleme umgehen wenn ich bei DCs, als auch bei Memberserver beispielsweise einen oder mehrere Windows 2012 Server reinhänge, diese zu den Namespace-Servern hinzufüge und danach die bisherigen migriere? Somit gibt es ja immer Server oder Domänencontroller, welche erreichbar sind oder?

[olc 18]

Hi,

 

Jeder Betrieb von mehreren Server Funktionen auf einer Maschine führt zu Abhängigkeiten. Geht es nicht anders, musst Du Dich zwischen Pest und Cholera entscheiden.

 

Sofern es anders geht, würde ich in der Regel immer Server Rollen trennen. Paradigma: Ein Server, ein Dienst.

 

Viele Grüße

olc

[gnoovy 10]

hi olc,

 

ok das ist klar. aber wenn ich mehrere domänencontroller habe und auf mindestens zweien den namespace von dfs einrichte hab ich doch Redundanz oder? sonst läuft ja nichts auf den DCs. hätte ich dann trotzdem Probleme bei Migrationen, etc.? sonst gebe ich dir natürlich recht mit ein Server und ein Dienst. aber oft kann man das ja aus budgetgründen auch oft nicht machen mit ein Dienst pro Server...