7
DFS: es zickt und bockt
Hallo,
habe einen SRV2016 mit Namen FP1 der mal in einer DFS-Gruppe Jahr und Tag repliziert hat.
Der hat aber nun seinen Partner verloren und soll zu einem anderen Server, sagen wir FP2, replizieren. FP2 ist dabei ein 2019er.
Die Namespaces sind angelegt, die Server sind die beiden AD's.
Nun kann ich machen was ich will, das Ding repliziert nicht:
- aller Arten von Assistenten (über die Namespaces als auch direkt über neue Replikationsgruppe) probiert, alles sieht gut aus und läuft ohne Fehler durch : es repliziert nicht
- Namespaces gelöscht und neu angelegt, auf dem Zielserver DFS neu installiert : es repliziert nicht
Was immer angelegt wird auf dem Ziel, ist das DFSPRIVATE-Verzeichnis und ein DFS-Testverzeichnis.
Aber das war's.
Die Topologietests sagen 'alles gut', die Diagnostictests sagen 'da klappt was nicht'. Ach, echt...
In meiner Not nun einen weiteren Server (2016) mit in das Spiel aufgenommen. Siehe da, der empfängt Daten - wenngleich sehr sehr langsam (nach 3 Stunden immer noch nicht alle Daten repliziert - die Verbindungen sind aber alle min GBIT.
Wer kennt die Untiefen von DFS gut genug um Rat zu geben...?
Danke Euch
habe einen SRV2016 mit Namen FP1 der mal in einer DFS-Gruppe Jahr und Tag repliziert hat.
Der hat aber nun seinen Partner verloren und soll zu einem anderen Server, sagen wir FP2, replizieren. FP2 ist dabei ein 2019er.
Die Namespaces sind angelegt, die Server sind die beiden AD's.
Nun kann ich machen was ich will, das Ding repliziert nicht:
- aller Arten von Assistenten (über die Namespaces als auch direkt über neue Replikationsgruppe) probiert, alles sieht gut aus und läuft ohne Fehler durch : es repliziert nicht
- Namespaces gelöscht und neu angelegt, auf dem Zielserver DFS neu installiert : es repliziert nicht
Was immer angelegt wird auf dem Ziel, ist das DFSPRIVATE-Verzeichnis und ein DFS-Testverzeichnis.
Aber das war's.
Die Topologietests sagen 'alles gut', die Diagnostictests sagen 'da klappt was nicht'. Ach, echt...
In meiner Not nun einen weiteren Server (2016) mit in das Spiel aufgenommen. Siehe da, der empfängt Daten - wenngleich sehr sehr langsam (nach 3 Stunden immer noch nicht alle Daten repliziert - die Verbindungen sind aber alle min GBIT.
Wer kennt die Untiefen von DFS gut genug um Rat zu geben...?
Danke Euch
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 653490
Url: https://administrator.de/contentid/653490
Printed on: April 18, 2024 at 18:04 o'clock
7 Comments
Latest comment
Hi,
erstens: Die DFS Replikation ist unabhängig vom DFS Namespace. Wenn Du also Probleme mit der Replikation hast, dann brauchst (und solltest) Du nicht parallel am DFS-N ändern.
Weiterhin: Dein Text suggeriert mir, dass Du einen bestehenden Datenbestand jetzt auf einen anderen Server replizieren willst. Falls ja: Wie groß ist dieser Bestand, wieviele Dateien und Ordner sind das ? Ist in der Quelle viel Schreibaktivität?
Worauf ich hinaus will: Wenn man einen großen Datenbestand von Null an replizieren will, dann kann es eine ganze Weile dauern (Stunden?) bis er überhaupt anfängt, etwas zu replizieren. Und dann sowieso erst die alten, bestehenden Daten. Ab Einrichten der Replikation neu hinzugekommen Dateien sind meistens dann als letztes dran.
Falls o.g. zutrifft, würde ich die Replikation mit diesem neuen Server wieder löschen und zunächst mit neuen, leeren Ordnern eine Test-Replikationsgruppe erstellen. Dann warten, bis beide Server in ihren DFS-R-Eventlogs melden, dass sie es kapiert haben und dann erst Dateien in diesen Ordnern erstellen und ändern und schauen, ob sie repliziert werden.
E.
erstens: Die DFS Replikation ist unabhängig vom DFS Namespace. Wenn Du also Probleme mit der Replikation hast, dann brauchst (und solltest) Du nicht parallel am DFS-N ändern.
Weiterhin: Dein Text suggeriert mir, dass Du einen bestehenden Datenbestand jetzt auf einen anderen Server replizieren willst. Falls ja: Wie groß ist dieser Bestand, wieviele Dateien und Ordner sind das ? Ist in der Quelle viel Schreibaktivität?
Worauf ich hinaus will: Wenn man einen großen Datenbestand von Null an replizieren will, dann kann es eine ganze Weile dauern (Stunden?) bis er überhaupt anfängt, etwas zu replizieren. Und dann sowieso erst die alten, bestehenden Daten. Ab Einrichten der Replikation neu hinzugekommen Dateien sind meistens dann als letztes dran.
Falls o.g. zutrifft, würde ich die Replikation mit diesem neuen Server wieder löschen und zunächst mit neuen, leeren Ordnern eine Test-Replikationsgruppe erstellen. Dann warten, bis beide Server in ihren DFS-R-Eventlogs melden, dass sie es kapiert haben und dann erst Dateien in diesen Ordnern erstellen und ändern und schauen, ob sie repliziert werden.
Der hat aber nun seinen Partner verloren
Was heißt das?E.
OK, werde das nun zunächst mit leeren Umgebungen testen.
Danke
Danke
DFS macht mich immer noch kirre:
nachdem es nun repliziert (weiß nicht wieso, hab nichts anders gemacht als die Tests davor), habe ich mich an echte Verzeichnisse gewagt.
Nach einigen vielen Minuten sind auch die angegangen worden und es tat sich was am Target.
Ich hatte dann zwei Ordnerstrukturen mit zusammen ~1TB Daten in der Replikation.
Nur: nach einem Tag waren davon grad mal 300GB repliziert und der DFS-Dienst schuckelte laut Lastanzeige im MBit-Bereich das eine oder andere dazu - in einer 10GBit Infrastruktur die nahe nichts zu tun hat z.Zt.
War mir ja fast noch egal, ich bin bei DFS irgendwie demütig geworden mit meinen Erwartungen.
Nun wurde es aber richtig 'nasty': User meldeten sich, ihre Netzlaufwerke wären leer/unvollständig.
Leider wahr- DFS leitete die User nach Zufall offenbar auf die unvollständigen Repliken um - ist DFS spinnert...?
Da bin ich wieder ganz schnell geworden in der Rücknahme meiner Versuche und noch ratloser.
Hilfe..
nachdem es nun repliziert (weiß nicht wieso, hab nichts anders gemacht als die Tests davor), habe ich mich an echte Verzeichnisse gewagt.
Nach einigen vielen Minuten sind auch die angegangen worden und es tat sich was am Target.
Ich hatte dann zwei Ordnerstrukturen mit zusammen ~1TB Daten in der Replikation.
Nur: nach einem Tag waren davon grad mal 300GB repliziert und der DFS-Dienst schuckelte laut Lastanzeige im MBit-Bereich das eine oder andere dazu - in einer 10GBit Infrastruktur die nahe nichts zu tun hat z.Zt.
War mir ja fast noch egal, ich bin bei DFS irgendwie demütig geworden mit meinen Erwartungen.
Nun wurde es aber richtig 'nasty': User meldeten sich, ihre Netzlaufwerke wären leer/unvollständig.
Leider wahr- DFS leitete die User nach Zufall offenbar auf die unvollständigen Repliken um - ist DFS spinnert...?
Da bin ich wieder ganz schnell geworden in der Rücknahme meiner Versuche und noch ratloser.
Hilfe..
Zitat von @winacker:
Nun wurde es aber richtig 'nasty': User meldeten sich, ihre Netzlaufwerke wären leer/unvollständig.
Leider wahr- DFS leitete die User nach Zufall offenbar auf die unvollständigen Repliken um - ist DFS spinnert...?
Da bin ich wieder ganz schnell geworden in der Rücknahme meiner Versuche und noch ratloser.
Das ist ein Admin-Fehler. Also Deiner!Nun wurde es aber richtig 'nasty': User meldeten sich, ihre Netzlaufwerke wären leer/unvollständig.
Leider wahr- DFS leitete die User nach Zufall offenbar auf die unvollständigen Repliken um - ist DFS spinnert...?
Da bin ich wieder ganz schnell geworden in der Rücknahme meiner Versuche und noch ratloser.
Ich hatte bereits geschrieben, dass DFS-N und DFS-R unabhängig voneinander sind. Warum - zum Geier - stellst Du den Anwendern auch ein Replikat als weiteres Ziel eines DFS-Ordners zur Verfügung, wenn dieses doch noch nicht vollständig repliziert ist? Entweder nimmst Du das Ziel raus aus dem DFS-Ordner oder Du deaktivierst es erstmal nur in der Konfiguration des DFS-Ordners. Erst wenn der Ordner vollständig repliziert ist und Du sicher verifiziert hast, dass aktuelle Änderungen auch zeitnah repliziert werden, erst dann aktivierst Du dieses Ziel im DFS-N.
"1 TB" ist nicht unbedingt das Kriterium. Die Anzahl der Dateien und Ordner sowie die Änderungsrate daran sind das Interessante!
DFS-R "Tuning" geht nicht allein über Netzwerk-Bandbreite, obwohl natürlich auch interessant. RAM und CPU sowie die Größe der Staging-Ordner spielen hier die erste Geige. IOpS der Datenträger erwähne ich nur.
War mir schon klar dass das mein Fehler sein muß, habe nur nicht gesehen welcher...
Bin vom Namespace ausgegangen, den gibts schon immer un der tut auch.
Dann bin ich über den Reiter REplikation brav über den Ordnerreplizierungsassistenten zur Replikation gekommen
Dort dann habe ich die Mitglieder und den primären Server eingetragen und dachte, alles ist gut.
Warum sollte DFS den sekundären Server verwenden wenn der primäre verfügabr ist?
Wenn ich Deiner Argumentation nun aber folge, würfelt DFS aus wohin es zeigt (bei z.B. 2 Zielen 'A' und 'B')?
Gehen wir von einer vollständigen Replikation zum Zeitpunkt X aus. Dann schaufelt jemand, dessen Laufwerksauflösung auf 'A' zeigt, später große Datenmengen auf 'A'. Ein anderer Anwender nun, der auf 'B' zeigt, wird davon nichts mitbekommen bis die Replikation durch ist?
Sollte DFS nicht immer den Primären nehmen, ausser der ist weggebrochen?
Bin vom Namespace ausgegangen, den gibts schon immer un der tut auch.
Warum sollte DFS den sekundären Server verwenden wenn der primäre verfügabr ist?
Wenn ich Deiner Argumentation nun aber folge, würfelt DFS aus wohin es zeigt (bei z.B. 2 Zielen 'A' und 'B')?
Gehen wir von einer vollständigen Replikation zum Zeitpunkt X aus. Dann schaufelt jemand, dessen Laufwerksauflösung auf 'A' zeigt, später große Datenmengen auf 'A'. Ein anderer Anwender nun, der auf 'B' zeigt, wird davon nichts mitbekommen bis die Replikation durch ist?
Sollte DFS nicht immer den Primären nehmen, ausser der ist weggebrochen?
Zitat von @winacker:
Warum sollte DFS den sekundären Server verwenden wenn der primäre verfügabr ist?
Er fragt Dich das nur, damit er weiß, von wo nach wo er die Initialkopie ausführen soll. Wenn diese erledigt ist, dann gibt es kein Primär/Sekundär mehr.Warum sollte DFS den sekundären Server verwenden wenn der primäre verfügabr ist?
Wenn ich Deiner Argumentation nun aber folge, würfelt DFS aus wohin es zeigt (bei z.B. 2 Zielen 'A' und 'B')?
Fast richtig. Aber nur, wenn beide am gleichen Standort und beide vom Client aus erreichbar sind. Sowas nennt sich Round-Robin-Verfahren.Wenn die DFS-Ziele an verschiedenen Standorten (Subnetze) sind, und diese im AD auch als Standorte abgebildet sind, dann verbinden sich die Clients bevorzugt mit dem Ziel am gleichen Standort. Wenn es am gleichen Standort kein Ziel gibt dann wird das nächste anhand der Replikations-Verknüpfungen des AD bestimmt. Das kann man aber alles nachlesen in der DFS-Doku von Microsoft.
Man kann das z.T. auch an den Einstellungen eines DFS-Ordners konfigurieren. Aber das sind nur "Empfehlungen". Keine Fixierungen.
Gehen wir von einer vollständigen Replikation zum Zeitpunkt X aus. Dann schaufelt jemand, dessen Laufwerksauflösung auf 'A' zeigt, später große Datenmengen auf 'A'. Ein anderer Anwender nun, der auf 'B' zeigt, wird davon nichts mitbekommen bis die Replikation durch ist?
Richtig. Ganz normal.Sollte DFS nicht immer den Primären nehmen, ausser der ist weggebrochen?
Wenn man DFS-Ordner rein aus Gründen der Redundanz mit mehreren Zielen betreibt und man eine sehr zeitnahe Konsistenz sicherstellen muss , dann muss man das sogar so einrichten. Das geht aber nur, wenn die Server und Clients in verschiedenen, im AD abgebildeten Standorten sind.Allerdings sollte man wissen, dass es dafür keine 100%-Garantie gibt. Sollte mal ein Client das bevorzugte Ziel nicht oder nicht schnell genug erreichen können (aus welchem Grund auch immer), dann wird er es mit einem anderen versuchen.
Wenn man eine kurze Unterbrechung bis zum Admin-Eingriff tolerieren kann, dann könnte man auch den "sekundären" Server netzwerktechnisch so abschotten, dass er vom Client aus nicht zu erreichen ist, dass sich nur die Server untereinander sehen (und die DC's). Im Störfall müsste dann erst ein Admin den Zugriff vom Client auf den "sekundären" Server freischalten.
Vielen Dank, das Dunkel lichtet sich...
Leider ist es genau so: beide Server stehen im selben Schrank im selben Netzwerk, der 2. ist nur als Redundanz gedacht wenn der 1. schwächeln sollte.
Muß ich ggf. also nochmal drüber nachdenken ob das wirklich hilft oder die Leute ggf. nur mehr verwirrt
Leider ist es genau so: beide Server stehen im selben Schrank im selben Netzwerk, der 2. ist nur als Redundanz gedacht wenn der 1. schwächeln sollte.
Muß ich ggf. also nochmal drüber nachdenken ob das wirklich hilft oder die Leute ggf. nur mehr verwirrt
