DFSR 2008R2 SP1 replicatie, backlog en staging directories

Vandaag een leuke ervaring rijker met DFS. Ik heb hier in het verleden veel mee gewerkt maar nog niet veel met de 2008R2 variant. De ervaring leert dan ook dat er erg veel over is te vinden op het internet maar wat is nu accuraat, wat is nog relevant. Onderstaand is van toepassing op 2008R2.

In het algemeen over DFS. DFS is een oplossing om data van meerdere servers centraal aan te bieden. Dit maakt 2 dingen mogelijk als speerpunt mogelijk, één er is niet één grote server welke bijvoorbeeld alle data moet aanbieden en dus een single point of failure is. Maar ook dat wanneer de data over meerder servers word verspreid het voor een eindgebruiker wel als één server over kan komen.

Denk aan het voorbeeld dat uw “S” schijf (een simpele data schijf) nu zowel foto’s, autocad tekeningen en de gebruiker data bevat. Dit is niet altijd zomaar uit elkaar te trekken zonder veel overlast voor een eindgebruiker. Met DFS is het mogelijk dit wel te doen, toch alles onder de S schijf te houden maar de data vanaf meerdere servers aan te bieden. Waarbij de ene bron een 2008 server is, de 2e bron een 2012 server en de 3e bron (t.b.v. foto’s) een NASje op het netwerk is welke direct aangesproken word. En dit alles word weergegeven als één schijf / drive-letter.

DFSR, er zijn recommended patches voor DFSR 2008R2, echter wanneer je SP1 draait zijn deze momenteel niet relevant. Altijd even controleren.

De DFSR bleek niet meer goed te lopen. Er is een replication group tussen 2 servers met ongeveer 800GB aan data. Als je nagaat dat DFS gebruik maakt van RDC (Remote Differential Compression) is dat niet veel. RDC houd in dat wanneer je 5 getallen in een Excel sheet van 10mb wijzigt, alleen de wijzigingen over de lijn gaan.

En nu terug naar de technische kant van DFS

Voordat we verder gaan, een aantal noodzakelijke wetenswaardigheden:

Replicatie gebeurt doormiddel van een initiële replicatie.
PST files, advies is dit niet via DFS te doen. Er zijn fine-tuning waardes voor Outlook maar mijn advies is, niet doen.
Backlog, een log file welk bijhoud hoeveel files en welke er nog gerepliceerd dienen te worden.
Staging, de map waarin files komen te staan die nog gerepliceerd dienen te worden.
High/Low Watermark, grof gezegd de ruimte waarbinnen files moeten passen die gerepliceerd worden. Een file die er niet in past gaat over de “high” watermark heen en kan dus niet worden gerepliceerd.

Wat was het probleem. De klant had last van een DFS die niet goed repliceerde. Er waren veel “High watermark” meldingen in het DFSR logboek. De klant had de Staging directory aangepast om deze files toch mee te kunnen nemen in de replicatie. De replicatie van 4GB was opgehoogd naar 8GB wat op zich de correcte manier is.

Echter bleek dat de files welke deze melding genereerde PST files waren. Dit word sterk ontraden om de simpele reden dat Outlook deze “in use” houd waardoor replicatie vrijwel niet plaats kan vinden. De “files” verbruiken echter wel de ruimte in de “Staging” directory waardoor deze vol staat, er geen andere files meer bij kunnen en dus de gehele replicatie tot stilstand komt.

Om hierachter te komen zijn de volgende stappen ondernomen:

RDC activeren / uitschakelen en replication schedule

Allereerst heb ik bekeken of RDC op de replication group aanstaat. Dit kan je doen via DFS Management, selecteer de Repilication group en kies voor het tabblad: “Connections”. Door de properties van de sending members op te vragen kan je kiezen voor: “Use Remote Differential Compression (RDC)”. Deze stonden op beiden aan.

In ditzelfde venster kan je ook de replicatie properties opgeven.

Health report / Propagation test (inzicht in backlog)

Met behulp van diagnostic reports kan je inzage krijgen in de actuele status. Deze kan je generen door rechts te klikken op de replication group en een dergelijk rapport te genereren. De belangrijkste optie die je nog kan kiezen is: “Count the replicated files and their sizes on each member”. Kort samengevat geeft dit je een goed beeld van de huidige situatie. Een blik op de rapportage moet je op weg kunnen helpen.

Propagation test, hiermee gaat de DFS zelf een file plaatsen, deze monitoren en de replicatie aan de hand hiervan controleren. Tevens word er gemeten hoe snel dit alles plaatsvind. Doormiddel van een Propagation report kan je inzage krijgen in de resultaten.

Via de command line, backlog

Persoonlijk houd ik van snel en makkelijk schakelen en de mogelijkheid om monitoring te kunnen bouwen. Dit kan vrij gemakkelijk door e.e.a. via de commandline te doen. Mijn gebruikte opties om de backlog uit te lezen zijn:

Backlog weergeven van repmember1 naar repmember2

dfsrdiag backlog /rgname:domein.local\profiledata /rfname:UserProfiles /sendingmember:repmember1 /receivingmember:repmember2 /v | more

en andersom de backlog uitlezen (repmember2 naar repmember1

dfsrdiag backlog /rgname:domein.local\profiledata /rfname:UserProfiles /sendingmember:repmember2 /receivingmember:repmember1 /v | more

Dit geeft een output van de files die in de log staan. In mijn geval bevonden zich hierin erg veel PST files. Door hier een filter op te zetten kon ik dit later op andere manieren aanvliegen.

File replication filter

Via de properties van een replicatie groep kan je naar het tabblad: “Replicated Folders” hier kan je per folder de properties opvragen en een filter instellen. Een file filter voorbeeld in mijn geval is:

~*, *.bak, *.tmp, *.pst

Een subfolder filter werkt puur, en alleen, op folder naam. Kortom, TEMP werkt. Wanneer je pietje\temp op zou geven zou alleen een folder met de naam “pietje\temp” uitgesloten worden.

Replication Filter Changes doorvoeren

En het duurde maar, voor mijn gevoel, eerdat het filter actief was. Een filter verloopt via de AD en dient dus eerst gerepliceerd te worden naar alle AD member servers, en vervolgens zullen de DFSR servers het pas oppakken. Je kan via sites en services de replicatie wat helpen “lees forceren”. Maar nu dien je de DFSR members nog te garanderen dat ze bij zijn. Dit kan je doen door per DFSR member een nieuwe config op te halen bij iedere dc op de volgende manier:

dfsrdiag.exe PollAD /Member:domain\v-dc01
dfsrdiag.exe PollAD /Member:domain\v-dc02
dfsrdiag.exe PollAD /Member:domain\p-dc03

Belangrijk, geduld

Wat belangrijk is, is dat je geduld hebt. De backlog is niet zomaar leeg. Een controle op de NIC’s hoef lang niet alles te vertellen. Bijvoorbeeld, is een file in use of zijn alleen de rechten veranderd geeft grote verschillen. Kijk het even 5 minuten aan en vooral of die dan voorzichtig leeg begint te lopen.

Zoniet, controleer of de files nog bestaan.

Aanvullend gaan replication filters pas actief zodra de backlog verwerkt is. Kortom, files dienen eerst echt te failen of een keer gekopieerd te zijn eerdat het filter ze uitsluit van replicatie.

Sommige files worden niet gerepliceerd

Het kan zijn dat sommige files niet meegenomen worden in de replicate. Wellicht staat dan het “TEMP” attribute op de file enabled. Dit kan je niet via de GUI zien maar alleen met fsutil opvragen. Normaliter zijn het dan ook temp files en DFS-R is hardcoded voorzien van een filter hierin. Echter, met crappy software kunnen zulke dingen gebeuren.

Een voorbeeld van een file welke niet wil repliceren:

fsutil usn readdata “D:\Company Shared Folders\Users\username\My Pictures\filename_20101130211009_2111000.avi”

deze gaf als output:

Major Version    : 0x2
Minor Version    : 0x0
FileRef#         : 0x0002000000011726
Parent FileRef#  : 0x003400000000a63a
Usn              : 0x000000035dc5dd20
Time Stamp       : 0x0000000000000000 0:00:00 1-1-1601
Reason           : 0x0
Source Info      : 0x0
Security Id      : 0x0
File Attributes  : 0x120
File Name Length : 0x48
File Name Offset : 0x3c
FileName         : filename_20101130211009_2111000.avi

Het file attributes is hier 0x120, de 0x20 is voor “Archive” en de 0x100 is voor “TEMP”. Hardcore coded in DFS-R is dat deze TEMP files niet worden meegenomen. Doormiddel van een script zullen we alle temp attributes eraf halen. Robocopy had ze immers ook meegenomen.

Powershell script voor het verwijderen van het TEMP attribuut

Met het volgende script kan je het temp attribuut van alle files in een onderliggende map verwijderen.

Get-childitem “D:\Company Shared Folders\Users\” -recurse | ForEach-Object -process {if (($_.attributes -band 0x100) -eq 0x100) {$_.attributes = ($_.attributes -band 0xFEFF)}}

Laatste redmiddel

Een laatste redmiddel, zo noem ik het zelf, is de replication group verwijderen en “even” opnieuw bij elkaar te klikken. Tuurlijk, het werkt, maar wie zegt dat je dan de oorzaak ook oplost.