DFS Replication Staging Inkonsistenzen bereinigen

[danieldd 12]

Hallo zusammen,

 

wir verwenden aktuell für die Replikation von Fileserver Daten zwischen verschiedenen Standorten die DFSR.

 

Aktuell scheinen in den Staging-Verzeichnissen in DfsrPrivate Inkosistenzen aufzutreten, wodurch permanent Traffic zwischen zwei Replikationspartnern (Windows 2003 und Windows 2008R2) für einen Replikations-Ordner entsteht.

 

Sobald der DFS Backlog des betroffenen Replikations-Ordners auf 0 steht, versenden die Replikationsserver laut Process Monitor tausende von "TCP Send" Paketen gegenseitig. Gleichzeitig liest der Master Server permanent in vier unterschiedlichen Staging-Verzeichnissen immer die gleichen Staging Informationen.

 

Die Replikation funktioniert grundsätzlich korrekt, lediglich scheinen irgend welche Staging Informationen nicht mehr konsistenz zu sein, wodurch permanent Steuerinformationen zwischen den beiden Replikationspartnern stattfinden.

 

Im Dfsr00100.log lassen sich hierzu keinerlei Warnungen oder Errors finden.

 

Auch die Staging Quotas sind ausreichend groß gesetzt.

 

 

Wie können die fehlerhaften Staging Informationen gefunden werden?

 

Wie können die Staging Informationen bereinigt werden, ohne alle Daten erneut replizieren zu müssen?

 

Wie funktioniert das Pre-Seeding wenn schon Staging Files existieren?

 

 

Jede Anregung bzw. Tipp ist hilfreich :)

 

Danke im Voraus.

[olc 18]

Hi Daniel, willkommen an Bo(a)rd, :)

 

im Normalfall sollte es keine "Inkonsistenzen" in den Staging Verzeichnissen geben - was nicht heißt, daß sich die Verzeichnisse vom Inhalt her nicht unterscheiden können. Das kann der Fall sein, daß ja mehrere Replikationspartner existieren.

 

Wenn Du handles auf den Staging Dateien hast, ist die Chance groß, daß es sich um einen Virenscanner o.ä. Filtertreiber handelt, der dort Dinge tut, die er lieber bleiben lassen sollte.

 

Welchen AV-Scanner hast Du im Einsatz - supported dieser DFSR?

 

Das Pre-Seeding ist hier erläutert: Get out and push! Getting the most out of DFSR pre-staging - Ask the Directory Services Team - Site Home - TechNet Blogs

 

Viele Grüße

olc

[danieldd 12]

Hallo olc,

 

danke für deine Antwort.

Aktuell läuft der Avira AntiVir Server, dieser läuft auch auf allen anderen 2k3 und 2k8 Servern ohne Probleme. Um den Scanner ausschließen zu können, wurde dieser bereits komplett deaktiviert, das Problem tritt aber weiterhin auf.

 

Die Staging Verzeichnisse sind auf den beiden Replikationsservern unterschiedlich, dass sollte nicht das Problem sein, aber sobald der Backlog des betroffenen Replikations-Ordners auf 0 geht, d. h. keine Daten mehr zur Übertragung anstehen, verursacht die Replikation unendlich viel WAN Traffic, da die dfsr.exe eines System laut Process Monitor tausende von "TCP Send" Paketen an den Partner schickt und permanent in 4 Staging Verzeichnissen lokal liest und hier scheinbar irgend welche Meta Informationen übertragen möchte aber keine Daten mehr überträgt.

Es scheint also als ob in diesen vier Staging Verzeichnissen Fehler enthalten sind.

 

Das Problem tritt auf, seit dem einmalig eine große Datenmenge übertragen wurde, welche die Staging Quota überschritten hat.

 

Kann ein manueller Cleanup der Staging Informationen vorgenommen werden?

 

Danke

 

grüsse

daniel

[olc 18]

Hi Daniel,

 

ein Deaktiveren des AV Scanners reicht nicht, damit der Filtertreiber nicht mehr aktiv ist. Du müßtest es deinstallieren. Avira supported meines Wissens DFSR nicht offiziell in Ihren Listen. Aber vielleicht hat sich da auch etwas geändert.

 

Es gibt sicherlich eine WMI-Methode zum Löschen des Cleanups. Aber Du kannst es Dir auch einfach machen, indem Du den DFSR Dienst stoppst, den Inhalt des Staging Ordners löschst, um danach den DFSR Dienst wieder zu starten. Die Staging Daten werden danach neu aufgebaut, was etwas CPU und HDD Last verursachen kann - je nach anstehender Replikationsdatenmenge im Backlog der Zwischenzeit.

 

Meines Wissens sollte es mit diesem Vorgehen keine Probleme geben.

 

Insgesamt halte ich es für wenig wahrscheinlich, daß das zu kleine Staging Quota verantwortlich dafür ist, daß der DFSR Dienst "durcheinander" gekommen ist. Es wäre das erste Mal, daß ich so etwas höre. :)

 

Viele Grüße

olc

[danieldd 12]

Hi olc,

 

an den Einstellungen der Staging Quotas denke ich liegt es nicht, es funktioniert mit allen anderen Replikations-Ordnern und Servern ebenfalls problemlos :)

Die beste Lösung wird sein, die Staging Informationen neu aufbauen zu lassen.

 

Wichtig ist, dass ich eine erneute Replikation aller Daten (weil die Daten ja aktuell auf beiden Servern schon identisch sind) ausschließen kann.

 

Müssen hierzu die Staging Dateien auf beiden Seiten gelöscht werden oder nur auf einem Server um einen Re-Sync vermeiden zu können?

 

Danke im Voraus

 

grüsse

daniel

[olc 18]

Hi,

 

meines Wissens löst der Neuaufbau des Staging Verzeichnisses keine Initialreplikation aus. Egal ob auf einem oder mehreren Servern initialisiert.

 

Viele Grüße

olc

[danieldd 12]

Hallo olc,

 

zur Info...die Lösung des Problems:

Die Staging Verzeichnisse mussten nicht neu erstellt werden.

Mit Hilfe des DFSR Logs aus C:\Windows\Debug am Empfänger (der Sender loggte hierzu leider nichts hilfreiches) konnte herausgefunden werden, dass vier Dateien (aus bisher unbekanntem Grund) nicht abgeglichen werden konnten.

 

Der passende Ausschnitt eines betroffenen Files lautete dazu:

20110908 10:09:18.680 5468 INCO 6582 InConnection::LogTransferActivity Failed to receive RAWGET uid:{xxx}-vxxx gvsn:{xxx}-vxxx fileName:xxx.img connId:{xxx} csId:{xxx} stagedSize:22216704 Error:

 

Nach manuellen Löschen dieser betroffenen Files wurden die Staging Informationen automatisch bereinigt und das Problem war behoben.

 

Danke für deine Hilfe.

 

grüsse

daniel

[olc 18]

Hi Daniel,

 

Im Dfsr00100.log lassen sich hierzu keinerlei Warnungen oder Errors finden.

 

Also gab es dann doch den entscheidenden Hinweis im Debug Log. :)

 

Vielen Dank für Deine Rückmeldung und viele Grüße

olc