DFS-Namespace: Server ohne DFS als Ziel?

[MaikHSW 13]

Hey zusammen,

irgendwie habe ich gerade ein Brett vor dem Kopf.

Stichwort: DFS.

Aus meiner Sicht müssen alle Fileserver, die am NFS teilnehmen, entsprechend das Windows Feature installiert haben und können dann auch Ordner besitzen.

Nur in meinem Kopf schwebt die Frage, ob ein Fileserver auch Target sein kann, ohne entsprechende Windows Features?

Aus meiner Sicht nicht, denn DFS ist ja nunmal das Distributed File System. Und wer nicht teilnimmt nimmt nicht teil.

Da mich das aber gerade etwas verunsichert frage ich hier einfach mal direkt: ich habe doch Recht, oder?

Oder folge ich einem Irrtum?

 

Habt vielen Dank.

 

 

Gruß

[Dukel 454]

DFS-N oder DFS-R? Oder beides?

In der DFS-N Konfiguration können beliebige Server angesprochen werden, die kein DFS-N installiert haben. Das muss nur der, der den Namespace hostet machen.

[MaikHSW 13]

Hey,

vielen Dank für dein Feedback.

DFS-N ist der Namespace selbst, richtig?

Da müssen alle entsprechend das Feature installiert haben, bieten aber nur den Space als Verzeichnis an, oder?

Im Namespace kann ich dann auch einen fileserver veröffentlichen, der gar nicht verteilt ist? Dann ist nur noch der namespace verteilt und mit \\domain\namespace\ordner anzusprechen? Wo ist der Mehrwert? Gäbe es, je nach lokation, mehrere Targets wäre es mir klar. Nur dann wäre es wieder verteilt da alle den gleichen Stand bräuchten im Regelfall (gleiche Dokumente zum Beispiel). 

Und was ist DFS-N? 

 

Bei DFS muss ich mich echt nochmal reinlesen....

Vielen Dank für deine Hilfe.

 

 

gruss

 

 

 

maik

[NorbertFe 2.050]

Bitte klar unterscheiden zwischen DFS-N und DFS-R.

 

Ersteres stellt einfach nur den gemeinsamen Namensraum mehrerer Server bereit (egal wo die Ziele jeweils liegen).

Letzeres repliziert die Daten und die müssen nicht zwingend als Nametargets veröffentlicht sein.

 

Probiers einfach aus, das ist einfacher, als darüber zu philosophieren. ;)

 

Bye

Norbert

[MaikHSW 13]

Hey Norbert,

vielen Dank für dein Feedback und du hast Recht, da geht probieren über studieren.

Da habe ich echt einen leicht blinden Fleck, den ich mal füllen muss.

 

Hab vielen Dank.

 

 

Gruß

 

 

Maik

[NilsK 2.940]

Moin,

 

DFS-N = System, das einen virtuellen Verzeichnisbaum bereitstellt. Die Einträge des Verzeichnisbaums sind Shares, die auf beliebigen SMB-Dateiservern liegen können. Die Dateiserver brauchen nichts von DFS zu wissen. DFS-N ist nur auf dem Server bzw. den (wenigen) Servern installiert, die den Baum als Verteilpunkt anbieten, diese Server sind typischerweise selbst keine Dateiserver.

 

DFS-R = Replikationssystem, das Dateien zwischen mehreren Servern repliziert. Kann mit oder ohne DFS-N verwendet werden. Ohne DFS-N nutzt man sowas manchmal, um Dateien von mehreren Servern z.B. für ein zentrales Backup zu konsolidieren. DFS-R und DFS-N in Kombination kann dafür sorgen, dieselben Daten z.B. an mehreren Standorten für User bereitzustellen. Vorsicht, DFS-R steuert die Zugriffe nicht und ist in der Hinsicht "dumm", es besteht also das Risiko des Datenverlusts oder von Inkonsistenzen, wenn man es falsch konzipiert und einsetzt.

 

Gruß, Nils

 

[Weingeist 159]

Ein paar Tipps am Rande noch, damit Du später nicht auf die Schnautze fällst. DFS kann für Anfänger recht fies sein, meist mit Verzögerung. =)

 

1. DFS sollte nicht auf dem DC installiert werden, bzw. nicht auf jenem mit der PDC-FSMO-Rolle.  Am besten sollte die physische Maschine eine andere sein damit nicht (auch wens eine VM ist).

Wenn der der PDC ausfällt, änderst Du nichts mehr an Deinem DFS-Root. Du kannst also nicht auf ein anderes Ziel umschalten. Fällt also der Haupt-DFS zusammen mit dem PDC aus, ist Ruhe im Karton wenn der DC auch der Fileserver mit den aktiven Targets ist.

 

2. DFS-R würde ich persönlich nicht auf zwei aktive Targets verwenden sondern nur ein Target für die Usere aktivieren und das zweite z.B. deaktivieren. Dann hast bereits 99% der Ärgernisse mit DFS-R von vornherein nicht. Es arbeiten dann alle auf dem ersten Target. Im Fehlerfall kannst dann einfach umschalten auf das zweite. Ich mache das gerne als schnell verfügbares Zweitsystem für den Fileserver, weil der in der Regel ne weile braucht für ein recovery. Das umschalten auf ein anderes Target (also aktivieren/deaktivieren) geht aber nur, wenn der PDC zu diesem Zeitpunkt noch lebt. Deshalb eben auch möglichst physisch trennen.

 

3. Dann auch immer DFS-R separat und nicht mit dem Wizard konfigurieren. Dann kann man es unabhängig voneinander ändern und löschen.

 

Anbei noch ein lesenswerter Artikel (wenn auch etwas älter)

https://blogs.technet.microsoft.com/deds/2011/07/12/wie-ein-dfs-namespace-nicht-aussehen-sollte/

https://blogs.technet.microsoft.com/askds/2012/07/24/common-dfsn-configuration-mistakes-and-oversights/

[MaikHSW 13]

Hey @Weingeist,

vielen Dank für deine ausführliche Antwort und die weiteren Gedanken.

Das Thema Verfügbarkeit habe ich in der Tat nicht mal groß im Auge gehabt, eben weil VMs nahezu immer im Cluster laufen und daher im Idealfall verfügbar sind.

Im Idealfall ist all das gegeben, natürlich nur da....

 

DFS-R müsste dann aber manuell umgeschaltet werden. Was zwar okay ist, aber einen Eingriff erfordert.

Bei Follow the Sun ist das etwas schwierig denke ich :-).

Oder siehst du da Möglichkeiten für Skripte?

 

 

Gruß

 

 

 

[Weingeist 159]

Klar kannst das ganze irgendwie scripten. Ich würde es aber trotzdem nicht automatisch sondern nur im Desaster-Fall per Hand auslösen. "Normale" Unterbrüche werden ja sowieso abgefangen weil die eigentlichen Fileserver selber wieder auf ner anderen physischen Maschine anstarten sofern das gewünscht ist.

Mit DFS-R hast dagegen schnell die Verfügbarkeit der Daten verkleinert anstelle vergrössert, wenn die Targets selbständig hin und herswitchen. Sei es nur weil Du einen Server rebootest. Gibt unter Umständen sehr lästige Effekte wo manuell eingegriffen werden muss oder nach Murphy automatisch das falsche gewählt wird. Die Kiste bzw. das Storage dahinter darf dann auch gerne etwas langsamer sein wenn nicht mordsmässig viele Daten parallel verarbeitet werden sondern einfach die Datenmenge gross ist. Wenn der Fall wirklich eintritt, dass der ganze Fileserver komplett platt ist, obwohl gut gesichert, ist man froh überhaupt schnell wieder was aktuelles zu haben und die Zeit in den rest der VM's zu investieren und ganz zum Schluss den Fileserver wieder in hochzuziehen. Backup-Storage hat damit eh schon genug zu tun. Aber das ist nur meine persönliche Meinung basiert auf Erfahrungen in Kleinumgebungen. Mag jeder wieder anders sehen.