DFSR Service bleibt hängen

[AndreP 0]

Hallo zusammen,

 

ich habe gerade ein Problem mit meiner DFS Replikation.

Der Dienst bleibt bei der Initialen Replikation nach einiger Zeit mit 100% CPU Last hängen.

 

Aber hier erst mal mein Szenario:

SERVER A - Produktivsystem

Ist ein Cluster, gebildet aus "Server A1" & "Server A2", beide auf VM.

 

SERVER B - Backup

Ist nativ, hat ein DFS Replikat, von dem dann Backups gezogen werden.

 

SERVER C - Backup

Ist nativ, hat ein DFS Replikat, von dem dann Backups gezogen werden.

 

Die Kombi lief bereits ohne Probleme.

Nachdem die DFSR Datenbank auf B & C irreparabel beschädigt war, habe ich folgendes gemacht:

• Alle Mitglieder der DFSR Gruppe deaktiviert
• DFSR Dienst auf B & C beendet
• Datenbank und DFSRPrivate auf B & C gelöscht
• DFSR Dienst auf B aktiviert
• Server A in der DFSR Gruppe aktiviert und gewartet bis er sich als Primärer meldet "Ereignis ID 4112"
• Server B in der DFSR Gruppe aktiviert

 

Server B startet auch brav die Erst-Replikation (ID 4102) und initialisiert das Laufwerk (ID 2002).

Ansonsten gleicht er einen Haufen Dateien ab (ID 4412).

 

Nach einigen Stunde steht dann der DFSR Dienst bei 100% und es passier nichts mehr.

Die Gegenstelle, Server A, meldet irgendwann dann einen Fehler bei der Kommunikation mit der Gegenstelle (ID 5002).

 

Ich habe bereits verschiedene Szenarien ausprobiert, immer mit dem gleichen Ergebnis.

 

Hat vielleicht jemand eine Idee, was dem Automaten fehlen könnte?

 

Schon mal Danke für Eure Mühen & Gruß

 

Andre P

 

 

 

Das hier sind die letzten Einträge des DFS-Logfiles von Server B:

20160601 22:43:27.262 1496 MEET  6356 Meet::LocalDominates Remote version dominates localgvsn:{A75068D7-1A92-4CEE-B522-255E30BF3A5E}-v279540 updateName:MZ-3312.jpg uid:{16345316-A1C6-4DC3-982E-8C2BF0239749}-v33198684 gvsn:{16345316-A1C6-4DC3-982E-8C2BF0239749}-v33198684 connId:{15F710BB-9C4A-49B2-BA29-B941511710F6} csName:Abteilungen

20160602 06:47:37.781 3252 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1804FDB60

20160602 06:47:37.781 2420 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1809FD530

20160602 06:47:42.859  256 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1802FDC90

20160602 06:47:42.859 3136 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F180BFD810

20160602 06:47:44.890  164 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F18107D520

20160602 06:47:44.890 2188 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F180E7D5B0

20160602 06:47:47.937 1372 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1806FD6C0

20160602 06:48:43.688 1104 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F180D7D910

20160602 06:48:44.703 1492 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F18047D600

20160602 06:48:49.735 2412 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F180FFD6B0

20160602 06:49:04.922 3528 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F180B7D4E0

20160602 06:49:13.016  412 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F18067D580

20160602 06:49:16.063 1496 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F18097D590

20160602 07:06:33.682 2452 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F18037DBB0

20160602 07:06:41.682  680 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1807FDAB0

20160602 07:06:42.682 1696 DOWN  1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1827BD9B0

 

[AndreP 0]

Hallo,

 

ich habe in den letzten Tagen diverse Szenarien ausprobiert, aber das Ergebnis ist immer wieder das Gleiche: der DFSR Dienst bleibt irgendwann mit 100% CPU Auslastung stehen.

Selbst das löschen und Neuanlegen der Replikationsgruppe brachte keinen Erfolg.

Aktuell lasse ich den DFSR Dienst den Datenbestand zum Replikationsziel kopieren (ohne Pre-seed). Mal sehen, was daraus wird...

 

Bei der Recherche in den Logs, ob er immer an bestimmten Files hängen bleibt, ist mir folgendes aufgefallen:

 

Eine Menge Verzeichnisse/Dateien überschreiten die Pfad-Länge von 255 Zeichen und

auf einigen Verzeichnissen habe die User die Berechtigungen "angepasst" und dabei sowohl SYSTEM, als auch den ADMINISTRATOR entfernt.

 

Kann das den Dienst absterben lassen?

Dann stellt sich mir auch noch die Frage, wie haben die User es überhaupt geschafft so lange Verzeichnisstrukturen anzulegen, dass die Länge von 255 Zeichen überschritten werden konnten?

 

Hat keiner einen Tipp, wie ich dem Fehler auf die Spur komme?

Oder kennt jemand jemanden, der einen kennt, der DFSR Profi ist?  :shock:

 

Gruß

Andre P.

[Weingeist 157]

Die Pfade bringt man schon länger hin. Kann die Hälfte des Windows auch damit umgehen (irgendwo um 32'000 oder warens doch 65'000 zeichen ist Schluss). Die andere Hälfte von Windows hat aber Mühe wens mehr als 255 Zeichen sind. Allen voran - was ich gar ned verstehe das es nach so vielen Jahren immer noch so ist - der Explorer. Der Windows Unterbau, also das Filesystem an sich, hat 0 Probleme mit langen Strukturen. Robocopy packts z.B. auch. Manche andere Programme wiederum ned. Ein Relikt aus alten Tagen das leider immer noch bei weitem nicht durchgefixt ist.

 

DFSR und Rechte: Nun, das ist theoretisch möglich, dass hier die fehlenden Berechtigungen mit reinpfuschen. Allerdings dürfte er deswegen ned hängenbleiben sondern müsste eigentlich Fehler produzieren wenn er tatsächlich keinen Zugriff hat.

Wenn es gewollt ist, das Admin und System keinen Zugriff haben und es Probleme macht, muss man mit Dienstkonten für die benötigten Dienste arbeiten, die dann auch in den entsprechenden Gruppen Mitglied sind.

 

Solche Konstrukte machen gerne immer wieder mal Probleme, weshalb manche Admins die Berechtigungen für System und oder Admin jeweils über Nacht hart setzen. Wiederum andere machen sich diese Mühe weil es - zumindest theoretisch - etwas weniger einfach ist, an die Daten zu kommen und passen eben alles auf Dienstkonten an. Ich entziehe dem System und den Admins vor allem im VDI-Bereich auch gerne Schreibrechte in Registry oder Filesystem die viele IO's produzieren oder mit Spy/Telemetry-Tätigkeit zusammenhängen. Man glaubt kaum, was da alles an unnötigen IO's zusammen kommen. Gleichzeitig gibts dann eine Dienst-Gruppe welche genau diese Rechte hat. Bei Problemen bzw. deren Lösung kommen Admin und System in die Gruppe rein und Problem wird gesucht.

[AndreP 0]

Hallo Weingeist,

Danke für Deine Antwort!

 

Das Robocopy diese Probleme nicht hat, habe ich auch schon gelesen und gemerkt. Ich hatte zuvor mit Robocopy den Pre-seed gemacht -ohne Probleme.

 

Ein Dienstkonto würde wahrscheinlich nicht helfen.

Die User sind hingegangen und haben die Vererbung in einigen Verzeichnissen ausgeschaltet und die übergeordneten Rechte nicht kopiert, sondern eigene (einzelne User) eingetragen.

Damit waren dann SYSTEM und Administrator weg. Oder kann man irgendwie gewisse Konten/Gruppen "erzwingen"?

 

Zu den IOs, wie kann ich die moitoren/analysieren?

Ist jetzt zwar ein anderes Thema, aber die Auslastung am Fileserver würde mich mal interessieren.

 

Gruß

Andre P.

[tesso 360]

Wenn die User Rechte am Dateisystem ändern können, stimmt aber schon grundsätzlich etwas nicht.

Aus welchem Grund ist das den Usern erlaubt?

[AndreP 0]

Hallo,

 

wir haben diverse Abteilungs-/Gruppenverzeichnisse, auf denen die entsprechenden User via Gruppenzugehörigkeit Vollzugriff haben.

Damit sollen die User die Möglichkeit haben eigene Unterstrukturen anzulegen und ggf. die Rechte selber weiter einschränken können für "sensiblere" Daten.

Leider und offensichtlich scheitert es aber an den Fähigkeiten und dem Verständnis der Vererbungslehre...

 

Der DFS Dienst ist diese Nacht wieder hängen geblieben, obwohl er den kompletten Datenbestand selber kopieren musste.

Also gehe ich jetzt mal davon aus, dass die Ursache in der Quelle (SERVER A) zu suchen ist, obwohl der Dienst auf Server B & C stirbt.

 

Ich sterb auch bald...

[Doso 77]

Wir hatten auf 2012R2 Servern nach Aktivierung von DFS-Namepsaces das problem das wir in einen Memory Leak gelaufen sind, Workaround:

 

https://blogs.technet.microsoft.com/core/2015/06/26/memory-leak-verursacht-von-dem-remote-registry-dienst-unter-windows-8-8-1-und-server-2012-2012r2/

 

Evtl. einen Versuch Wert. Bei der Suche dazu habe ich auch Fehler zum DFS in anderen Serverversionen gefunden. Evtl. läufst du da in einen Bug der irgendwo schon bekannt ist und dafür gibt es einen Patch/Hotfix/Workaround irgendwo.

[Doso 77]

Vermutlch läufts du gerade in diesen Bug rein:

https://www.reddit.com/r/sysadmin/comments/4oe5bv/dfsr_headaches_uninstall_kb3156418/

[AndreP 0]

Hallo Doso,

 

VIELEN DANK!!!!

 

Genau das ist der Fehler.

Das Update deinstalliert, Replikationsgruppen neu eingerichtet und siehe da, er läuft durch.

 

Hier der Vollständigkeit halber noch der Link zur MS Doku des KB3156418, in dem Microsoft das Problem mit dem DFSR Dienst auch nennt:

https://support.microsoft.com/en-us/kb/3156418

 

Noch mal vielen Dank für die Hilfe!

Problem ist damit gelöst.

 

Gruß

Andre P.

bearbeitet 21. Juni 2016 von AndreP