4
Probleme mit DFS Replikation
Moin,
wir betreiben neben dem Zentralstandort (Windows Server 2016 Std.) noch 5 "Niederlassungen" an denen jeweils ein eigener DFS Server steht (Windows Server 2012)
Auf dem Fileserver in der Zentrale gibt es für jede Niederlassung ein Verzeichnis, welches von dort repliziert werden soll. Bis vor ein paar Wochen hat dies auch wunderbar geklappt und das Backlog war, je nach Auslastung eigentlich immer sehr gering bzw. nicht existent.
Nun ist aber scheinbar irgendwas passiert, sodass die Replizierung nicht mehr wirklich funktioniert. Das Backlog wird nicht abgearbeitet, die ersten 100 Dateien verändern sich nicht, wenn ich über die CMD das Protokoll aufrufe.
Gehe ich nun über die DFS Verwaltung meldet das System keine Fehler. Der Topologiestatus ist für jedes der fünf eingerichteten Ziele in Ordnung
Bei den Diagnoseberichten kann ich zumindest sehen, dass die Testdatei bei einer Niederlassung zwischen 10 und 13 Std gedauert hat..
Bei einer anderen Niederlassung (die hat auch ein Backlog von euns 137.000 Dateien) ist seit dem letzten Test vor 45 Tagen noch keine Übermittlung erfolgt.
An der Bandbreite kann es eigentlich nicht liegen, die entsprechenden Zeitpläne sind auf maximalen Durchsatz gestellt und am Wochenende arbeitet auch niemand, sodass das Backlog eigentlich auch kleiner werden müsste.
Im Eventlog finde ich ab und zu folgende Meldung:
Ich gehe also davon aus, dass die Daten verarbeitet werden allerdings so langsam, dass das Backlog eher anwächst...
Gibt es irgendeine Möglichkeit initial die Daten einmal anzustoßen/zu kopieren, sodass das Backlog verschwindet? Löschen kann ich die eine Seite jedenfalls nicht mehr, da die Daten mittlerweile Asynchron sind und sowohl auf der einen als auf der anderen Seite aktuelle Daten liegen...
wir betreiben neben dem Zentralstandort (Windows Server 2016 Std.) noch 5 "Niederlassungen" an denen jeweils ein eigener DFS Server steht (Windows Server 2012)
Auf dem Fileserver in der Zentrale gibt es für jede Niederlassung ein Verzeichnis, welches von dort repliziert werden soll. Bis vor ein paar Wochen hat dies auch wunderbar geklappt und das Backlog war, je nach Auslastung eigentlich immer sehr gering bzw. nicht existent.
Nun ist aber scheinbar irgendwas passiert, sodass die Replizierung nicht mehr wirklich funktioniert. Das Backlog wird nicht abgearbeitet, die ersten 100 Dateien verändern sich nicht, wenn ich über die CMD das Protokoll aufrufe.
Gehe ich nun über die DFS Verwaltung meldet das System keine Fehler. Der Topologiestatus ist für jedes der fünf eingerichteten Ziele in Ordnung
Bei den Diagnoseberichten kann ich zumindest sehen, dass die Testdatei bei einer Niederlassung zwischen 10 und 13 Std gedauert hat..
Bei einer anderen Niederlassung (die hat auch ein Backlog von euns 137.000 Dateien) ist seit dem letzten Test vor 45 Tagen noch keine Übermittlung erfolgt.
An der Bandbreite kann es eigentlich nicht liegen, die entsprechenden Zeitpläne sind auf maximalen Durchsatz gestellt und am Wochenende arbeitet auch niemand, sodass das Backlog eigentlich auch kleiner werden müsste.
Im Eventlog finde ich ab und zu folgende Meldung:
Vom DFS-Replikationsdienst wurde erkannt, dass eine Datei auf mehreren Servern geändert wurde. Es wurde ein Algorithmus zur Konfliktauflösung verwendet, um die Gewinnerdatei zu bestimmen. Die Verliererdatei wurde in den Konfliktordner für gelöschte Dateien verschoben. Gibt es irgendeine Möglichkeit initial die Daten einmal anzustoßen/zu kopieren, sodass das Backlog verschwindet? Löschen kann ich die eine Seite jedenfalls nicht mehr, da die Daten mittlerweile Asynchron sind und sowohl auf der einen als auf der anderen Seite aktuelle Daten liegen...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1768390752
Url: https://administrator.de/forum/probleme-mit-dfs-replikation-1768390752.html
Ausgedruckt am: 22.12.2024 um 09:12 Uhr
4 Kommentare
Neuester Kommentar
Tach jann0r,
du kannst natürlich auf dem Zentral-Server selbst den lokalen Order öffnen, und daneben den anderen Ordner in der Niederlassung. Das sollte ja gehen, wenn die Datenverbindung steht.
Dann eben mit robocopy aktualisieren.
Im Zweifel vorher das ganze mal eben mit Testordnern ausprobieren.
Wenn alles nix hilft ggf Ordner in Zentralserver als auch auf den Filialserver duplizieren in neue Ordner und die DFS Replikation damit neu einrichten.
Kreuzberger
du kannst natürlich auf dem Zentral-Server selbst den lokalen Order öffnen, und daneben den anderen Ordner in der Niederlassung. Das sollte ja gehen, wenn die Datenverbindung steht.
Dann eben mit robocopy aktualisieren.
Im Zweifel vorher das ganze mal eben mit Testordnern ausprobieren.
Wenn alles nix hilft ggf Ordner in Zentralserver als auch auf den Filialserver duplizieren in neue Ordner und die DFS Replikation damit neu einrichten.
Kreuzberger
1
Zitat von @kreuzberger:
Tach jann0r,
du kannst natürlich auf dem Zentral-Server selbst den lokalen Order öffnen, und daneben den anderen Ordner in der Niederlassung. Das sollte ja gehen, wenn die Datenverbindung steht.
Dann eben mit robocopy aktualisieren.
Im Zweifel vorher das ganze mal eben mit Testordnern ausprobieren.
Wenn alles nix hilft ggf Ordner in Zentralserver als auch auf den Filialserver duplizieren in neue Ordner und die DFS Replikation damit neu einrichten.
Kreuzberger
Tach jann0r,
du kannst natürlich auf dem Zentral-Server selbst den lokalen Order öffnen, und daneben den anderen Ordner in der Niederlassung. Das sollte ja gehen, wenn die Datenverbindung steht.
Dann eben mit robocopy aktualisieren.
Im Zweifel vorher das ganze mal eben mit Testordnern ausprobieren.
Wenn alles nix hilft ggf Ordner in Zentralserver als auch auf den Filialserver duplizieren in neue Ordner und die DFS Replikation damit neu einrichten.
Kreuzberger
Ich hab mal Testhalber ein Verzeichnis samt Unterverzeichnis mit robocopy /mir jeweils von Zentralserver zum Niederlassungsserver und zurück verschoben aber laut Backlog im DFS sind ebenjene Dateien immer noch nicht verarbeitet..
dir ist schon bewusst, dass /MIR im ziel alles löscht, was in der Quelle nicht da ist?
Kreuzberger
Kreuzberger
Also eine schlechte Replikationsperformance rührt oft daher daß man das RDC nicht aktiviert hat, und wenn es nicht aktiv ist gibt das Traffic ohne Ende. RDC wiederum kostet CPU-Last. im Schnitt sind 2-4 Cores während eines Pushes ausgelastet.
Und DFSR ist nur wirklcih brauchbar bei einer 1:1 Replikation, aber für sternförmige Replikation... dann noch mit gemeinsam genutzten Dateien ist das der falsche Ansatz. Dann sollte man eher mal über einen gemeinsamen Cloud-Share nachdenken oder höher entwickelte Produkte wie Panzura Freedom in Betracht ziehen.
Und Konflikte - damit kann und will man sich bei einem Share mit hunderttausenden DAteien nicht befassen.
Entweder last update wins, und einer hat dann halt Pech gehabt. War so und ist so und wird immer so bleiben, auch ben der SQL Server Repliaktion von Microsoft, sonst sucht man sich tot. Speziell bei Word oder Excel. Sollte der Fileshare in großem Umfang zur gemeinsamen Dateiverwaltung verwendet werden, bietet sich auch an mal über ein Dokumetnenmanagement System nachzudenken oder eine Sharepoint Integration, weil man da DAteien nämlich sperren kann.
Denn wenn DFSR mal steht dann steht es, und dann werden z.B. die Sperrdatenen von Officedokumenten nicht mehr repliziert bzw die Sites werden dann inkonsistent.
Und DFSR ist nur wirklcih brauchbar bei einer 1:1 Replikation, aber für sternförmige Replikation... dann noch mit gemeinsam genutzten Dateien ist das der falsche Ansatz. Dann sollte man eher mal über einen gemeinsamen Cloud-Share nachdenken oder höher entwickelte Produkte wie Panzura Freedom in Betracht ziehen.
Und Konflikte - damit kann und will man sich bei einem Share mit hunderttausenden DAteien nicht befassen.
Entweder last update wins, und einer hat dann halt Pech gehabt. War so und ist so und wird immer so bleiben, auch ben der SQL Server Repliaktion von Microsoft, sonst sucht man sich tot. Speziell bei Word oder Excel. Sollte der Fileshare in großem Umfang zur gemeinsamen Dateiverwaltung verwendet werden, bietet sich auch an mal über ein Dokumetnenmanagement System nachzudenken oder eine Sharepoint Integration, weil man da DAteien nämlich sperren kann.
Denn wenn DFSR mal steht dann steht es, und dann werden z.B. die Sperrdatenen von Officedokumenten nicht mehr repliziert bzw die Sites werden dann inkonsistent.
