Toepassing / Ervaring met Microsoft DFS (Distributed FS)

[Q]

Hallo,

DFS lijkt me erg handig om een primary server te syncen met een failover / backup server (in een andere server ruimte voor failover/disaster recovery).

Ik ben er flink ingedoken en DFS is erg stoer, maar het maakt me ook bang. Ik heb het plan om 5 TB aan data in sync te houden. Dat doe ik niet met 1 replicatie map, maar dat verdeel ik over meerdere mappen, om niet tegen de DFS limieten aan te lopen.

Ik weet van onze backup dat na een maand ongeveer 200 GB aan data als gemuteerd wordt gezien. Dat is maar een fractie van de 5 TB.

DFS is primair bedoeld voor statische data en niet voor data die regelmatig wordt aangepast. Ik zie soms issues met EXCEL files die vaak open staan. Dat databases (access, sql) niet werkt, lijkt me logisch, maar EXCEL files zouden toch geen issues moeten geven?

Ik ben erg benieuwd hoe anderen met DFS omgaan.

Momenteel draaien we DFS op twee virtuele Windows 2008 R2 machines en opzich gaat dit goed. Geen backlog, alleen af en toe wat replicate issues van open bestanden.

[Linke Loe]

Ik gebruik DFS ook in onze omgeving om data zowel lokaal, als in ons datacenter beschikbaar te hebben, onder dezelfde namespace. Wij hebben namelijk kantoren in Nederland, Belgie en Duitsland, aangesloten op ons datacenter door middel een VPN. Op deze kantoren draait ook lokaal een fileserver. DFS repliceert zo de map met NL data naar de fileserver in Nederland, BE data naar Belgie en DE data naar Duitsland. Gebruikers die op onze terminal server omgeving werken benaderen de data vanuit ons datacenter, gebruikers met een PC of een laptop benaderen de data op de locale fileserver.

Bijkomend voordeel van DFS is dat een toekomstige migratie naar een nieuwe fileserver een stuk makkelijker is. Je voegt de nieuwe fileserver toe aan de replication group en als alles lekker gerepliceerd is haal je de oude er uit. Alles draait dan gewoon lekker door zonder dat je je clients naar een nieuwe server moet verwijzen.

[Q]

Precies, dat is het mooie van DFS en ook de reden dat ik het graag wil toepassen.

Hebben jullie geen issues met conflicten tussen versies van bestanden op verschillende servers?

[Linke Loe]

Het komt wel eens een enkele keer voor dat er een conflct optreedt, maar het aantal keren per jaar is op een hand te tellen.

[Equator]

Dfs is een mooie techniek, maar het is niet bedoeld om samen met een collega in hetzelfde document te werken. File locking werkt dan niet.
Daarvoor heb je o.a. sharepoint

[Q]

Daarvoor is het ook zeker niet bedoeld inderdaad en zo gebruiken wij het ook niet. Ik sta er toch een beetje alleen voor met dit soort zaken en 5 TB aan data is spannend.

na een reboot vanavond van de 2 servers gaf dfs diagnostics geen fouten meer.

[Trommelrem]

Er is een heel groot verschil tussen DFSN, DFSR en DFS.

DFS is het oude Windows 2000/2003 protocol, waar FRS onderdeel van is. Hoewel dat opzich werkte, had het erg veel nadelen. Vanaf Windows 2003 R2 is er ook DFSR. DFSR is de naamgevinginfrastructuur en DFSR is de replicatieinfrastructuur. Beiden zijn twee verschillende dingen.

Ik gebruik DFSR voor de replicatie van persoonlijke data tussen de locatie van mijn ouders en mijn thuislocatie. Het is de twee Windows licenties meer dan waard gebleken. Ik heb daardoor naast de offline backup ook een live-backup in geval van brand. Ook is de data vanaf beide locaties tenminste snel toegankelijk.

Ik gebruik DFSN voor de makkelijke naamgeving. Waar je ook bent, je hebt altijd één folderstructuur om de bestanden te benaderen.

[Q]

Ik gebruik DFSR en DFS omdat het domein helaas nog op 2003 zit. FRS wordt niet gebruikt.

[Trommelrem]

Volgens mij werkt DFSR en DFSN zelfs met een Windows 2000 mixed Domain Functional Level. Alleen voor SYSVOL DFSR is een Windows 2008 Domain Functional Level vereist.

[Insehh]

Als je van plan bent om het domein dadelijk ook naar 2008 te upgraden, hou dan ook bv. rekening met je virusscanners & FRS....

En wat betreft DFSR:
- Meerdere root targets op meerdere machines voor redundantie van je data.
- Draai geen DFS op je controllers
- Als je trage links hebt (Hub/Spoke), regel dan one way traffic. Belast je link in ieder geval niet zo zwaar, zodat data alleen op de "hubs" gerepliceerd wordt.
- Als je DFS gaat implementeren, maak dan meerdere DFS links. DFS gebruikt client awareness zodat de dichtsbijzijnde link gebruikt wordt.

Zoals je zelf al aangaf, als twee users tegelijk een file openen, schrijft het laatst opgeslagen bestand de vorige over. DFS is dan ook niet handig om te gebruiken voor files die regelmatig veranderen. Tenzij je het buiten kantooruren scheduled, maarja, als iemand s'avonds nog vanuit thuis werkt...

[ Voor 0% gewijzigd door Insehh op 19-11-2013 09:03 . Reden: Specifieker wbt virusscanners ]

[Q]

De users werken op dezelfde server, de 2e server is alleen voor nood.

Ik heb echter een groot probleem: corruptie in Excel files. Het zijn shared excel files waarin de corruptie lijkt op te treden.

Ik heb zelfs de virus scanner op de file server uitgezet, maar toch nog corruptie.

Uiteindelijk heb ik DFS maar uitgezet. Dit kan zo niet. Met heel veel werk en moeite kan ik dit misschien oplossen, maar ik heb de tijd gewoon niet.

Terug naar robocopy

Fuck.

[ Voor 56% gewijzigd door Q op 19-11-2013 11:52 ]

[Insehh]

Q schreef op dinsdag 19 november 2013 @ 11:48:
De users werken op dezelfde server, de 2e server is alleen voor nood.

Ik heb echter een groot probleem: corruptie in Excel files. Het zijn shared excel files waarin de corruptie lijkt op te treden.

Ik heb zelfs de virus scanner op de file server uitgezet, maar toch nog corruptie.

Uiteindelijk heb ik DFS maar uitgezet. Dit kan zo niet. Met heel veel werk en moeite kan ik dit misschien oplossen, maar ik heb de tijd gewoon niet.

Terug naar robocopy

Fuck.

Als ze op dezelfde server werken merk je er niet heel veel van, alleen tussen de servers zelf, maar goed dat is ook het nut ervan.
Corruptie krijg je als meerdere mensen hetzelfde bestand openen of wanneer het bestand opnieuw geopend is tijdens replicatie. Vandaar: buiten kantooruren of in de pauze bv...

Virusscanners editten de NTFS security tag, waardoor het bestand dus, weliswaar minimaal, veranderd.

Maak eerst in een geïsoleerde testomgeving een PoC, en bouw vanuit daar verder. Het werkt wel, alleen goed snuffelen. :-)

[Trommelrem]

Insehh schreef op dinsdag 19 november 2013 @ 12:03:
[...]
Virusscanners editten de NTFS security tag, waardoor het bestand dus, weliswaar minimaal, veranderd.

RDC.

Q schreef op dinsdag 19 november 2013 @ 11:48:
Uiteindelijk heb ik DFS maar uitgezet. Dit kan zo niet. Met heel veel werk en moeite kan ik dit misschien oplossen, maar ik heb de tijd gewoon niet.

Je zei dat je nog een Windows 2003 domain functional level draaide. Daarin kun je prima DFSR draaien. Ik zou niet met het oudere DFS gaan werken. De tegenwoordige virusscanners zullen ook niet compatible meer zijn met het oude DFS/FRS, wel met het nieuwere DFSR.

Waarom probeer je niet DFSR? Waarom perse FRS? Je zal zien dat er vele nieuwe (en nuttige) functies bij komen, waardoor het beheer ineens veel makkelijker wordt.

[ Voor 62% gewijzigd door Trommelrem op 19-11-2013 14:02 ]

[Q]

Nee, ik werk op 2008 met DFSR. Ik heb het op kleine schaal getest, het lijkt alleen fout te gaan met gedeelde excel bestanden. Erg genoeg.

Ik zit wel warm:

http://social.technet.mic...ions?forum=winserverfiles

Ik zie die rare 8 tekens van files waar DFSR over klaagt. Maar ook veel files raken corrupt waar ik niets van terug zie in de logs. Ik heb al wat mensen een previous version laten restoren, maar zo raken mensen data kwijt.

Terug naar de teken tafel.

Mijn plan was om DFS puur te gebruiken als een real-time backup naar een 2e server, waar mensen niet op werken (behalve in nood).

EDIT:

Ik denk dat ik een vermoeden heb waarom bij ons DFSR fout gaat. De primaire map met data wordt niet via DFS gepubiceerd in de DFS namespace, ze wordt alleen via DFSR gerepliceerd. De Map met data die dus met DFS gerepliceerd wordt is NIET gepubliceerd op enige manier. Ik weet het niet zeker maar ik denk dat DFS dat dus niet zo tof vindt. Of zou dat zonder problemen moeten werken?

[ Voor 89% gewijzigd door Q op 19-11-2013 22:31 ]

[Acmosa]

Hou ook rekening mee (testen) dat de kans bestaat dat je backup van je fileserver ineens erg traag wordt.
Er zijn gevallen bekend (persoonlijke ervaring) dat dfs, en in mijn geval Symantec backup exec niet lekker samen werken waardoor de snelheid van mijn backup terug liep naar een paar mb (minder dan 10) per seconden.

Zoek er maar eens op.

[Q]

Ik heb daar artikelen over gezien en wij gebruiken Symantec, ik ga dat even controleren, bedankt.

[Linke Loe]

Ik ben van mening dat je DFSR niet moet gebruiken als enige vorm van backup. Als een bestand verwijderd wordt, of corrupt raakt aan de ene kant, gebeurt dat ook aan de andere kant. Als de primaire server crasht, heb je weliswaar nog wel de bestanden op de andere server, maar je bouwt in ieder geval geen retentie op.

Ook kun je niet helemaal voorkomen dat gebruikers bestanden op de andere fileserver openen. In principe worden bestanden geopend op de server in dezelfde AD site. Als beide servers in dezelfde site draaien, gaat die vlieger dus al niet meer op.

Als je aan een DFS folder een tweede target toevoegt, krijg je toch gewoon de vraag of er een replication group aangemaakt moet worden? Het lijkt er een beetje op dat jij eerst een replication group aangemaakt hebt en alsnog vergeten bent om een target server toe te voegen...

Ook ik had problemen met BackupExec, maar dan vooral met het restoren van bestanden. Op het moment dat ik een restore deed, direct naar DFS, ging alles opnieuw repliceren. Met een DFS folder waar zo'n 500 GB aan dat in staat, gaat dat een tijd duren, waardoor gebruikers begonnen te klagen. Bij een restore moest ik het bestand ergens anders restoren en daarna kopieren naar mijn DFS folder. Nu gebruiken we Veeam en gaat het restoren erg snel en eenvoudig, direct naar DFS.

[Trommelrem]

Acmosa schreef op woensdag 20 november 2013 @ 06:46:
Hou ook rekening mee (testen) dat de kans bestaat dat je backup van je fileserver ineens erg traag wordt.
Er zijn gevallen bekend (persoonlijke ervaring) dat dfs, en in mijn geval Symantec backup exec niet lekker samen werken waardoor de snelheid van mijn backup terug liep naar een paar mb (minder dan 10) per seconden.

Zoek er maar eens op.

Symantec Backup Exec niet gebruiken in combinatie met DFSR of FRS! BE ondersteunt DFSR en FRS namelijk niet. Bron: Symantec klantenservice. Geldt voor: alle momenteel ondersteunde versies.

[ Voor 3% gewijzigd door Trommelrem op 20-11-2013 09:52 ]

[Acmosa]

Ik gebruik nu Backup Exec 2012 Met een Windows 2008 R2 DFS fileserver (DFS dient voor replicatie van alle remote locaties)
In samenwerken met een externe partij hebben we de backup weten de optimaliseren door de backup job van de fileserver op te splitsen in 4 jobs per fileserver volume en te stagen naar disk. Op deze manier halen we wel voldoende doorvoersnelheid.

Het is wel mogelijk om symantec BE te gebruiken in combinatie met DFS(R).
Backup en restore werken gewoon en symantec heeft documentatie over hoe dit geconfigureerd dient te worden.
http://www.symantec.com/c...d-file-system-backup-exec

Het is dus, imho, wat kort door de bocht om te zeggen dat het niet wordt ondersteund.

[Question Mark]

Q schreef op maandag 18 november 2013 @ 14:23:
DFS lijkt me erg handig om een primary server te syncen met een failover / backup server (in een andere server ruimte voor failover/disaster recovery).

Wat voor verbinding zit er tussen de twee serverruimtes? Wellicht dat er betere opties zijn om DR aan te bieden, maar dat zal afhankelijk van de snelheid zijn.

En wat zijn je exacte eisen voor je disaster recovery site? Hoelang mag een recovery duren en hoeveel data mag verloren zijn? Dat zijn ook even twee belangrijke parameters om je DR oplossing te bepalen.

[Q]

We hebben twee server ruimtes 200 meter van elkaar vandaan. Daar tussen zit glas 1 gigabit (redundant). Ik denk dat je al een beetje gaat snappen wat het idee is.

We hebben ook nog een backup server met 20TB disk chassis voor disk backup waar ook een tape library aan hangt.

Ik had eigenlijk het idee om de twee servers dus gewoon DFSR te laten doen, en dan dus vanaf server 1 naar 2 en vandaf 2 naar de backup server (2008 R2) storage -> read only en dan vanaf disk direct naar tape te backuppen. Dat geeft een mooie tape snelheid. Het probleem is dat een Backup Exec 2012 rechtstreeks vanaf een FS via het netwerk super traag is. Als dat instant repliceert dagelijks naar die backup server van FS1 naar FS2 naar backupserver storage, is dat natuurlijk veel sneller en mooier.

DFS is natuurlijk zeker niet mijn enige 'backup' (het is meer een soort RAID 1 over 2 servers), ik heb disk en tape backup geregeld. DA parameters: ik wil mijn organisatie niet afvallen maar deze staat qua IT anno 2013 echt nog in de kinderschoenen. Ik ben al blij als straks de infrastructuur echt solide is, dat kost me nog wel een aantal maanden tot een half jaar, ik ben praktisch alleen.

@Acmosa: bedankt voor de tip. Wij doen ook BE 2012. Dus goed om te weten.

[ Voor 17% gewijzigd door Q op 20-11-2013 21:58 ]

[Trommelrem]

Acmosa schreef op woensdag 20 november 2013 @ 15:38:
Het is dus, imho, wat kort door de bocht om te zeggen dat het niet wordt ondersteund.

Als Symantec tegen mij zegt dat FRS en DFSR niet wordt ondersteund en dat het gebruik van BE in combinatie met FRS en DFSR problemen kan geven, dan blijf ik liever weg van BE. Dat was na een issue met BE in een DFSR environment, waarna Symantec support met die mededeling kwam. Het ging niet over die specifieke configuratie, FRS en DFSR in het algemeen zouden niet worden ondersteund in BE.

[ Voor 21% gewijzigd door Trommelrem op 21-11-2013 10:24 ]

[Zoetjuh]

Wij gebruiken DFS+DFSR bij verschillende klanten (laatste opgezette opgeving op basis van 2012R2 met Remote Differential Compression); vergelijkbaar met een eerdere genoemde omgeving (primair werken vanuit het datacentrum dmv RDP, maar een replica van alle "statische" data op locaties). Het gaat daarbij om de Mijn Documenten en afdelingsbestanden (dus geen databases e.d.).

Neen, DFSR is niet bedoeld om op verschillende sites aan de zelfde bestanden te werken. Het ("ahum") algoritme dat Microsoft gebruikt is vrij simpel: Last Writer Wins. Maargoed, wel ideaal dus wanneer de verbinding met het datacentrum er onderhoopt uit ligt, of je zaken doet die via Remote Desktop misschien niet lekker te doen zijn (moet zeggen, dat is met 2012 R2 ook geen issue meer, maar dat is offtopic).

Ten aanzien van back-up; DFSR is een replica (een 1-op-1 kopie), dus niet een back-up.
Wat wij nog wel eens doen, is deze data op een locatie ook nog eens back-uppen naar disk/tape (maar dat staat dus los van het feit dat DFSR gebruikt wordt).

Houd er rekening mee dat (in ieder geval in 2008R2) DFS-data nog wel eens onder System State data kan vallen en als je stevig aan het repliceren bent, een back-up maken (afhankelijk van de software) inderdaad wel eens voor issues kan zorgen. Is je fileserver een VM, zou ik persoonlijk van de VM een snapshot maken en deze back-uppen.

[Trommelrem]

Zoetjuh schreef op donderdag 21 november 2013 @ 14:11:
Neen, DFSR is niet bedoeld om op verschillende sites aan de zelfde bestanden te werken. Het ("ahum") algoritme dat Microsoft gebruikt is vrij simpel: Last Writer Wins.

Toch kom ik dit soms tegen. Ik ben weleens ingehuurd om DFSR problemen op te lossen. Vaak is het probleem inderdaad dat er in dezelfde bestanden wordt gewerkt. Veel andere voorkomende problemen zijn problemen doordat de standaardinstellingen zijn gebruikt, zoals RDC over een snelle LAN en IPv6 problemen bij DFSN.

Er was eens iemand die DFSR en DFSN gebruikte voor loadbalancing tussen twee servers. Ook hier werden de standaardinstellingen gebruikt en het gevolg was dat beide servers er extreem traag van werden.

DFSN en DFSR zijn geen rocket science, maar er zijn wel enkele simpele regels waar je je aan moet houden.

[ Voor 6% gewijzigd door Trommelrem op 21-11-2013 16:12 ]

[Q]

Bedankt voor alle nuttige commentaren. Wij waren van plan om DFS-R te gebruiken op de 'veilige' manier en niet dat mensen op verschillende servers werken. In dat laatste is het een kwestie van tijd voordat er problemen ontstaan.

Ik zit er nu midden in, maar het verhaal wordt complexer. Als de boel is afgehandeld zal ik dat verhaal vertellen, ik denk dat dit wel gewaardeerd wordt. Stay tuned.

[Equator]

Q schreef op donderdag 21 november 2013 @ 20:52:
Bedankt voor alle nuttige commentaren. Wij waren van plan om DFS-R te gebruiken op de 'veilige' manier en niet dat mensen op verschillende servers werken. In dat laatste is het een kwestie van tijd voordat er problemen ontstaan.

Ik zit er nu midden in, maar het verhaal wordt complexer. Als de boel is afgehandeld zal ik dat verhaal vertellen, ik denk dat dit wel gewaardeerd wordt. Stay tuned.

Maar heb je dan nu het idee dat er op beide servers tegelijkertijd wordt gewerkt? Waardoor er dus corruptie ontstaat?

[Q]

Nee, dat kon niet, iedereen werkt via een DFS path dat alleen naar de 1e FS wijst.

De oorzaak van de data corruptie was niet DFS.

We hebben een VMware host die data corruptie op zijn netwerk interface(s) heeft.

Extra tests wezen uit dat alle VMs op die host er last van hadden, ook Linux VMs -> data transfer failed vanwege 'corrupt packet'.

Niet. Te. Geloven.

Mogelijk dat ik een hardware firmware update heb gemist. Of misschien is het een VMware driver.

Heeft iemand dat ooit wel eens gezien?

Leuk klusje nu om de users te helpen welke data wel/niet corrupt is. Aan de backup hebben we niet al te veel, want die backupped ook corrupte data. Alle data die is aangepast of aangemaakt is gedurende dit issue is verdacht.

Als iemand een tool weet die je over de data kunt rossen om te zien of er mogelijk corruptie in zit (pdf/xls/doc) dan hou ik me aanbevolen.

[ Voor 9% gewijzigd door Q op 22-11-2013 08:26 ]