Frage: Gibt es eine Möglichkeit, diesen 350.000-Dateien-Rückstand schneller zu vervollständigen? Für fast jede Datei war die einzige Änderung eine Änderung der ACL für jede betroffene Datei. Einige Dateien haben den Inhalt geändert, dies ist jedoch in dieser Situation nicht der Fall.
Dies könnte behoben sein. Ich werde diesen Text bearbeiten, um Erfolg / Misserfolg nach einer gewissen Zeit und Überprüfung zu bestätigen. Gegen Ende dieses Fragetextes habe ich die kürzlich vorgenommenen Änderungen detailliert beschrieben, die dies möglicherweise behoben haben.
Wir haben eine DFSR-Replikationsgruppe mit ca. 450.000 Dateien und belegen 1,5 TB Speicherplatz. In dieser Situation gibt es zwei Windows Server 2008 R2-Server, die ungefähr 500 Meilen voneinander entfernt sind. Es gibt andere Server, die jedoch nicht an dieser Replikationsgruppe beteiligt sind. Server ALPHA ist der Hauptserver und wird von den meisten Mitarbeitern verwendet. Server BETA ist der Server im Remote-Büro und ist weniger ausgelastet.
Hier ist ein Diagramm des Rückstands für diese Replikationsgruppe (PNG, das auf Google Drive gehostet wird), das den langsamen Synchronisierungsfortschritt zeigt.
Ich musste einen Berechtigungseintrag entfernen, der sich im Stammverzeichnis dieser Replikationsgruppe befand, der natürlich von den meisten Unterordnern geerbt wurde. Ich habe diese Änderung auf dem Server ALPHA vorgenommen. Unmittelbar danach hatte DFSR einen Dateirückstand von 350.000. Es ist mehr als eine Woche her und jetzt sind es 267.000. Das einzige, was sich (anfangs) geändert hat, war die Änderung der Einzelberechtigung.
Dies ist passiert (dies ist nicht die Lösung, nur eine weitere Erklärung dessen, was dieses Problem verursacht hat): http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -wenn-es-sich-herausstellt-Freitag-Nacht-war-in-Ordnung-für-Kampf.aspx # dfsr
Alle Änderungen, die auf Server BETA auftreten, werden sehr schnell auf Server ALPHA repliziert, da in dieser Richtung kein Rückstand besteht. Alle auf BETA geänderten Dateien gelangen problemlos zu ALPHA.
Es wird rund um die Uhr mit voller Geschwindigkeit über eine 50-Mbit / s-Verbindung an einem Ende auf eine Glasfaser mit 100 Mbit / s am anderen Ende repliziert. Der Staging-Bereich beträgt auf jedem Server 100 GB. In den Ereignisprotokollen ist überhaupt nichts Interessantes. Es gibt ein nicht verwandtes Ereignis mit hohem Wasserzeichen, das für eine nicht verwandte Replikationsgruppe angezeigt wird, die weder für diese bestimmte Replikation noch für dieses ALPHA / BETA-Serverpaar gilt. Insbesondere gibt es keine Ereignisprotokolleinträge für hohe Wasserzeichen oder für Verbindungsfehler.
ALPHAs Ansicht der Replikationsgruppe:
Bandbreiteneinsparungen : Reduzierung um 99,83% (30,85 MB repliziert statt 18,1 GB)
Ich glaube, dass die 30,85 MB / 18,1 GB seit dem letzten Neustart des DFSR-Dienstes auf ALPHA und BETA aufgetreten sind. Wenn ja, zeigt dies, dass es, obwohl es sehr lange dauert (länger als ich glaube, dass es dauern sollte), den Dateiinhalt nicht tatsächlich über das Kabel überträgt.
Replizierter Ordner : 1,46 TB (tatsächliche Größe), 439.387 (Dateien), 52.886 (Ordner)
Konflikt- und gelöschter Ordner : 100,00 GB (konfigurierte Größe), 34,01 GB (tatsächliche Größe), 19.620 (Dateien), 2.393 (Ordner)
Staging-Ordner : 200,00 GB (konfigurierte Größe), 92,54 GB (tatsächliche Größe)
Ich habe einen Fehler mit hohem Wasserzeichen in den Protokollen (14. Mai, 19 Uhr) und habe daher die Staging-Quote von 100 GB auf 200 GB erhöht. Ich weiß, dass die von Microsoft genehmigte Route um 20% erhöht werden soll, aber ich spiele nicht damit herum. Wir haben viel Speicherplatz auf den Staging-Festplatten-Arrays.
Das Deaktivieren des Antivirenprogramms auf allen Servern hat nicht geholfen, obwohl ich dachte, es hätte ein bisschen geholfen. Im Moment habe ich Antivirus wieder aktiviert, aber den Pfad der Replikationsgruppe so festgelegt, dass er vom Scannen ausgeschlossen wird, um diese Variable aus der Gleichung zu entfernen.
Gibt es eine Möglichkeit, dies schneller zu machen? Ich würde diese Änderung nur auch auf Server-BETA vornehmen, aber es gibt Dateien, die sich auf ALPHA geändert haben, aber nicht auf BETA repliziert wurden, und durch die Änderung der geerbten Berechtigung auf BETA würden ALTE Dateien von BETA auf ALPHA übertragen (weil DFSR dies zu tun scheint) Ignorieren Sie die Zeitstempel der Datei, wenn Sie vergleichen, welche Datei bei einer Kollision der Gewinner ist. Und das zu haben wäre ziemlich schlimm.
Der Rückstand nimmt langsam ab. Sehr, sehr langsam. Es geht aber weiter. Aber bei dieser Geschwindigkeit wird es Wochen dauern, bis es fertig ist. Ich denke darüber nach, nur eine Kopie des Datensatzes auf ein 3-TB-Laufwerk zu schieben und an das Remote-Büro zu senden. Gibt es einen besseren Weg?
16. Mai, 4 Uhr morgens US PT: Was könnte das Problem behoben haben (vorausgesetzt, es ist sowieso ehrlich behoben):
Ich habe mehrere Änderungen an den DCs vorgenommen, die vor langer Zeit hätten vorgenommen werden sollen. Das Problem ist, dass dieses Netzwerk von jemand anderem geerbt wurde, der es wahrscheinlich von jemand anderem geerbt hat usw. Ich kann nicht versprechen, welche Änderung das Problem behoben hat. Hier sind sie in keiner bestimmten Reihenfolge:
- Alle Domänencontroller befanden sich nicht in der Organisationseinheit "Domänencontroller". Ich habe noch nie eine Windows-Domäne gesehen, deren Domänencontroller anderswo waren. Ich brachte sie dorthin zurück, wo sie hingehörten. Sie befanden sich zuvor in Organisationseinheiten, die nach dem Namen der Stadt getrennt waren, in der sich jedes Büro befindet. (Ich habe das Gefühl, dass ich jetzt, da ich diese umgezogen habe, einige Klempnerarbeiten erledigen muss, aber derzeit scheint alles in Ordnung zu sein ...)
- AVG Anti-Virus wird auf allen DCs und DFSR-teilnehmenden Servern ausgeführt. Ich habe die replizierten Ordner und die Staging-Ordner vom aktiven / On-Access-Scannen ausgeschlossen. Ich glaube nicht, dass dies das Problem behoben hat, und ich werde dieses Problem wahrscheinlich später testen, um festzustellen, ob das Rückgängigmachen dieser Änderung die Replikationsgeschwindigkeit von DFSR beeinträchtigt. Das ist eine Herausforderung für einen anderen Tag.
- dcdiag.exe hat ein DNS-Problem in Bezug auf RODCs beanstandet. Ich habe dieses Problem behoben, obwohl wir überhaupt keine RODCs in der Domain haben. Ich bezweifle, dass dies irgendetwas behoben hat.
- Einer der SRV-Datensätze _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET fehlte für einen der Domänencontroller (nicht für einen der DFSR-Server), und ich habe Abhilfe geschaffen. Ich glaube auch nicht, dass das geholfen hat.
- Bei einem Neustart von Server BETA wurde ein fehlerhaftes Herunterfahren der DFSR-Datenbank (Ereignis 2212) beanstandet, und es dauerte Stunden, bis die Datenbank neu erstellt wurde. Als es fertig war, meldete es Ereignis 2214, um mich wissen zu lassen, dass es fertig war. Danach lief die Replikation immer noch extrem langsam, aber es hätte möglicherweise geholfen, alles zu lösen, was feststeckte.
- Einer der Domänencontroller hatte in seiner Schnittstellenkonfiguration nicht 127.0.0.1 als sekundären DNS-Server. Ich habe es hinzugefügt. Dies war keiner der DFSR-Server, so dass dies wahrscheinlich nichts damit zu tun hatte.
- Ich folgte dem TechNet-Blog: Optimieren der Replikationsleistung in den von DFSR empfohlenen Registrierungseinstellungen für DFSR-Server. Ich habe alle Werte für den "getesteten Hochleistungswert" verwendet, außer dass AsyncIoMaxBufferSizeBytes auf 4194304 festgelegt wurde, was eine Stufe niedriger als der Hochwert ist. Dies hätte bei dem Problem helfen können ... oder vielleicht auch nicht. Es ist schwer zu sagen, wann man zu viele Variablen ändert.
- dcdiag.exe hat sich über ein Problem bei der Kommunikation mit dem RPC-Dienst auf BETA beschwert, jedoch erst, nachdem die oben genannten Änderungen bereits vorgenommen wurden. Dies schien das wahrscheinlichste Problem zu sein, aber ich habe nichts getan, um es zu korrigieren. Das VPN lief ordnungsgemäß und die Firewall blockierte es nicht. Es ist möglich, dass einer der oben genannten Punkte das RPC-Problem verursacht und dann behoben hat, oder es könnte ein einfacher Zufall gewesen sein. Ich bin nicht diesen Fehler jetzt immer und Replikation läuft reibungslos derzeit.
Die Moral der Geschichte lautet: Ändere eine Sache nach der anderen oder du wirst nie wirklich wissen, was sie behoben hat. Aber ich war verzweifelt und hatte keine Zeit mehr, um das Problem zu beheben. Deshalb habe ich nur ein paar Kugeln auf das Problem abgefeuert. Wenn ich jemals den Fix finde, werde ich das hier melden. Verlassen Sie sich jedoch nicht darauf, dass ich es einschränke.
EDIT 21.05.2012: Ich habe dieses Problem gelöst, indem ich gestern etwa sieben Stunden mit einem Ersatzserver (GAMMA) zum Remote-Büro gefahren bin. GAMMA fungiert jetzt als primärer lokaler Server, während der übliche Server (BETA) die Replikation aufholt. Seit ich es eingerichtet habe, haben die Server die Replikationsgeschwindigkeit verdoppelt. Dies sagt mir zwar, dass es sich um ein VPN-Problem handeln könnte, aber ich bin weniger geneigt zu glauben, dass dies der Fall ist, da alle neuen Updates von ALPHA auf GAMMA repliziert wurden und sehr schnell und gut verlaufen sind.
EDIT 22.05.2012: Es ist gerade bei 12000 und sollte in ein paar Stunden fertig sein. Ich werde eine schöne Grafik des Fortschritts vom langsamen Start bis zum schnellen Ende veröffentlichen. Das Problem ist, dass das einzige, was wirklich "behoben" wurde, die lokale Serververbindung ist. Ich denke derzeit, dass vielleicht das VPN Teil des Problems ist. Und wenn das der Fall ist, habe ich das Gefühl, dass diese Frage noch nicht ganz beantwortet ist. Nachdem ich mehr Zeit hatte, um zu überprüfen, wie sich die Dinge über das VPN replizieren und ob Fehler auftreten, werde ich den Fortschritt debuggen und melden.
Wenn sich etwas ändert, werde ich hier aktualisieren.
dfsrdiag replicationstate /azeigt, dass nur zwei Dateien gesendet werden, beide jedoch denselben Dateinamen haben. Es heißt, dass es ohnehin zwei ausgehende Verbindungen zu BETA von ALPHA gibt. Die Datei, die gesendet wird, ist 850 MB groß. Wie zuvor beschrieben, bin ich davon überzeugt , nicht , dass es tatsächlich sendet den gesamte Dateiinhalt, obwohl ich nicht sicher bin , was wäre es , wenn nicht tun , da es eine sehr lange Zeit in Anspruch nimmt mit einer einzigen Datei nur zu beschäftigen. Die Datei wurde zuletzt im Jahr 2008 (auf beiden Servern) aktualisiert, sodass es keinen Grund gibt, etwas anderes zu tun, als die ACL-Informationen für die Datei auf BETA zu aktualisieren.