14
DFS-Replikation gestartet, Staging zu klein, angepasst und trotzdem kein Start sowie weiterhin Fehlermeldungen
Moin moin,
ich habe die Replikation eines Ordners mit Profilen gestartet. Nach einer Zeit ist der Staging-Ordner gegen die Wand gefahren, bzw. die Replikation ist angehalten. Am nächsten Tag gab es das Phänomen, dass die älteren Daten (vom alten File-Server) beim User angezeigt werden und die neuen bearbeiteten Daten auf dem neuen Server liegen, jedoch nicht repliziert worden sind.
Ich habe daher den Staging-Ordner von 4 (4,3 GB genutzt) auf jetzt 32 GB (zwischenzeitlich 7,7 GB genutzt) vergrößert. In den Logs kann ich sehen, dass es Konflikte gab und die Daten vom neuen zum alten Server bzw. repliziert worden sind. Das Problem ist jedoch, dass es nicht "weiter geht". Also viele Änderungen gab es nicht von dem einen zum anderen Tag und die Gesamtgröße des alten Servers auf dem neuen File-Server bei weitem noch nicht erreicht sind.
Wenn ich die Diagnose starte, steht jedes Mal die Fehlermeldung, dass der Staging-Ordner überschritten worden ist, obwohl die Staging-Größe bei beiden File-Servern bzw. in der Replikationsgruppe erweitert worden ist.
Auch ein manueller Restart des Replikationsdienstes führt kurzfristig zu "Bewegung" bzw. zum automatischen Verschieben auf einen anderen Knoten (neuer File-Server ist ein Cluster aus zwei Knoten).
Ich bin aktuell ratlos und bitte um Hilfe, wie ich am besten die wenigen neuen Daten auf den alten bekomme und gleichzeitig die Replikation vom alten zum neuen Server abschließen kann.
ich habe die Replikation eines Ordners mit Profilen gestartet. Nach einer Zeit ist der Staging-Ordner gegen die Wand gefahren, bzw. die Replikation ist angehalten. Am nächsten Tag gab es das Phänomen, dass die älteren Daten (vom alten File-Server) beim User angezeigt werden und die neuen bearbeiteten Daten auf dem neuen Server liegen, jedoch nicht repliziert worden sind.
Ich habe daher den Staging-Ordner von 4 (4,3 GB genutzt) auf jetzt 32 GB (zwischenzeitlich 7,7 GB genutzt) vergrößert. In den Logs kann ich sehen, dass es Konflikte gab und die Daten vom neuen zum alten Server bzw. repliziert worden sind. Das Problem ist jedoch, dass es nicht "weiter geht". Also viele Änderungen gab es nicht von dem einen zum anderen Tag und die Gesamtgröße des alten Servers auf dem neuen File-Server bei weitem noch nicht erreicht sind.
Wenn ich die Diagnose starte, steht jedes Mal die Fehlermeldung, dass der Staging-Ordner überschritten worden ist, obwohl die Staging-Größe bei beiden File-Servern bzw. in der Replikationsgruppe erweitert worden ist.
Auch ein manueller Restart des Replikationsdienstes führt kurzfristig zu "Bewegung" bzw. zum automatischen Verschieben auf einen anderen Knoten (neuer File-Server ist ein Cluster aus zwei Knoten).
Ich bin aktuell ratlos und bitte um Hilfe, wie ich am besten die wenigen neuen Daten auf den alten bekomme und gleichzeitig die Replikation vom alten zum neuen Server abschließen kann.
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: 324469
Url: https://administrator.de/contentid/324469
Printed on: May 6, 2024 at 00:05 o'clock
14 Comments
Latest comment
Hi,
Wenns gar nicht geht, dann würde ich mit der neuen Staging-Größe vollkommen neu anfangen.
E.
ich habe die Replikation eines Ordners mit Profilen gestartet. Nach einer Zeit ist der Staging-Ordner gegen die Wand gefahren, bzw. die Replikation ist angehalten. Am nächsten Tag gab es das Phänomen, dass die älteren Daten (vom alten File-Server) beim User angezeigt werden und die neuen bearbeiteten Daten auf dem neuen Server liegen, jedoch nicht repliziert worden sind.
Hast Du etwa beide Replikate ins DFS-N eingebunden bevor Du sicher warst, dass die Repikation erfolgreich läuft? Falls ja, selbst schuld.Wenns gar nicht geht, dann würde ich mit der neuen Staging-Größe vollkommen neu anfangen.
- DFS-N-Links nur auf den Server mit den aktuellen Daten zeigen lassen
- Replikationsgruppe löschen
- warten, bis das beide Server im Eventlog bestätigen
- Daten auf dem "Kopie-Server" löschen. Auch den Staging-Ordner.
- Replikationsgruppe neu erstellen: Server mit Daten ist der Master
- warten, bis das beide Server im Eventlog bestätigen
- warten bis beide Server synchron sind
- jetzt erst den "Kopie-Server" ind DFS-N auf nehmen
E.
Guten Morgen,
vielen Dank für deine Antwort!
Noch einmal in der Kürze was genau passiert ist (nachdem schon Einiges vorher erfolgreich repliziert worden ist).
FS=File-Server (alte phys. Maschine)
CFS=ClusterFileServer (zwei neue Knoten, soll den alten FS ersetzen)
1. Replikation gestartet (FS ist natürlich als Master ausgewählt)
2. Replikation ist bei ca. 40% angehalten (ca. 320 GB Gesamtgröße), Staging-Ordner ist gegen die Wand gefahren.
Leider ist das Ordnerziel des neuen Servers vergessen worden herauszunehmen. Dadurch wurde nicht auf dem alten FS gesichert bzw. vom CFS wurde mangels belegtem Staging-Ordner nicht mehr "zurück" repliziert.
3. Staging-Ordner auf 16 GB vergrößert, später ca. 7 GB belegt, daher auf 64 GB aktuell gesetzt.
4. Somit liegen für einen Zeitraum von ca. 1-2 Tagen geänderte Daten auf dem neuen CFS, die nicht repliziert worden sind.
Mittlerweile sieht es aber besser aus, da er immer mal wieder repliziert bzw. ich viele Ereignis-IDs 4412 sehen kann. Leider aber in einer sehr geringen Geschwindigkeit. Zumindest läuft es richtig (vom CFS zum SF), wenn es heißt:
Ursprünglicher Dateipfad: H:\home\"username"\Documents\Default.rdp
Neuer Name im Konfliktordner: Default-{1CC56DCC-D084-4BCA-ABAC-2EB469255623}-v4697.rdp
Stamm des replizierten Ordners: H:\home
Datei-ID: {AB991D4E-2559-48FE-A9DD-1838AA54D4F6}-v19818528
Name des replizierten Ordners: Home
So sind es wenigstens seit gestern Abend ca. 5 GB an Replikationsmasse hinzugekommen. Nur benötigen die User am besten jetzt die zuletzt bearbeiteten Dateien. Wenn ich aber die Replikation deaktiviere, neu erstell' und den CFS als Master nehme, dann überschreibt er doch den FS. Oder liege ich hier falsch?
Edit: Ist es möglich vom CFS die Sache zu beschleunigen, so dass ich den alten SF als Master wieder konsistent habe?
Edit2: Ist es schädlich die Staging Größe auf 64 GB beim FS und CFS zu belassen? Aktuell sehe ich noch viele Dateien auf dem alten FS, die noch nicht gestaged worden sind. Oder dauert es seine Zeit?
vielen Dank für deine Antwort!
Noch einmal in der Kürze was genau passiert ist (nachdem schon Einiges vorher erfolgreich repliziert worden ist).
FS=File-Server (alte phys. Maschine)
CFS=ClusterFileServer (zwei neue Knoten, soll den alten FS ersetzen)
1. Replikation gestartet (FS ist natürlich als Master ausgewählt)
2. Replikation ist bei ca. 40% angehalten (ca. 320 GB Gesamtgröße), Staging-Ordner ist gegen die Wand gefahren.
Leider ist das Ordnerziel des neuen Servers vergessen worden herauszunehmen. Dadurch wurde nicht auf dem alten FS gesichert bzw. vom CFS wurde mangels belegtem Staging-Ordner nicht mehr "zurück" repliziert.
3. Staging-Ordner auf 16 GB vergrößert, später ca. 7 GB belegt, daher auf 64 GB aktuell gesetzt.
4. Somit liegen für einen Zeitraum von ca. 1-2 Tagen geänderte Daten auf dem neuen CFS, die nicht repliziert worden sind.
Mittlerweile sieht es aber besser aus, da er immer mal wieder repliziert bzw. ich viele Ereignis-IDs 4412 sehen kann. Leider aber in einer sehr geringen Geschwindigkeit. Zumindest läuft es richtig (vom CFS zum SF), wenn es heißt:
Ursprünglicher Dateipfad: H:\home\"username"\Documents\Default.rdp
Neuer Name im Konfliktordner: Default-{1CC56DCC-D084-4BCA-ABAC-2EB469255623}-v4697.rdp
Stamm des replizierten Ordners: H:\home
Datei-ID: {AB991D4E-2559-48FE-A9DD-1838AA54D4F6}-v19818528
Name des replizierten Ordners: Home
So sind es wenigstens seit gestern Abend ca. 5 GB an Replikationsmasse hinzugekommen. Nur benötigen die User am besten jetzt die zuletzt bearbeiteten Dateien. Wenn ich aber die Replikation deaktiviere, neu erstell' und den CFS als Master nehme, dann überschreibt er doch den FS. Oder liege ich hier falsch?
Edit: Ist es möglich vom CFS die Sache zu beschleunigen, so dass ich den alten SF als Master wieder konsistent habe?
Edit2: Ist es schädlich die Staging Größe auf 64 GB beim FS und CFS zu belassen? Aktuell sehe ich noch viele Dateien auf dem alten FS, die noch nicht gestaged worden sind. Oder dauert es seine Zeit?
Leider ist das Ordnerziel des neuen Servers vergessen worden herauszunehmen.
Es hätte nie und nimmer reingenommen werden dürfen!3. Staging-Ordner auf 16 GB vergrößert, später ca. 7 GB belegt, daher auf 64 GB aktuell gesetzt.
Wenn das Staging vollläuft, dann kann das verschiedene Ursachen haben. z.B.- sehr viele Änderungen inerhalb kurzer Zeit (Anzahl der Datenblöcke)
- schlechte oder/und langsame Netzwerkverkverbindung zwischen den Partnern
Nimm die Replikation wie schon von mir beschrieben raus. (Punkte 1-3)
Dann die neueren Dateien z.B. mittels Robocopy vom CFS auf den FS kopieren. Aber nicht spiegeln! Also kein /MIR Schalter!
Damit solltest Du einen halbwegs konsistenten Bestand hinbekommen.
Dann erst wie schon vom mir beschrieben wieder die Replikation aufbauen. (Punkte 4-8)
Wie ich herausgefunden habe, halten sich die Änderungen in Grenzen. Die Replikation funktioniert für aktuelle und alte Daten. Zumindest sehe ich es an den Logs und den Zielen, dass was passiert. Ich denke, hier ist es am besten einen Diagnosebericht abzuwarten und dann zu sehen, bei welchem Benutzer samt Daten es zu Inkonsistenz gekommen ist.
Ist diese Meldung "normal" und gehört zum Thema "kann passieren"?
Der DFS-Replikationsdienst wurde wiederholt daran gehindert, eine Datei zu replizieren. Der Grund besteht in fortdauernden Freigabeverletzungen für die Datei. Der Dienst konnte das Staging für eine Datei für die Replikation aufgrund einer Freigabeverletzung nicht durchführen.
Hier handelt es sich häufig um .URL- und .temp-Dateien.
Gibt es noch wichtige cmdlets wie eine Replikation neugestartet werden kann? Oder reicht es den Replikations-Dienst zu beenden, so dass der zweite Knoten (vom Cluster) einspringt und dann den Dienst "frisch" (neu) ausführt. Oder bringt das nichts?
Ist diese Meldung "normal" und gehört zum Thema "kann passieren"?
Der DFS-Replikationsdienst wurde wiederholt daran gehindert, eine Datei zu replizieren. Der Grund besteht in fortdauernden Freigabeverletzungen für die Datei. Der Dienst konnte das Staging für eine Datei für die Replikation aufgrund einer Freigabeverletzung nicht durchführen.
Hier handelt es sich häufig um .URL- und .temp-Dateien.
Gibt es noch wichtige cmdlets wie eine Replikation neugestartet werden kann? Oder reicht es den Replikations-Dienst zu beenden, so dass der zweite Knoten (vom Cluster) einspringt und dann den Dienst "frisch" (neu) ausführt. Oder bringt das nichts?
Ist diese Meldung "normal" und gehört zum Thema "kann passieren"?
Der DFS-Replikationsdienst wurde wiederholt daran gehindert, eine Datei zu replizieren. Der Grund besteht in fortdauernden Freigabeverletzungen für die Datei. Der Dienst konnte das Staging für eine Datei für die Replikation aufgrund einer Freigabeverletzung nicht durchführen.
Ja klar, wenn die Datei am Ziel in Benutzung ist.Der DFS-Replikationsdienst wurde wiederholt daran gehindert, eine Datei zu replizieren. Der Grund besteht in fortdauernden Freigabeverletzungen für die Datei. Der Dienst konnte das Staging für eine Datei für die Replikation aufgrund einer Freigabeverletzung nicht durchführen.
Hi
also Profile zu replizieren wird meines Wissens nach von MS nicht empfohlen wenn beide Punkte aktiv sind.
Wie oben erwähnt wäre Robocopy das Mittel zur Wahl.
Die .temp Dateien kannst du aus der Replication im DFS R ausschließen. (Bitte auch gleich die thumbs.db und andere ggf Datenbanken auf welche zugegriffen wird z.B. Access)
Außerdem kannst du im DFSR die Geschwindigkeit angeben in der repliziert wird. Tagsüber wenn gearbeitet wird garnicht und wenn dann nur nachts Full Speed um kaputte Profile zu vermeiden)
Den DFSR Dienst kann man nicht mehr so einfach beenden der beendet sich nicht mehr bzw das beenden verläuft in einem Timeout . Dazu musst du den Server runterfahren.
Das kannst du nur mit den Replicationszeiten/Geschwindigkeiten einstellen.
mit freundlichen Grüßen Nemesis
also Profile zu replizieren wird meines Wissens nach von MS nicht empfohlen wenn beide Punkte aktiv sind.
Wie oben erwähnt wäre Robocopy das Mittel zur Wahl.
Die .temp Dateien kannst du aus der Replication im DFS R ausschließen. (Bitte auch gleich die thumbs.db und andere ggf Datenbanken auf welche zugegriffen wird z.B. Access)
Außerdem kannst du im DFSR die Geschwindigkeit angeben in der repliziert wird. Tagsüber wenn gearbeitet wird garnicht und wenn dann nur nachts Full Speed um kaputte Profile zu vermeiden)
Den DFSR Dienst kann man nicht mehr so einfach beenden der beendet sich nicht mehr bzw das beenden verläuft in einem Timeout . Dazu musst du den Server runterfahren.
Das kannst du nur mit den Replicationszeiten/Geschwindigkeiten einstellen.
mit freundlichen Grüßen Nemesis
also Profile zu replizieren wird meines Wissens nach von MS nicht empfohlen wenn beide Punkte aktiv sind.
Ja. Wenn beide Ziele im DFS sind und der Zugriff auf die Profile über DFS erfolgt, dann gibts heir Probleme.Wenn der Zugriff aber nicht über DFS erfolgt, dann kann man das so machen, wenn sich der Benutzer nicht gleichzeitig an beiden Standorten anmeldet (z.B. Remote-Zugriff, oder Team- oder Admin-Konto, welches an beiden Standorten genutzt wird)
Der heutige Stand sieht so aus.
- Eigenschaften/Größe beider Ziele sehen so gut wie gleich aus... hier sind nur ein paar hundert Dateien die fehlen... vermutlich .tmp usw.
- Die Staging-Size hatte ich zwischenzeitlich auf 64 GB gesetzt, da ich eine Meldung über 23 GB an Nutzung des Staging-Ordners bekommen habe.
Trotzdem gibt es noch folgendes. In der "ConflictAndDeletedManifest.xml" kann ich die Konflikte und Änderungen genau herausfinden. Leider nur bis zum 21.12. Hier war wohl der Ordner nicht groß genug gewählt, so dass er das älteste gelöscht hat, richtig?
CFS:
- Staging-Ordner steht bei 11 GB, Ordner mit Erstelldatum vom 19.12., jedoch mit Änderungsdatum von heute (27.12.) - Werden Staging-Dateien (.frx) aktualisiert, wenn sie nicht verschoben werden können, und daher mit neuem Timestamp gesetzt?
- ConflictAndDeleted steht bei 12,2 GB
FS:
- Staging-Ordner steht bei 8,7 GB und "ConflictAndDeleted" bei 0 GB.
Edit: Kann man hier im Staging noch auf einen "grünen Pfad" kommen, also kann ich noch damit rechnen, dass hier gestaged wird oder war's das?
In anderen Ordnern, auf dem alten FS wo die Staging-Size nicht ausgereizt worden ist, sehe ich noch Dateien datiert vom 1.12. Passiert hier noch was oder liegen die solange bis gelöscht?
Wenn ich mir die Profile der User ansehe, die sich am nächsten Tag gemeldet hatten, gibt es bis heute kein Staging von neu zu alt. Darauf zu hoffen kann ich wohl vergessen, außer ich mach den CFS unsinnig zum Master, nur dann sind alle wieder geänderten Daten auf dem SF wieder nicht richtig.
Also ist die einzige Lösung alles Geänderte suchen von/bis und es per robocopy in das alte Verzeichnis, sofern möglich händisch zu verschieben!?!?
- Eigenschaften/Größe beider Ziele sehen so gut wie gleich aus... hier sind nur ein paar hundert Dateien die fehlen... vermutlich .tmp usw.
- Die Staging-Size hatte ich zwischenzeitlich auf 64 GB gesetzt, da ich eine Meldung über 23 GB an Nutzung des Staging-Ordners bekommen habe.
Trotzdem gibt es noch folgendes. In der "ConflictAndDeletedManifest.xml" kann ich die Konflikte und Änderungen genau herausfinden. Leider nur bis zum 21.12. Hier war wohl der Ordner nicht groß genug gewählt, so dass er das älteste gelöscht hat, richtig?
CFS:
- Staging-Ordner steht bei 11 GB, Ordner mit Erstelldatum vom 19.12., jedoch mit Änderungsdatum von heute (27.12.) - Werden Staging-Dateien (.frx) aktualisiert, wenn sie nicht verschoben werden können, und daher mit neuem Timestamp gesetzt?
- ConflictAndDeleted steht bei 12,2 GB
FS:
- Staging-Ordner steht bei 8,7 GB und "ConflictAndDeleted" bei 0 GB.
Edit: Kann man hier im Staging noch auf einen "grünen Pfad" kommen, also kann ich noch damit rechnen, dass hier gestaged wird oder war's das?
In anderen Ordnern, auf dem alten FS wo die Staging-Size nicht ausgereizt worden ist, sehe ich noch Dateien datiert vom 1.12. Passiert hier noch was oder liegen die solange bis gelöscht?
Wenn ich mir die Profile der User ansehe, die sich am nächsten Tag gemeldet hatten, gibt es bis heute kein Staging von neu zu alt. Darauf zu hoffen kann ich wohl vergessen, außer ich mach den CFS unsinnig zum Master, nur dann sind alle wieder geänderten Daten auf dem SF wieder nicht richtig.
Also ist die einzige Lösung alles Geänderte suchen von/bis und es per robocopy in das alte Verzeichnis, sofern möglich händisch zu verschieben!?!?
Das habe ich doch alles schon mal erklärt?!
Auf dem CFS dürften doch jetzt noch keine neueren Dateien sein. Denn die Initialreplikation ist doch offensichtlich noch nicht durch. Also darfst Du auch auf dem CFS keine Dateien oder Verzeichnisse ändern (lassen). Egal ob über DFS-N (da sollte der CFS ja raus) oder ob direkt über Servername.
Erst wenn die Initialreplikation vom Master (FS) zum Replikat (CFS) min. einmal vollständig und erfolgreich gelaufen ist kann und wird er anfangen, auch vom CFS zum FS zu replizieren.
Auf dem CFS dürften doch jetzt noch keine neueren Dateien sein. Denn die Initialreplikation ist doch offensichtlich noch nicht durch. Also darfst Du auch auf dem CFS keine Dateien oder Verzeichnisse ändern (lassen). Egal ob über DFS-N (da sollte der CFS ja raus) oder ob direkt über Servername.
Erst wenn die Initialreplikation vom Master (FS) zum Replikat (CFS) min. einmal vollständig und erfolgreich gelaufen ist kann und wird er anfangen, auch vom CFS zum FS zu replizieren.
Auf dem CFS sind bereits neue Dateien. Wenn ich mir die Größen ansehe, ist die Initialreplikation längst durch. Vor Weihnachten war sie noch bei 40%.
Und das sollte ersichtlich sein, wenn beide Staging-Ordner (so gut wie) leer sind bzw. der Konflikt-Ordner größer wird, da er wohl möglich diese Dateien umbenennen wird und darin ablegt?
Zitat von @emeriks:
Erst wenn die Initialreplikation vom Master (FS) zum Replikat (CFS) min. einmal vollständig und erfolgreich gelaufen ist kann und wird er anfangen, auch vom CFS zum FS zu replizieren.
Erst wenn die Initialreplikation vom Master (FS) zum Replikat (CFS) min. einmal vollständig und erfolgreich gelaufen ist kann und wird er anfangen, auch vom CFS zum FS zu replizieren.
Und das sollte ersichtlich sein, wenn beide Staging-Ordner (so gut wie) leer sind bzw. der Konflikt-Ordner größer wird, da er wohl möglich diese Dateien umbenennen wird und darin ablegt?
Okay, der Pfad ist als einziger nicht dabei, der (erfolgreich) abgeschlossen worden ist. Also abwarten und nichts tun?
Gibt es irgendwo ein Log, wo ich live sehen kann, wieweit er ist? Oder ist die Diagnose mit dem Zählen der Daten das Einzige Mittel?
Edit: Hast du vielleicht noch andere Tipps, außer der Staging-Size, wie ich die Replikation beschleunigen kann? Denn auf den Kosten ist nichts zu sehen. Das SAN langweilt sich auch eher, als das dort was passiert.
Gibt es irgendwo ein Log, wo ich live sehen kann, wieweit er ist? Oder ist die Diagnose mit dem Zählen der Daten das Einzige Mittel?
Edit: Hast du vielleicht noch andere Tipps, außer der Staging-Size, wie ich die Replikation beschleunigen kann? Denn auf den Kosten ist nichts zu sehen. Das SAN langweilt sich auch eher, als das dort was passiert.
Okay, der Pfad ist als einziger nicht dabei, der (erfolgreich) abgeschlossen worden ist. Also abwarten und nichts tun?
Welcher Pfad?Hast Du mehrere Replikationsgruppen? Oder in einer Gruppe mehrere Ordnerpaare?
Es gibt mehrere Replikationsgruppen.
Edit: Ich habe jetzt einmal mittels PS dfsrdiag replicationstate auf dem CFS die aktiven Verbindungen mir anzeigen lassen. Anbei das Ergebnis.
Edit: Ich habe jetzt einmal mittels PS dfsrdiag replicationstate auf dem CFS die aktiven Verbindungen mir anzeigen lassen. Anbei das Ergebnis.
