Problem mit DFS-R

[JEKRFW 10]

Hallo,

 

folgende Situation:

 

- 2 Standorte, an Standort A DC mit 2003R2, an Standort B DC mit 2008 Std.

- ein Ordner (ca. 6 GB) soll an beiden Standorten synchron gehalten werden

- ich habe auf dem 2003er eine Replikationsgruppe eingerichtet (DFS-R)

- habe am Freitag Abend (16.01) die Intitial Sync gestartet und wollte sie übers

Wochenende laufen lassen

 

So, jetzt zu meinem Problem:

 

Am Samstag (17.01) um 09:17 kam die Meldung "Der DFS-Replikationsdienst hat erkannt, dass der für den replizierten Ordner unter dem lokalen Pfad "E:\xxxxx" verwendete Stagingspeicher die obere Grenze überschritten hat. Der Dienst versucht, die ältesten Stagingdateien zu löschen. Dies kann die Leistung beeinträchtigen. "

 

Direkt dannach "Der DFS-Replikationsdienst hat alte Stagingdateien für den replizierten Ordner unter dem lokalen Pfad "E:\xxxxx" erfolgreich gelöscht. Der Stagingspeicher liegt nun unter der oberen Grenze. "

 

Um 13:01 passierte folgendes:

"Der DFS-Replikationsdienst beendet die Kommunikation mit Partner XXXXX für Replikationsgruppe XXX aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen."

 

Direkt danach:

"Der DFS-Replikationsdienst hat erfolgreich eine eingehende Verbindung mit Partner "XXXXX" für Replikationsgruppe "XXX" hergestellt."

 

Um 13:47 dann diese Meldung:

"Der DFS-Replikationsdienst hat die erste Replikation für den replizierten Ordner unter dem lokalen Pfad "XXXXX" erfolgreich abgeschlossen."

 

Ey iss ja geil habe ich gedacht. Aber leider sind von den ca. 6 GB nur ca. 800 MB drüben angekommen.

 

Wenn ich einzelne Dateien neu anlege werden die einwandfrei rüber repliziert. In beide Richtungen. Löschen genauso.

 

Wie kriege ich denn nun die Daten vollständig? Kann ich den Initial Sync nochmal starten?

[olc 18]

N'Abend,

 

was Du schreibst (von den Events her) sieht soweit ja erst einmal gut aus bzw. nicht grundsätzlich "schlecht". :)

 

Ey iss ja geil habe ich gedacht. Aber leider sind von den ca. 6 GB nur ca. 800 MB drüben angekommen.

 

Was für Daten liegen denn in dem zu replizierenden Ordnern? Sind vielleicht Dateitypen geblockt? Wie setzen sich die Dateien / Ordner zusammen?

 

Vielleicht kannst Du einmal prüfen, welche Daten denn nicht repliziert wurden.

 

Wie "errechnest" Du die 6GB Daten? Rechtsklick auf den Ordner und Eigenschaften? Das ist ggf. nicht sonderlich zuverlässig, da in dem Ordner standardmäßig ja auch die Staging / ConflictedAndDeleted Daten liegen.

 

Wie kriege ich denn nun die Daten vollständig? Kann ich den Initial Sync nochmal starten?

 

Grundsätzlich kannst Du über das Deaktivieren und erneutes Aktivieren des "Slave"-Servers ein neues initial sync einleiten. Dabei werden die Daten des "Slaves" dann nicht autorativ erneut repliziert. Sollten auf dem "Slave" in der Zwischenzeit Änderungen stattgefunden haben, werden diese abber ggf. gelöscht / in den ConflictedAndDeleted / PreExisting Ordner verschoben.

 

Die Frage ist, ob das Ergebnis das gewünschte sein wird. Ggf. ist es das selbe wie im Moment, wenn Du ein eventuell vorhandenes Problem nicht behebst. ;)

 

Was sagen denn die Health Reports für die Replikationsgruppe?

 

Viele Grüße

olc

[JEKRFW 10]

was Du schreibst (von den Events her) sieht soweit ja erst einmal gut aus bzw. nicht grundsätzlich "schlecht".

 

Das habe ich auch gedacht, nur das Ergebnis passt noch nicht ganz :cool:

 

Das mit den Dateiausschlüssen wäre ne Möglichkeit. Sind ne ganze Menge Foto's.

Das man Dateitypen ausschliessen kann wusste ich, aber ist sowas standardmäßig aktiviert ? Ich habe es jedenfalls nicht gemacht. Werde ich aber morgen überprüfen.

 

Die 6 GB sind zwar wie Du beschrieben hast ermittelt worden, aber vorher. Jetzt sind es auf dem Quellserver ca. 11

[olc 18]

Hi,

 

Das habe ich auch gedacht, nur das Ergebnis passt noch nicht ganz :cool:

 

Kann ich verstehen. :D

 

Das mit den Dateiausschlüssen wäre ne Möglichkeit. Sind ne ganze Menge Foto's.

Das man Dateitypen ausschliessen kann wusste ich, aber ist sowas standardmäßig aktiviert ? Ich habe es jedenfalls nicht gemacht. Werde ich aber morgen überprüfen.

 

Also standardmäßig sind nur "*.bak", "~*" und "*.tmp" Dateien geblockt, siehe Windows Server How-To Guides: Teil 5 - Zugelassene Dateitypen - ServerHowTo.de . Fotos sollten also durchgehen.

 

Wie gesagt, schau erst einmal, welche Daten denn genau nicht angekommen sind und wo diese liegen. Ggf. Health Report prüfen.

Welches Service Pack ist auf dem Windows Server 2003 installiert und welche DFSR Hotfixes hast Du ausgerollt?

 

Die 6 GB sind zwar wie Du beschrieben hast ermittelt worden, aber vorher. Jetzt sind es auf dem Quellserver ca. 11

 

Ok, also wahrscheinlich mit nun zusätzlichen 5GB Staging Daten gefüllt.

 

Viele Grüße

olc

[JEKRFW 10]

Hi,

 

ich bin noch nicht wirklich weiter :mad:

 

Habe das mit den Ausschlüssen mal gecheckt -> negativ

Der Health-Report zeigt keine Warnung und keinen Fehler

 

Wir sind aber gerade am überlegen das ganze DFS Konzept nochmal zu überdenken.

 

Im Moment ist wirklich nur die Anforderung, diesen einen User-Ordner zu replizieren, damit er an beiden Standorten verfügbar ist.

Hierbei ergibt sich aber auch schon das nächste Problem. Dem User wird sein Laufwerk U:\ gem. Profileinstellungen verbunden. Da ist per UNC-Pfad der Server an Standort A hinterlegt.

 

Heisst also auch an Standort B wird er diesen damit verbinden. Was bei der Bandbreite der Leitung nun wirklich keinen Spaß macht :cry:

 

Deshalb ja auch die Idee mit der DFS-Replikation. Da der User aber eh nicht (nur selten) aber den Laufwerksbuchstaben geht, sondern nur über seine "Eigenen Dateien" habe ich ihm das manuell verbogen :D

 

Ist natürlich wieder "EDV zu Fuß", aber die schnellste Möglichkeit.

Das ganze geht doch bestimmt auch eleganter, wenn man mit Namespaces arbeitet. Habe da was von Site Awareness gelesen. Würde das so funktionieren das ich die User Ordner an beiden Standorten synchron halte, im AD das Userlaufwerk mit dem Namespace verbinde und er dann erkennt an welchem Standort er sich befinden und dann den entsprechenden Server ausswählt ???

[mikewi 10]

Hallo,

 

dieses Problem kenn ich und die Lösung ist ganz einfach!

Wie dir die Meldung schon gesagt hat ist der "Stagingspeicher" zu klein, Windows kann die zu replizierenden Daten nicht korrekt zerlegen und wieder zusammensetzen. Das kann u. a. soweit gehen, dass dir deine Server (regelmäßig) abstürzen wenn Daten synchronisiert werden sollen.

Den Stagingspeicher kannst Du mit dem DFS-Manger, nicht Distibuted-File-System!!!!!!, ändern.

Öffne dazu den DFS-Manger und dort die entsprechende Synchronisationsgruppe (ich nenne das einfach mal so weil mir die korrekte Bezeichnung gerade nicht einfällt) und erhöhe bei allen beteiligten Servern den Cache-Speicher. Je nach Datenvolumen erst mal um 10% -30%. Da musst Du dich eben rantasten, wie viel Cache-Speicher benötigt wird. Danach sollte es ohne Probleme funktionieren.

 

 

Am Samstag (17.01) um 09:17 kam die Meldung "Der DFS-Replikationsdienst hat erkannt, dass der für den replizierten Ordner unter dem lokalen Pfad "E:\xxxxx" verwendete Stagingspeicher die obere Grenze überschritten hat. Der Dienst versucht, die ältesten Stagingdateien zu löschen. Dies kann die Leistung beeinträchtigen. "

 

Wie kriege ich denn nun die Daten vollständig? Kann ich den Initial Sync nochmal starten?

[olc 18]

Guten Abend,

 

es macht sich in solchen Fällen immer ganz gut, wenn man einen neuen Thread zu dem neuen Problem öffnet - im Grunde hat das ja nun wenig mit der Ausgangslage bzw. dem ursprünglichen Problem zu tun. ;)

 

Wir sind aber gerade am überlegen das ganze DFS Konzept nochmal zu überdenken.

 

Das, was Du geschrieben hast, ist grundsätzlich möglich. Die Clients suchen sich bei eingeschaltetem Site-Costing und aktiviertem "Bridge all site links" standardmäßig einen Server am eigenen Standort. Nutzt Du also DFSN-Ziele für die Profile, ist das so machbar.

 

Distributed File System: Frequently Asked Questions

 

Gerade in Bezug auf DFSR lauern da aber einige Fallstricke - so mußt Du sicherstellen, daß die Replikation der Benutzerdaten definitiv zum anderen Standort repliziert wurde, wenn der Benutzer "wandert". Sonst bekommst Du schlimmstenfalls massive Probleme mit den Profilen aufgrund der inkonsistenten Daten (bezieht sich auf Romaing Profiles).

 

Hast Du dann noch Ordnerumleitungen aktiv (etwa für Eigene Dateien etc.), dann läufst Du auch in starke "Sharing Violations", also dem Versuch von DFSR Dateien zu replizieren, die exklusiv für den Zugriff der Applikation geblockt sind (z.B. Access oder Excel Dateien).

 

Das muß kein Problem darstellen, denn DFSR versucht es später wieder - kann aber zum Problem werden, wenn es sich um sehr viele Dateien mit den Zugriffsverletzungen handelt und setzt ggf. die Replikationsperformance herunter. Auch hier wäre zu beachten, daß die Benutzer immer Ordnungsgemäß Ihre Client-Systeme herunterfahren, um nicht dauerhafte Locks auf Dateien zu haben, die dann wiederum nicht repliziert werden können.

 

Bei guter Planung kann das jedoch gut funktionieren.

 

dieses Problem kenn ich und die Lösung ist ganz einfach!

 

Lies Dir den Thread einmal komplett durch - dann siehst Du, daß das nicht das Problem war. Die Initialreplikation benötigt natürlich einiges an Staging Speicher, von daher wurde der Fehler geloggt. Die Initialreplikation wurde jedoch laut Logs auch abgeschlossen, weshalb das Problem (falls es denn eins gibt) an anderer Stelle zu suchen ist. ;)

 

Aber grundsätzlich hast Du natürlich vollkommen Recht - die Staging-Quotas sind ein kritischer Punkt einer DFSR Infrastruktur.

 

Viele Grüße

olc

[JEKRFW 10]

*** PROBLEM GELÖST ***

 

Ich hab's gefunden.

Unglaublich dämliche Geschichte :D:D:D

 

Habe gestern das ganze nochmal neu gemacht. Gestern Mittag den Initial Sync neu gestartet. Habe das im Laufe des Nachmittages verfolgt wie die Ordner rüber wandern. Irgendwann blieb die Ordnergröße aber bei 820 MB stehen :mad:

Man konnte aber in den Eigenschaften des Datenträgers sehen das der Verfügbare Plattenplatz immer weiter abnahm. Naja, ich habe es einfach laufen lassen. Heute morgen zuerst auf die Ordnergröße geschaut -> immer noch (nur) 820 MB. Dann den Health Report angeschaut. Demnach wurden 6,79 GB repliziert. Also genau die Menge des Quellordners.

 

Um es kurz zu machen. Es lag an den Zugriffsrechten. Wenn ich auf einen replizierten Unterordner auf dem Zielsystem zugreifen wollte kam die Benutzerkontensteuerung von 2008 und meldete das ich keine Zugriffsrechte habe, mit Klick auf "Fortsetzten" gehts weiter. Wenn man das gemacht hat zeigte er mir in den Eigenschaften des Unterordners auch die Größe an. Vorher war da Null. Also, meinem Benutzer auf den gesamten Ordner incl. aller Unterordner Vollzugriff gegeben und siehe da die Größe bertägt 6,79 GB :D

 

Na da soll mal einer drauf kommen:shock:

 

Trotzdem vielen Dank für eure Hilfe

[olc 18]

Hi,

 

ok - jetzt gehst Du also wieder zum Urspungsthema über. Nicht sonderlich übersichtlich. :wink2:

 

*** PROBLEM GELÖST ***

Um es kurz zu machen. Es lag an den Zugriffsrechten.

 

Na da soll mal einer drauf kommen:shock:

 

Ich wiederhole mich bei dem Thema hier im Board immer wieder (siehe auch oben) - aber Rechtsklick --> Eigenschaften auf den Ordner ist keine zuverlässige Art und Weise, die replizierte Datenmenge zu bestimmen. Dein Problem bestätigt das einmal mehr... :D

 

Danke für Deine Rückmeldung und Gruß

olc

[JEKRFW 10]

aber Rechtsklick --> Eigenschaften auf den Ordner ist keine zuverlässige Art und Weise, die replizierte Datenmenge zu bestimmen. Dein Problem bestätigt das einmal mehr...

 

Ich werde es mir hinter die Ohren schreiben :cool:

 

Das ist doch das schöne an unserem Job. Man lernt nie aus, und durch solche Erlebnisse wird es besonders gefestigt :D:D:D

 

Zwei Tage Gesuche wegen so 'nem ******* :cry::cry::cry:

[olc 18]

Das ist doch das schöne an unserem Job. Man lernt nie aus, und durch solche Erlebnisse wird es besonders gefestigt :D:D:D

 

Zwei Tage Gesuche wegen so 'nem ******* :cry::cry::cry:

 

;)

 

Hauptsache man lernt daraus und ist nicht lernresistent. :)

Schön, daß es letztendlich dann doch geklappt hat. :)

 

Viele Grüße

olc