Das Thema Staging-Folder bzw. Staging-Quotas ist ein oft vernachlässigtes Thema, was in Folge dessen jedoch in der Praxis zu den meisten Problemen führt. Es wird in diesem HowTo bewusst eine Verbindungslinie zwischen diesen beiden unabhängigen Einstellungen gezogen, da zwischen der Größe der Staging-Folder (also dem Quota) und dem Replikationsverhalten eine starke Verbindung existiert.
Zuerst ein wenig Theorie, die ganz grob skizziert, was bei einer Änderung passiert.
Wird zum Beispiel eine Datei auf Server A geändert, der seine Daten mit dem Server B repliziert, sendet Server A nach der Änderung eine „change notification“ an den Server B. Nach einem Vergleich der Datenbanken (bzw. deren Einträgen) wird Server B nun eine Anfrage an Server A starten, welche Datei repliziert werden soll.
Server A wird nun, nachdem er die Anfrage von Server B erhalten hat, die entsprechende Datei „stagen“, d.h. die Datei packen und in den Staging Ordner unterhalb von „DfsPrivateStaging“ legen.
Dort wird mittels Remote Differential Compression (RDC) überprüft, welche Teile der Datei übertragen werden müssen, und die Datei wird dann in die benötigten Teile zerlegt.
Diese Teile werden zum Server B übertragen, der die Datei wieder zusammensetzt (ggf. unter Einbeziehung der lokalen Teile der Datei, die nicht mit übertragen wurden, weil Sie auf dem Server B schon vorhanden waren), um sie dann entpackt an den Speicherort zu legen.
Dieser Vorgang kostet, je nach Dateigröße und Dateityp, eine Menge CPU-Power und Disk-Performance. Es ist also sinnvoll, gerade bei oft geänderten Dateien die Daten nicht immer wieder neu zu stagen, sondern die Dateien nach Möglichkeit im Staging Folder liegen zu lassen, da dort viele „Dateistücke“ schon berechnet sind.
Das Staging-Folder unterliegt dem Staging-Quota. Das bedeutet, dass der Server A als auch der Server B ein Staging-Quota konfiguriert haben welches bestimmt, wie viele Daten dort hineingelegt werden dürfen.
Ist dieses Quota zu gering, müssen die Dateien immer wieder aufs neue gestaged werden, was eine hohe CPU-Last und Plattenlast zur Folge haben kann. Außerdem nimmt die Geschwindigkeit der Datenübertragung ab und es kann im schlimmsten Fall zum fast vollständigen Stillstand der Replikation kommen.
Hintergrund hierfür sind Einstellungen, die Microsoft für das Stagen von Daten standardmäßig verwendet. Es existiert eine sogenannte Low-Watermark (60% des Staging-Quotas) und eine High-Watermark (90% des Staging-Quotas). Wird die High-Watermark überschritten, werden aus dem Staging-Folder die jeweils ältesten Daten gelöscht, bis die Low-Watermark wieder erreicht ist, also 60% des Quotas.
Das Überschreiten der Watermarks und das daraus resultierende Löschen von Daten wird in den DFS-R Eventlogs unter den Event IDs 4202, 4204, 4206 e 4208 angezeigt. Eine sinnvolle Maßnahme ab diesem Punkt könnte also sein, das Quota um mindestens 50% zu erhöhen.
Stellt man sich also vor, dass man bei einem Staging-Quota von 4096 MB eine ca. 4 GB große Datei stagen möchte…
– muss diese gepackt,
– Checksummen errechnet
– und zerlegt werden;
– es müssen fast alle Daten aus dem Staging-Folder gelöscht werden,
– um dann die 4 GB große Datei zu übertragen.
Danach findet dieser Mechanismus für andere Dateien ebenfalls wieder statt, die wiederum neu berechnet werden müssen – ein hoher Aufwand.
Solange die Staging-Folder Größe unter 100% des Quotas liegt, wird der DFS-R Server insgesamt neun Dateien gleichzeitig replizieren: 5 sendende (outbound) e 4 empfangene (inbound) Threads, d.h. insgesamt 9 Dateien.
Wird ein Quota überschritten (das Quota ist „elastisch“, nicht „statisch“), wird ein Thread für den Löschvorgang genutzt, bis die Quota-Auslastung der betroffenen Replikationsgruppe wieder unter 60% sinkt.
Werden jedoch zum Zeitpunkt der Quota Überschreitung alle 4 inbound oder alle 5 outbound Threads genutzt, kann es in ungünstigen Konstellationen dazu kommen, che ALLE outbound bzw. inbound Threads oder die genutzten RPC Verbindungen des Servers blockiert werden, um den Aufräumvorgang des Quotas abzuschließen. Das bedeutet für die Praxis, dass kaum noch bzw. gar keine weiteren Daten außer diesen einen Datei übertragen werden und die sogenannten Backlogs stark anwachsen.
Um es noch einmal zu verdeutlichen: Tritt dieser Effekt ein, kann auf dem gesamten Server keine Replikationsgruppe mehr Daten replizieren, bis das Quota wieder unter 60% gesunken ist. Liegt jedoch eine Datei im Staging-Folder, welche insgesamt größer ist als das Quota, kann dieser Vorgang bis zum Abschluss der Replikation dieser Datei dauern. Das bedeutet in der Praxis also einen temporären Stillstand der Datenreplikation von diesem Server. Weitere Ausführungen dazu findet man unter [6].
Die Quotas haben per Default bei neuen Replikationsordnern eine Größe von 4096 MB. Diesen Wert sollte man in jedem Fall seinen Ansprüchen anpassen. Es muss ganz klar gesagt werden, dass es grundsätzlich keine konkrete Aussage zur Größe der Quotas geben kann – dies ist im Einzelfall zu entscheiden. Jedoch sollte man die Größe des Quotas nach Möglichkeit so groß als irgend möglich im Verhältnis zu der Datenmasse der zu replizierenden Daten wählen. Im besten Fall ist das Quota sogar genauso groß wie diese Datenmasse der entsprechenden Replikationsgruppe.
Während der Initialreplikation wird im Normalfall sehr viel Quota-Platz benötigt, da alle Daten übertragen werden müssen (es sei denn es wurden Daten Pre-Staged oder Cross-File-RDC ist möglich). Aus diesem Grund ist es empfehlenswert, während der Initialreplikation das Quota sehr großzügig zu wählen. Im besten Fall, bei ausreichend Speicherplatz, mindestens genauso groß wie die Gesamtsumme der zu replizierenden Daten (siehe oben).
Hat man noch mehr Speicher frei, kann man sogar bis zu einer Daumenformel von 1,5x Replikationsordnergröße für das Quota gehen, da durch Checksummen, alten Staging-Files etc. durchaus mehr Daten zusammenkommen können, als das Folder selbst bereitstellt.
Es ist zu beachten, dass die Quotas (wie oben kurz erwähnt) auf allen Servern bzw. Replikationsordnern einzeln eingestellt werden müssen. Ferner ist dabei zu beachten, dass die Quotas lediglich pro Replikationsordner gelten, das heißt auf allen Replikationsgruppen nach Bedarf angepasst werden können (und sollten).
HINWEIS: Zum Abschluss dieses Themas noch einmal der eindringliche Hinweis, die Quotas sehr gut zu planen und immer im Auge zu behalten. Gibt es hier Probleme, ist unter Umständen die gesamte DFS-R Struktur betroffen.
Autor: olc, MCSEboard.de