45455
May 30, 2016
3391
6
0
DFSR-Dienst lässt sich nicht neustarten
Hallo,
ich habe etwas Probleme mit einer ursprünglich problemlos funktionierenden DFS-R Konfiguration.
Und zwar hängt sich der DFS-R-Dienst auf dem entfernten Mitglied in der Form auf, dass er zunehmend weniger Performance zeigt und ständig Abbrüche der DFS-R-Verbindung protokolliert (Event 5014), aber ohne besondere CPU- oder RAM-Last. Dadurch laufen die Replikationsmitglieder auseinander.
In diesem Zustand lässt sich der Dienst auch nicht mehr neu starten, sondern nur noch abbrechen, was dann natürlich immer eine Prüfung der Datenbank nach sich zieht.
Danach läuft das wieder ne Weile.
Die DFSRS.exe ist allerdings wohl auf dem neuesten Stand 06.04.16
Konstellation:
DFS in 2008-R2-Domäne, Member1: Storage als Einzelserver mit 2012, Member 2: (entfernte) Storage als RDC in Filiale, Verbindung über VPN mit 10 MBit/s.
Was kann den noch stören?
Gruß
Kai
ich habe etwas Probleme mit einer ursprünglich problemlos funktionierenden DFS-R Konfiguration.
Und zwar hängt sich der DFS-R-Dienst auf dem entfernten Mitglied in der Form auf, dass er zunehmend weniger Performance zeigt und ständig Abbrüche der DFS-R-Verbindung protokolliert (Event 5014), aber ohne besondere CPU- oder RAM-Last. Dadurch laufen die Replikationsmitglieder auseinander.
In diesem Zustand lässt sich der Dienst auch nicht mehr neu starten, sondern nur noch abbrechen, was dann natürlich immer eine Prüfung der Datenbank nach sich zieht.
Danach läuft das wieder ne Weile.
Die DFSRS.exe ist allerdings wohl auf dem neuesten Stand 06.04.16
Konstellation:
DFS in 2008-R2-Domäne, Member1: Storage als Einzelserver mit 2012, Member 2: (entfernte) Storage als RDC in Filiale, Verbindung über VPN mit 10 MBit/s.
Was kann den noch stören?
Gruß
Kai
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: 305701
Url: https://administrator.de/contentid/305701
Printed on: April 20, 2024 at 16:04 o'clock
6 Comments
Latest comment
Hallo,
Tritt der Fehler denn zu bestimmten Zeiten auf oder in bestimmten Abständen?
Eventuel TCP Verbindungs-Timeout, wegen VPN Einstellung.
Oder ein Backupprozess des DFS welches die Kommunikation stört.
Es aknn auch am eingeschalteten "TCP Offload" liegen.
Gruß c
Tritt der Fehler denn zu bestimmten Zeiten auf oder in bestimmten Abständen?
Eventuel TCP Verbindungs-Timeout, wegen VPN Einstellung.
Oder ein Backupprozess des DFS welches die Kommunikation stört.
Es aknn auch am eingeschalteten "TCP Offload" liegen.
Gruß c
Hi,
ich tippe zu 99% auf eine temporär ausgelastete oder gestörte WAN-Verbindung. Sowas hatten wir auch schon. Wir haben dann die Leitungen vom Provider beobachten lassen und dabei hat sich herausgestellt, dass diese mehrmals täglich am Anschlag waren.
In so einem Fall:
Entweder die Leitungen vergrößeren oder die max. Replikations-Bandbreite in der DFS-R-Gruppe reduzieren.
E.
ich tippe zu 99% auf eine temporär ausgelastete oder gestörte WAN-Verbindung. Sowas hatten wir auch schon. Wir haben dann die Leitungen vom Provider beobachten lassen und dabei hat sich herausgestellt, dass diese mehrmals täglich am Anschlag waren.
In so einem Fall:
Entweder die Leitungen vergrößeren oder die max. Replikations-Bandbreite in der DFS-R-Gruppe reduzieren.
E.
An den Netzwerkeinstellungen wurde nichts verändert und die Replikation läuft damit schon ein Jahr.
Der Fehler schaukelt sich wie gesagt immer wieder nach etwas Laufzeit des Dienstes auf (ca. 1-2 Tage)
Der Fehler schaukelt sich wie gesagt immer wieder nach etwas Laufzeit des Dienstes auf (ca. 1-2 Tage)
An den Netzwerkeinstellungen wurde nichts verändert und die Replikation läuft damit schon ein Jahr.
Bei uns damals auch nicht.Was geht denn sonst noch alles über diese Leitung?
Der Fehler schaukelt sich wie gesagt immer wieder nach etwas Laufzeit des Dienstes auf (ca. 1-2 Tage)
Ja. Jede Korrektur-Übertragung verschlimmert "die Welle" noch. Irgendwann ist der "Wellenberg" höher als die verfügbare Bandbreite.Ist der Staging-Bereich groß genug?
Die Replikationsbandbreite ist tagsüber bereits reduziert, damit die Leitung nicht völlig zu geht. Dennoch tritt auch dann der Fehler auf.
Ich befürchte eigentlich eher, dass die Datenbank beschädigt ist, was normalerweise beim Neustart behoben werden sollte, aber aus irgendeinem Grund (der nirgends protokolliert ist) anscheinend nicht wird.
Im Datenbankverzeichnis findet sich auch eine Datei $db_dirty$, die aber schon älter ist (02/2016)
Funktioniert die Prüfung/Reparatur mit Eseutil auch unter 2012 R2 noch?
Ein Neuaufbau wäre unschön, da der sehr lange dauert.
Ich befürchte eigentlich eher, dass die Datenbank beschädigt ist, was normalerweise beim Neustart behoben werden sollte, aber aus irgendeinem Grund (der nirgends protokolliert ist) anscheinend nicht wird.
Im Datenbankverzeichnis findet sich auch eine Datei $db_dirty$, die aber schon älter ist (02/2016)
Funktioniert die Prüfung/Reparatur mit Eseutil auch unter 2012 R2 noch?
Ein Neuaufbau wäre unschön, da der sehr lange dauert.
Staging ist ausreichend. Leerungseinträge sind aktuell keine zu finden.
Über die Leitung gehen interne Telefongespräche und in sehr geringem Umfang Dateizugriffe (Lizenzserver)
Über die Leitung gehen interne Telefongespräche und in sehr geringem Umfang Dateizugriffe (Lizenzserver)
