DFS Replikation Verbindungsabbrüche

[danieldd 12]

Hallo,

 

wir verwenden DFSR für die Replikation von einzelnen Verzeichnissen zwischen mehreren Standorten weltweit.

 

Bei einer Replication Group erscheinen im Sekundentakt auf beiden Servern (Sender und Empfänger) folgende Meldungen im DFS Log:

 

+ [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 4732 C A failure was reported by the remote partner]

+ [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 4732 C The content set is not ready]

20120913 09:45:25.809 4732 INCO 7487 InConnection::RestartSession Retrying establish contentset session. connId:{B6236B02-9C73-41A8-B799-37F455E58D45} csId:{46BEA95B-B66B-403C-9E8D-D78F06D02235} csName:xxx

20120913 09:45:25.809 4732 INCO 1042 [WARN] SessionTask::Step (Ignored) Failed, should have already been processed. Error:

+ [Error:9027(0x2343) InConnection::EstablishSession inconnection.cpp:6172 4732 C A failure was reported by the remote partner]

+ [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4200 4732 C A failure was reported by the remote partner]

+ [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 4732 C A failure was reported by the remote partner]

+ [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 4732 C The content set is not ready]

 

 

Die Replikation bleibt dann hängen, d.h. es wird unendlich viel Traffic verursacht, aber die Files kommen nie am Ziel an.

 

Sender: Win 2k3 R2

Empfänger: Win 2k8

 

Alle möglichen Hotfixes wurden bereits installiert.

 

Hat hierzu jemand eine Idee wodurch oben stehende Meldungen verursacht werden können?

 

Danke im Voraus

 

grüsse

daniel

[olc 18]

Hi Daniel,

 

welchen Virenscanner setzt Du ein? Supported dieser DFSR laut Hersteller explizit?

Testweises deinstallieren (!) des Scanners auf beiden Seiten möglich?

 

Viele Grüße

olc

[danieldd 12]

Hi olc,

 

danke für die Rückmeldung.

Aktuell verwenden wir Avira Server Security 12.

Wir haben mehrere Replikations-Gruppen, das Problem tritt aber nur bei einer Gruppe auf, wo größere Files (> 4 GB) übertragen werden sollten.

Bei Avira online findet sich keine offizielle Freigabe für DFSR, ich habe Avira bereits diesbezüglich beim Support nachgefragt und warte aktuell auf Rückmeldung.

 

Aber ich werde die Replikation testweise ohne AntiVir laufen lassen.

Danke für den Tipp.

 

grüsse

daniel

[LarryLaffer 10]

Hi,

 

Hast du auch die Staging Area entsprechend groß dimensioniert? Mal RDC ausgeschalten?

Geht die Replikation nur in eine Richtung nicht im Fehlerfall oder geht's in beide nicht?

 

Grüße, Larry

[danieldd 12]

Hi,

 

die Staging Quotas sind ausreichend groß und werden während der Replikation auch nicht vollständig genutzt.

Die Deinstallation des Virenscanners zeigte keine Änderung.

Auch RDC wurde für diese Verbindung deaktiviert, aber die Meldungen (siehe oben) tauchen trotzdem auf.

Auch die maximal nutzbare Bandbreite wurde bereits auf 2 MBit/s heruntergestuft, um ein Problem durch unterschiedliche WAN Anbindungen ausschließen zu können.

 

Aktuell sollte eine Initial Replikation vom Primary Member zu einem Außenstandort stattfinden.

 

Auch bei Verwendung eines anderen Gruppentyps (Multipurpose und Data Collection) ändert sich nicht.

 

Gibts noch irgend welche Einstellungen, was die Verbindungsabbrüche auslösen kann?

 

grüsse

daniel

[LarryLaffer 10]

+ [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 4732 C The content set is not ready]

 

Das bedeutet, dass der Initial Sync noch nicht abgeschlossen ist.

Wie groß sind die Daten insgesamt, welche du in dem Replicated Folder hast?

Hast du ein prestaging betrieben?

 

Kannst du mal den DFS-R Dienst stoppen, 5 min warten, die Debuglogs wegkopieren, Dienst wieder starten, 15 min warten, neue Debug Logs hier posten?

 

Sorry vergessen: Mach als aller erstes noch das:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set debuglogseverity=5

[olc 18]

Hi,

 

+ [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 4732 C The content set is not ready]

Das bedeutet, dass der Initial Sync noch nicht abgeschlossen ist.

 

Ja, wurde ja auch vom TO angegeben :) ... :

 

Aktuell sollte eine Initial Replikation vom Primary Member zu einem Außenstandort stattfinden.

 

Neben den Hinweisen von LarryLaffler:

 

Auch bei Verwendung eines anderen Gruppentyps (Multipurpose und Data Collection) ändert sich nicht.

 

• Wie lange wartest Du nach Anpassung der Struktur oder DFSR-Dienst Neustart?
  
• Wie viele Systeme sind Teil der Replikationsgruppe? Wie stabil sind die WAN-Leitungen?
  
• Sind Anpassungen unterhalb von HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters auf den Systemen durchgeführt worden?
  
• Werden "WAN-Optimierer" (etwa von Riverbed) auf den Strecken eingesetzt?
  

 

Viele Grüße

olc

[danieldd 12]

Hi,

 

anbei die Logfiles (nur von 5 Minuten aufgrund der Größe).

 

• 
  Insgesamt wären ca. 10 GB zu replizieren, wobei 3 Files eine Größe von jeweils 3 GB haben.
  Prestaging wurde in diesem Falle nicht betrieben.
  

 

• 
  Wenn ich eine Änderung in der Struktur oder oder den Replikationsgruppen vornehme, so warte ich, bis die Änderung zum Replikationspartner mittels AD / NTDS Replikation übertragen wird.
  

 

• 
  Aktuell sind in der Replikationsgruppe welche die Probleme bereitet zwei Server eingebunden (in einer Multipurpose Gruppe).
  Die WAN Verbindungen sind relativ stabil, d. h. wir haben keinerlei Problem bei anderen Replikationen oder sonstigen Übertragungen.
  

 

• 
  In der Registry wurde bisher auf keinem der beiden Server eine Änderung in den Tcpip Parametern vorgenommen.
  

 

• 
  WAN Optimierer sind nicht im Einsatz.
  

 

Danke für die Unterstützung.

 

grüsse

daniel

Dfsr00253.txt

Dfsr00253_02.txt

Dfsr00253_03.txt

[danieldd 12]

Update:

Seit dem Ändern des Loglevels sind jetzt folgende Meldungen vorhanden:

 

+ [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C A failure was reported by the remote partner]

+ [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C The content set is not ready]

20120920 17:18:01.706 6460 INCO 2813 InConnection::ProcessErrorStatus Restarting session on error. connId:{35DB2F3C-3EB4-4C91-B0E7-4EEBE5D90C70} csId:{50F27B17-4CA7-47EA-B0CE-A63DB9953904} state:CONNECTED Error:

+ [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4200 6460 C A failure was reported by the remote partner]

+ [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C A failure was reported by the remote partner]

+ [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C The content set is not ready]

20120920 17:18:01.706 6460 INCO 7487 InConnection::RestartSession Retrying establish contentset session. connId:{35DB2F3C-3EB4-4C91-B0E7-4EEBE5D90C70} csId:{50F27B17-4CA7-47EA-B0CE-A63DB9953904} csName:Boot

20120920 17:18:01.706 6460 INCO 1042 [WARN] SessionTask::Step (Ignored) Failed, should have already been processed. Error:

+ [Error:9027(0x2343) InConnection::EstablishSession inconnection.cpp:6172 6460 C A failure was reported by the remote partner]

+ [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4200 6460 C A failure was reported by the remote partner]

+ [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C A failure was reported by the remote partner]

+ [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C The content set is not ready]

20120920 17:18:01.706 6460 TASK 756 Task::Schedule task:000000000B362370 oldState:RUNNING newState:RUNSLEEP timeout:120000 NEW_SESSION

 

Die letzte Zeile mit "oldState:RUNNING newState:RUNSLEEP timeout:120000 NEW_SESSION" hab ich zuvor nie gesehen.

 

Habe die Replikation eines 4 GB Files auch mittlerweile in die umgekehrte Richtung dieser beiden Server getestet.

Es scheint aber das gleiche Problem aufzutreten, d. h. es liegt nicht an einer bestimmten Richtung von einem Server zu dem zweiten.

 

grüsse

daniel

[olc 18]

Hi,

 

das Problem kann auch nach Log-Lage aus meiner Sicht aus vielerlei Gründen auftreten.

Mir scheint, daß bis zum aktuellen Status eine Menge Aktionen erfolgt sind, die das Fehlerbild verwässern können.

 

Kurz Rückmeldung zu Deinen Anmerkungen:

a) RDC zu deaktivieren ist nicht sinnvoll.

b) die AD-Replikation reicht leider nicht aus - der DFSR Dienst muß die Änderungen auch erst aus der AD abrufen. Das erfolgt standardmäßig jede Stunde 1x. Beschleunigen kannst Du das mittels "dfsrdiag pollad" auf den Zielmaschinen.

c) Du schriebst, daß Du alle möglichen Hotfixes schon installiert hast - welche genau?

d) Wie ist der Status von SNP auf dem 2003er Server? Sind die SNP Features deaktiviert oder alternativ auf dem neuesten Stand? A Scalable Networking Pack (SNP) hotfix rollup package is available for Windows Server 2003

e) Kannst Du ggf. das Quota einmal auf 20 GB hochdrehen und die Replikationsgruppe neu einrichten? Datensicherung nicht vergessen und richtigen Primary Member wählen. ;)

f) Dabei bitte keine Bandbreiteneinschränkung konfigurieren wie oben beschrieben, das macht es nicht besser.

g) Nach der Einrichtung der Replication Group das System einmal 24h "in Ruhe" lassen - keine Änderungen an der Konfiguration, kein Neustart der DFSR Dienste usw.

 

BTW: Hardware oder virtuelle Maschinen?

 

Viele Grüße

olc

[danieldd 12]

Hi,

danke für die Rückmeldung

 

a) RDC ist im Normalfall aktiviert, nur testweise hab ich es deaktiviert -> keine Änderung

b) Danke für die Info - wenn es stündlich passiert sollte es daran auch nicht liegen

c)

2462352/424078 -- DFSR fails from a computer that is running Windows Server 2008 R2 to a computer that is running Windows Server 2003 R2

953325 -- A Windows Server 2003- or 2008-based computer becomes unresponsive because the paged pool memory is exhausted when an application calls the GetFileAttributesEx and MoveFileEx functions on lots of files

948496 -- Disable SNP (Scalable Networking Pack)

953325 -- A Windows Server 2003- or 2008-based computer becomes unresponsive because the paged pool memory is exhausted when an application calls the GetFileAttributesEx and MoveFileEx functions on lots of files

 

d) SNP ist laut Registry auf dem 2003er deaktiviert - hab die Replikation aber testweise auch mit einem Win 2k8 R2 getestet, es zeigt sich aber das gleiche Verhalten

 

e) Die Quota hab ich bereits auf 25 GB

 

Beide Systeme ist eine physische Hardware, keine virtuelle Umgebung.

 

Ich werde heute die Replikationsgruppe nochmal komplett löschen, alle Daten bereinigen und nächste Woche nochmal alles neu erstellen

 

Gibt es evtl. weitere Debugging Tools oder ähnliches? Welches vielleicht weitere Meldungen ausgeben würde?

 

Danke und ein schönes WE

 

grüsse

daniel

[danieldd 12]

Hi,

 

kurzes Update zu den in der Zwischenzeit vorgenommenen Änderungen.

• 
  Der TCP Chimney-Abladestatus wurde auf allen Replikationspartner deaktiviert

• "Large Send Offload" in der NIC Konfiguration ebenfalls deaktiviert
  

• Änderungen in der Registry vorgenommen: DFSR RPC replication errors 5014 1726 with large files over VPN
  

 

 

Die Eventlogs 5014 tauchen aber weiterhin auf:

 

Protokollname: DFS Replication

Quelle: DFSR

Datum: 01.10.2012 09:31:24

Ereignis-ID: 5014

Aufgabenkategorie:Keine

Ebene: Warnung

Schlüsselwörter:Klassisch

Benutzer: Nicht zutreffend

Computer: gerätename.domänenname.local

Beschreibung:

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

 

Weitere Informationen:

Fehler: 1726 (The remote procedure call failed.)

Verbindungs-ID: EE7BEFE0-4C39-4F7B-8778-C3D008EDAE36

Replikationsgruppen-ID: 8F1BFD12-DA84-4225-A7DB-679A2D652812

 

Auch die Timeouts im DFS Log:

20121001 09:36:40.674 1984 TASK 756 Task::Schedule task:000000000BE1A640 oldState:RUNNING newState:RUNSLEEP timeout:20000 NEW_SESSION

 

 

Die Replikationsgruppe wurde komplett neu erstellt mit 25GB Staging Quota und ausreichend Zeitverzögerung, damit sich die Änderungen automatisch in der Domäne abgleichen können.

 

Wodurch könnten die permanenten Timeouts und Verbindungsabbrüche noch verursacht werden?

Welche Änderungen könnte man noch vornehmen?

 

danke

 

grüsse

daniel

[olc 18]

Hi Daniel,

 

mit TCP Chimney deaktivieren meinst Du alle drei Werte, korrekt?

EnableTCPChimney

EnableTCPA

EnableRSS

 

Was sagt der folgende Wert?

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters --> DisableTaskOffload. Enthält er den Wert "1"?

 

Beide Maschinen nach den TCP-Änderungen neu gestartet? Im Regelfall ist das übrigens eher nur für 2003 relevant, unter 2008 läuft das Offloading stabiler.

 

Du hattest bei den Tests ganz oben Avira wirklich auf beiden Systemen testweise deinstalliert, korrekt? Nicht nur deaktiviert?

 

Ist auf den Systemen irgend eine Art von NIC-Teaming aktiv?

 

Ggf. könntest Du noch einen Netzwerktrace mitlaufen lassen um zu prüfen, von welchem System ggf. TCP Resets kommen oder ob es wirklich einfach "Verbindungsabbrüche" sind.

 

P.S.: Nimm einmal die firmen-spezifischen Daten aus den Exports oben raus. :)

 

Viele Grüße

olc

[danieldd 12]

Hi olc,

 

ich hab die Replikation mittlerweile im LAN getestet, um das WAN als Verursacher ausschließen zu können.

 

Ergebnis: Im LAN läuft die Replikation und alle Verbindungsabbrüche sind weg, alle Files werden korrekt repliziert.

 

Grund für die Probleme sind also scheinbar doch die langsamen WAN Verbindungen (aktuell zwischen 3 und 10 MBit/s).

 

Der nächste Schritt wäre also irgendwie in Richtung WAN Optimierung zu gehen.

 

Gibt es irgendwo in DFS eine Einstellung zur Erhöhung von Timeouts oder sonstiges bei langsamen Verbindungen?

Hat jemand hilfreiche Tipps bzgl. WAN Optimierung?

 

Danke im Voraus

 

grüsse

daniel

bearbeitet 11. Oktober 2012 von danieldd