[Anmerkung Übersetzer. Der Artikel ist für Windows Server 2003 / 2003R2 / 2008 / 2008R2, aber die meisten der oben genannten Punkte gelten für spätere Versionen des Betriebssystems.]Warren ist wieder da. Dieser Artikel ist eine Kurzanleitung zur korrekten Berechnung der Mindestgröße des Staging-Ordners, die erforderlich ist, damit DFSR ordnungsgemäß funktioniert. Das Festlegen niedrigerer Werte kann die Replikation verlangsamen oder sogar stoppen. Beachten Sie, dass dies nur die
Mindestwerte sind . Beachten Sie bei der Auswahl der Größe eines Zwischenordners Folgendes: Je größer der Zwischenordner ist, desto besser bis zur Größe des replizierten Ordners. Weitere Informationen darüber, wie wichtig es ist, die richtige Größe des Staging-Ordners zu verwenden, finden Sie im Abschnitt „Feststellen, ob Sie ein Problem mit dem Staging-Ordner haben“ und in den Blog-Posts, die am Ende dieses Artikels verlinkt sind.
Update: Warren weiß wirklich zu überzeugen! Jetzt gibt es einen Fix, mit dem Sie die Größe des Staging-Ordners berechnen können.
https://support.microsoft.com/kb/2607047Faustregeln
Windows Server 2003 R2 - Das Kontingent für Staging-Ordner sollte der Gesamtgröße der 9 größten Dateien im replizierten Ordner entsprechen.
Windows Server 2008 und 2008 R2 - Das Kontingent für Staging-Ordner muss der Gesamtgröße der 32 größten Dateien im replizierten Ordner entsprechen
[Hinweis Übersetzer. Diese Nummer gilt auch für Windows Server 2012 / 2012R2]Die primäre Replikation belegt viel mehr Speicherplatz im Staging-Ordner als die normale tägliche Replikation. Wenn die Größe des Speicherplatzes dies zulässt, wird dringend empfohlen, vor dem Starten der primären Replikation eine Größe festzulegen, die über dem erforderlichen Minimum liegt.
Woher bekomme ich PowerShell?
PowerShell ist in Windows 2008 und höher enthalten. Es muss unter Windows Server 2003 installiert werden. Laden Sie PowerShell für Windows 2003
hier herunter.
Wie finde ich diese größten Dateien?
Verwenden Sie ein PowerShell-Skript, um die 32 oder 9 größten Dateien zu finden und zu bestimmen, wie viele Gigabyte sie belegen (dank Ned Pyle für PowerShell-Befehle). Ich möchte Ihnen drei PowerShell-Skripte vorstellen. Jeder von ihnen ist auf seine Weise nützlich, der dritte ist jedoch der nützlichste.
- Ausführen:
Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | ft name,length -wrap -auto
Dieser Befehl gibt Dateinamen und deren Größe in Bytes zurück. Es ist hilfreich herauszufinden, welche 32 Dateien die größten im replizierten Ordner sind, und ihre Besitzer zu besuchen.
- Ausführen:
Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | measure-object -property length –sum
Dieser Befehl gibt die Gesamtzahl der Bytes für die 32 größten Dateien in einem Ordner zurück, ohne deren Namen anzugeben.
- Ausführen:
$big32 = Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | measure-object -property length –sum $big32.sum /1gb
Dieser Befehl ermittelt die Gesamtzahl der Bytes für die 32 größten Dateien in einem Ordner und konvertiert sie mithilfe mathematischer Berechnungen in Gigabyte. Dieser Befehl besteht aus zwei separaten Zeilen. Sie können sie sofort in die PowerShell-Befehlsshell einfügen oder nacheinander ausführen.
Manuelle Analyse
Um den Prozess zu demonstrieren und wenn möglich unser Verständnis für das, was wir tun, zu vertiefen, werden wir jede Operation durchgehen und manuell ausführen.
Der erste ausgeführte Befehl gibt ähnliche Ergebnisse wie die unten gezeigten zurück. Der Kürze halber werden in diesem Beispiel nur 16 Dateien verwendet. Berücksichtigen Sie immer 32 Dateien für Windows 2008 und spätere Betriebssysteme und 9 für Windows 2003 R2.
Von PowerShell zurückgegebene Beispieldaten:
| Name | Länge |
|---|
| File5.zip | 10286089216 |
| archive.zip | 6029853696 |
| BACKUP.zip | 5751522304 |
| file9.zip | 5472683008 |
| MENTOS.zip | 5241586688 |
| File7.zip | 4321264640 |
| file2.zip | 4176765952 |
| frd2.zip | 4176765952 |
| BACKUP.zip | 4078994432 |
| File44.zip | 4058424320 |
| file11.zip | 3858056192 |
| Backup2.zip | 3815138304 |
| BACKUP3.zip | 3815138304 |
| Current.zip | 3576931328 |
| Backup8.zip | 3307488256 |
| File999.zip | 3274982400 |
So verwenden Sie diese Daten, um die Mindestgröße des Staging-Ordners zu bestimmen:
- Name = Dateiname
- Länge = Größe in Bytes
- Ein Gigabyte = 1073741824 Bytes
Zuerst müssen Sie die Gesamtzahl der Bytes berechnen. Teilen Sie dann die resultierende Zahl durch 1073741824. Ich empfehle die Verwendung von Excel oder eines anderen Tabellenkalkulationseditors, den Sie für diese Berechnungen verwenden.
Beispielbasierte BerechnungenIm obigen Beispiel beträgt die Gesamtzahl der Bytes 75241684992. Um die minimal erforderliche Größe des Zwischenkontingents zu erhalten, müssen Sie 75241684992 durch 1073741824 teilen.
75241684992/1073741824 = 70,07 (GB)
Basierend auf den Daten würde ich die Größe des Staging-Ordners auf 71 GB einstellen und auf eine ganze Zahl aufrunden.
Praktische Anwendung
Trotz der Tatsache, dass manuelle Analyse eine interessante Sache ist, ist es nicht das Beste, Ihre Zeit damit zu verbringen. Verwenden Sie den dritten Befehl aus den obigen Beispielen, um den Prozess zu automatisieren. Das Ergebnis wird ungefähr so aussehen:
Mit dem Befehl aus dem dritten Beispiel kann ohne Berechnungen (ohne Rundung) festgestellt werden, dass für den Ordner d: \ docs ein Zwischenkontingent von 6 GB erforderlich ist.
Muss ich den Server neu starten oder den Dienst neu starten, um die Änderungen zu übernehmen?
Damit die am Kontingent des Staging-Ordners vorgenommenen Änderungen wirksam werden, muss der Server nicht neu gestartet oder der Dienst neu gestartet werden. Um die Änderungen zu übernehmen, müssen Sie warten, bis die AD-Replikation und der Abfragezyklus für DFSR-Objekte in AD abgeschlossen sind.
So identifizieren Sie Probleme mit dem Staging-Ordner
Probleme mit Zwischenordnern werden erkannt, indem bestimmte Ereigniscodes in den DFSR-Serverprotokollen verfolgt werden. Hier ist eine Liste dieser Ereignisse: 4202, 4204, 4206, 4208 und 4212. Beschreibungen für diese Ereignisse sind unten aufgeführt. Es ist wichtig, den Unterschied zwischen den Ereignissen 4202 und 4204 sowie anderen Ereignissen zu verstehen. Die Ereignisse 4202 und 4204 können in großer Anzahl und während des normalen Betriebs protokolliert werden. Stellen Sie sich die Ereignisse 4202 und 4204 als einen Puls vor, während 4206, 4208 und 4212 Brustschmerzen ähneln. Im Folgenden werde ich erklären, wie die Ereignisse 4202 und 4204 zu interpretieren sind.
Ordnerbezogene Ereignisse bereitstellen[Anmerkung Übersetzer. Die unten beschriebenen Journalereignisse werden in der Form dargestellt, in der sie in der russischen Lokalisierung von Windows Server 2012 R2 vorhanden sind.]Code:
4202Stufe:
WarnungDie DFS-Replikation hat festgestellt, dass der vom replizierten Ordner mit dem lokalen Pfad <Pfad> verwendete Staging-Speicherplatz seine Obergrenze überschritten hat. Der Dienst versucht, die ältesten Zwischendateien zu löschen. Dies kann die Leistung beeinträchtigen.
Code:
4204Level:
DetailsDer DFS-Replikationsdienst hat die alten Zwischendateien des replizierten Ordners mit dem lokalen Pfad <Pfad> erfolgreich gelöscht. Der Zwischenraum liegt jetzt unter der Obergrenze.
Code:
4206Stufe:
WarnungDer DFS-Replikationsdienst konnte alte Zwischendateien für den replizierten Ordner im lokalen Pfad <Pfad> nicht bereinigen. Der Dienst kann möglicherweise einige große Dateien nicht replizieren, und der replizierte Ordner ist möglicherweise nicht mehr synchron. Der Dienst versucht automatisch, den Staging-Bereich innerhalb von <X> min erneut zu bereinigen. Ein Dienst beginnt möglicherweise früher mit der Reinigung, wenn er feststellt, dass einige Zwischendateien entsperrt wurden.
Code:
4208Stufe:
WarnungDie DFS-Replikation hat festgestellt, dass der Staging-Speicherplatz das Staging-Kontingent des replizierten Ordners im lokalen Pfad <Pfad> überschreitet. Wenn Sie einige große Dateien replizieren, ist der replizierte Ordner möglicherweise nicht mehr synchron. Der Dienst versucht automatisch, den Staging-Bereich erneut zu bereinigen.
Code:
4212Stufe:
FehlerDer DFS-Replikationsdienst konnte den replizierten Ordner nicht mit dem lokalen Pfad <Pfad> replizieren, da der Zwischenpfad ungültig oder nicht verfügbar ist.
Was ist der Unterschied zwischen den Ereignissen 4202 und 4208?
Die Ereignisse 4202 und 4208 haben eine ähnliche Beschreibung, d.h. DFSR erkennt, dass die vom Staging-Ordner belegte Größe den Grenzwert überschreitet. Der Unterschied besteht darin, dass das Ereignis 4202 unmittelbar nach dem Start des Zwischenordner-Bereinigungsprozesses protokolliert wird, während das Zwischenkontingent noch überschritten wird. Das Ereignis 4202 ist ein Zeichen für einen normalen Normalbetrieb, während 4208 eine Abweichung von der Norm anzeigt und ein Eingreifen erfordert.
Wie viele Ereignisse 4202 und 4204 werden als zu groß angesehen?
Es gibt keine einheitliche Antwort auf diese Frage. Im Gegensatz zu den Ereignissen 4206, 4208 und 4212, die immer schlechte Dinge sagen und auf Handlungsbedarf hinweisen, treten die Ereignisse 4202 und 4204 auch während des normalen Betriebs auf. Häufige Ereignisse 4202 und 4204
können auf ein Problem hinweisen. Zu berücksichtigende Fakten:
- Werden während der primären Replikation 4202 Ereignisse für einen replizierten Ordner (RF) protokolliert? Wenn ja, dann sind die Ereignisse 4202 und 4204 normal. Wenn Sie während der ersten Synchronisierung die Anzahl dieser Ereignisse auf ein Minimum reduzieren möchten, können Sie dies erreichen, indem Sie den Zwischenordner vergrößern.
- Es reicht nicht aus, nur die Gesamtzahl von 4202 Ereignissen zu zählen. Sie müssen wissen, wie viele davon für eine bestimmte RF gelten. Wenn es in 24 Stunden zwanzig 4202 Ereignisse im Journal gab, die sich auf einen Ordner bezogen, dann ist das eine Menge. Wenn Sie jedoch 20 replizierte Ordner und jeweils ein Ereignis haben, ist alles in Ordnung.
- Um Trends zu identifizieren, müssen Sie die über mehrere Tage gesammelten Informationen analysieren.
Normalerweise rate ich Kunden, während des normalen Betriebs tagsüber nicht mehr als ein 4202-Ereignis pro repliziertem Ordner zuzulassen. "Normal" bedeutet, dass keine primäre Replikation stattfindet. Ich begründe dies mit folgenden Überlegungen:
- Die zum Bereinigen des Staging-Ordners benötigte Zeit entspricht der Zeit, die für die Dateireplikation benötigt wird. Die Replikation wird angehalten, während der Staging-Ordner bereinigt wird.
- DFSR arbeitet effizienter, wenn genügend Speicherplatz für das Intermediate zugewiesen ist. Es wird für RDC und dateiübergreifendes RDC sowie zum Replizieren identischer Dateien auf andere Replikationsmitglieder verwendet.
- Je mehr Ereignisse 4202 und 4204 protokolliert werden, desto größer ist die Wahrscheinlichkeit, dass Sie auf eine Situation stoßen, in der DFSR den Staging-Ordner nicht löschen kann oder gezwungen ist, Dateien vorzeitig zu löschen.
- Nach meiner Erfahrung wurden die Ereignisse 4206, 4208 und 4212 immer vorweggenommen und von einer großen Anzahl von Ereignissen 4202 und 4204 begleitet.
Das Befolgen der Regel "Nicht mehr als ein 4202 Ereignis pro Tag für jede RF" verringert die Wahrscheinlichkeit von Problemen mit dem Staging-Ordner erheblich und hilft dem DFSR-Server, Ressourcen für den beabsichtigten Zweck - die Dateireplikation - effizienter zu nutzen.
Weitere Informationen
https://blogs.technet.com/b/askds/archive/2010/03/31/tuning-replication-performance-in-dfsr-especial-on-win2008-r2.aspxhttps://blogs.technet.com/b/askds/archive/2007/10/05/top-10-common-causes-of-slow-replication-with-dfsr.aspxWarren "weit über meiner Oud-Quote" Williams