Windows Shared folders over VPN

[citruspers]

Als stagiair ben ik belast met het ontwerpen van een oplossing om shared folders beschikbaar te maken op de 2 sites binnen een domein. Deze sites zijn verbonden via een relatief trage en instabiele WAN link, dus ik wil het graag allemaal zo efficient en redundant mogelijk laten lopen. Er wordt gebruik gemaakt van redirected folders (dus documents/downloads worden transparant op de server opgeslagen en lokaal gecachet). Daarnaast zullen er nog enkele normale shares zijn die als driveletter gemapt worden.

De gebruikte servers zijn SBS 2011, 2008R2 en 2008R2 Foundation

Ik ben nog niet zo bekend met Windows Server architecturen en features maar dit is waar ik tot nu toe op uitgekomen ben:

Branchcache: Perfect voor mijn doeleinden, maar werkt zo te zien niet goed samen met redirected folders, en heeft als groot nadeel dat de machines van Win7 enterprise moeten worden voorzien.

Offline files+redirected folders: heeft al lokale caching, maar door de flexwerkplekken moeten wel alle bestanden over de WAN link als de gebruiker nog niet op die computer heeft ingelogd.

Files mirroren op de servers: kan versieconflicten geven, werkt niet lekker met redirected folders, niet flexibel als de gebruiker van locatie wisselt.

Schema'tje van de setup


De rockende ACDC server moet natuurlijk een ADDC zijn

De 2e locatie heeft zo'n 7 medewerkers, kom ik dan weg met de initiele vertraging bij het voor het eerst inloggen op een PC? Offline files synchroniseert op de achtergrond, er hoeft dus niet 20 minuten gewacht te worden bij het inloggen zoals met roaming profiles.

Zie ik iets over het hoofd? Bij voorbaat dank

[bgrr]

kort antwoord : Terminal Server :-)

[citruspers]

Mag ik daarvan het lange antwoord?
Want zo op het eerste gezicht zie ik toch een paar nadelen:

Al het rekenwerk wordt dan op de server gedaan. Dat is prima voor kantoorapplicaties, maar het betreft een software development bedrijf. Lijkt me dat dat performance problemen op gaat leveren bij het compileren.
Er zijn al een paar "servers" aangeschaft, voor terminal services moet daar toch een stuk meer cpu power en geheugen in lijkt me, dan nodig is voor een SBS.

[Question Mark]

citruspers schreef op dinsdag 18 oktober 2011 @ 14:52:
Deze sites zijn verbonden via een relatief trage en instabiele WAN link,

bgrr schreef op dinsdag 18 oktober 2011 @ 14:55:
kort antwoord : Terminal Server :-)

Ja, handig over een trage en instabiele verbinding. Dat valt onder de categorie: "gebruikers pesten"

@TS: kijk even naar de mogelijkheden van DFS.

[ Voor 5% gewijzigd door Question Mark op 18-10-2011 15:48 ]

[citruspers]

Ahh, dus dan laat ik de shares in AD verwijzen naar \\domeinnaam\dfsroot\shares en dan pakt hij automatisch de dichtstbijzijnde, afhankelijk van met welke DC hij verbonden is?

[Question Mark]

Klopt helemaal. Selectie wordt dan gemaakt op basis van AD sites. Bovendien verloopt replicatie op blocklevel niveau.

Kleine kanttekening is wel dat DFS geen record locking kent. Wordt dezelfde file op twee lokaties tegelijk bewerkt dan geld het principe "last write wins" bij replicatie. Wel is er 3rd-party software te krijgen die deze functionaliteit toevoegen.

[citruspers]

Interessant. Record locking is minder belangrijk, Redirected folders zouden toch nooit meer dan 1 gebruiker per persoonlijke map kunnen hebben, en een binaries share zou toch read only zijn en een inleverspot voor de code (naast SVN) heeft ook persoonlijke subfolders. Ik moet dus alleen de gebruikers aanleren om niet op 2 machines tegelijk ingelogd te zijn (of kan vast wel via een GPO).

Dit valt natuurlijk ook weer te combineren met Offline files, waardoor de bestanden ook nog eens lokaal opgeslagen worden, en beschikbaar zijn als beide servers plat liggen neem ik aan.

Ik ga er eens naar kijken, merci

EDIT: is het eventueel ook mogelijk om de DFS data van 1 site te dumpen, en bij uitval te transplanteren op de tweede site, zodat die een "head start" krijgt bij het hersynchroniseren? Want bij een catastrofe waarbij zowel de machineschijf als de backup het begeeft is het misschien sneller om een HDD over te vliegen dan alles over de WAN link te pushen

[ Voor 22% gewijzigd door citruspers op 18-10-2011 16:24 ]

[alt-92]

[google=prestaging DFS replication] is dan denk ik wel verstandig

[citruspers]

Ik wist niet dat zoiets prestaging heette, bedankt. Wel heb ik wat horror stories gevonden over de 30 day tombstone flag en het feit dat windows doodleuk een lege DFS share synchroniseert naar de volle DFS share, in plaats van andersom

[alt-92]

prestaging of preseeding

[Bielie993]

DFS is inderdaad een goede oplossing. Misschien een idee om het gewoon eens uit te testen? DFS is immers geen service die iets wat al draait in de war gooit.

Globale installatie
DFS installeren, mapje aanmaken op lokaal station, mapje op lokaal station sharen, in de DFS gooien, testen maar.

Natuurlijk is het niet zo makkelijk als hierboven staat maar met de juiste documentatie en research kom je al een heel end.

De VPN verbinding die tussen de 2 sites ligt is niet echt snel.

Misschien kan je de servers laten repliceren en elke server zijn eigen DFS laten hebben? Zo heeft alleen de server last van connectie problemen en kunnen de gebruikers zonder steeds de verbinding te verliezen rustig door blijven werken.

Het fijne weet ik er niet van maar het is het proberen waard lijkt me.

[akimosan]

Let wel op bij grote bestanden en slow links.

Als er een trage verbinding is (en blijft) en er worden regelmatig grote bestanden op de share gezet dan moeten deze grote bestanden dus ook repliceren. Dan kan het lang duren voordat data op de andere site/server beschikbaar is.

Je kunt dit wat afvangen door verschillende replication groups te maken met verschillende replicatie schema's anders worden kleinere bestanden op een gegeven moment niet gerepliceerd omdat de queue nog vol staat met de grotere bestanden.

[citruspers]

Tot nu toe bedankt heren!

Mijn plan is om beide servers te voorzien van DFS, zodat ik dus redundantie heb, maar ook on-site caching. Als de server op 1 locatie faalt zouden de shares automatisch een failover moeten doen naar de server op de andere site. Toegang met minder bandbreedte is altijd beter dan helemaal geen toegang

Wat betreft snelheid: Ik was van plan een QoS schema'tje toe te passen op beide VPN routers, en verder remote differential compression in te schakelen zodat het bandbreedtegebruik binnen de perken blijft. Verder zullen er geen gigantisch grote bestanden op worden gezet, en de 2e site is dermate ver weg dat de bestanden waarschijnlijk al gerepliceerd zijn voordat een medewerker van locatie kan wisselen

Maar verschillende replicatie groups hou ik in gedachten mocht er toch meer data over de link gaan dan verwacht

[Question Mark]

Klinkt alsof je er goed over nagedacht hebt.

Complimenten overig voor je topicstart en hetgeen je doet met de gekregen feedback. Ik kan merken dat je ook daadwerkelijk wat doet met de gegeven steekwoorden. Erg prettig voor de mensen die reageren in dit topic.

[citruspers]

Update:

Inmiddels draait het systeem heerlijk in productie met DFS, synchroniseert alles netjes en op tijd, en werkt de failover ook naar behoren. Snelheid is nog geen probleem gebleken maar ik heb wel voor de zekerheid ook meteen remote differential compression geimplementeerd.

Iedereen bedankt voor de hulp