[W2K3] File Replication en File Locks

[Zoetjuh]

(jaja, daar heb je die Zoetjuh weer )

In Windows 2003 (en 2000) vinden we het nuttige DFS (Distributed File System), zodat shares op domeinniveau gemaakt kunnen worden en kunnen verwijzen naar shares op willekeurige werkstations/servers.

Icm FRS (File Replication Service) is het met W2K(3) servers mogelijk om deze files nog eens te repliceren via een "last writer wins" algoritme. Het probleem is echter dat FRS (voor zover ik gelezen heb, begrijp en in de praktijk tests hier heb gezien) een "ge-sceduled" systeem is en zodoende geen filelocks doet over de verschillende kopieën (replica's) van een bestand.

Heeft iemand een idee of:
- Of/hoe dit mogelijk is?
- Of hier 3rd party tools voor zijn?
- Wat het beste alternatief is?

Ben zeer benieuwd...

[Question Mark]

FRS gebruikt een "staging" folder (hidden) hierin wordt een kopie van de te repliceren bestanden geplaatst en op moment van replicatie (volgens schema) worden de kopieen van de bestanden gerepliceerd. Dit voorkomt het in gebruik zijn van de te repliceren bestanden.

Kleine quote van de MS site:

"The FRS staging folder is a temporary store for files that are replicated to downstream partners of Sysvol or DFS replica sets. Files in the FRS staging folder may consume disk space up to the limit that is assigned in the Staging Space Limit in KB REG_DWORD registry value. The default value is 660 megabytes (MB), or up to the amount of free disk space that is available on the hosting drive, whichever is less. If the staging area becomes full, the FRS service stops functioning"

Verder begrijp ik je vraag niet helemaal, je wil dat weg te repliceren bestanden gelocked worden voor gebruikers?

[ Voor 45% gewijzigd door Question Mark op 15-05-2004 16:44 . Reden: typo ]

[Monkeybrains]

Bij een klant van ons gebruiken wij het om data tussen twee servers te synchroniseren.

Op een gegeven moment kwam de klant er achter dat wanneer gebruiker 1 een bestand opende, en vervolgens een andere gebruiker ook dit bestand opende, dat de wijzigingen van de gebruiker die als laatste het bestand opsloeg bewaard bleven.

Dit hebben we uiteindelijk opgelost door referal maar voor 1 target van de dfs share aan te zetten. Dan werkt het file locking weer, maar synchroniseert Windows de boel wel.

[Zoetjuh]

Gaat inderdaad om het locken van bestanden zoals Monkeybrians dat ook noemt.. Ik had alleen gehoopt dat DFS/FRS een optie zou hebben om, wanneer een file op server-A wordt bewerkt; dat DFS/FRS op server-B de file ook zou locken, om te voorkomen dat er dus twee versies tegelijk worden geopend...

Ik ken de staging area inderdaad. Hier worden meen ik ook CRC/HASH checks gedaan etc voordat de file daadwerkelijk word "geaccepteerd".

Ik zit hier alleen met het punt dat de files op twee lokaties komen (via een vpn-tunnel over internet met elkaar verbonden netwerken), waarbij ik dus zou willen/hopen dat ik ook nog eens in kon stellen op welke IPs welke links als default genomen zouden worden (aangezien het ook om laptops gaat; IP based). Zodat ik aan beide kanten de clients naar het "lokale" deel van de DFS kan verwijzen en dat FRS verder voor locking en replicatie zou zorgen

[ Voor 9% gewijzigd door Zoetjuh op 15-05-2004 18:11 ]

[Made4U]

@Zoetjuh
Volgens mij is het mogelijk wat jij zegt. Als je de verschillende servers in verschillende AD Sites zet, en deze sites via een "slow"-link met elkaar verbindt, moeten de clients vanzelf de snelste server pakken.
Dit is in ieder geval in theorie volgens Microsoft mogelijk. De precieze configuratie weet ik echter niet.

[relaxteb]

Wij hebben hier het zelfde probleem.
2 servers over een vpn met identieke shares waar de data van de klant op staat.
Deze zijn via dfs gekoppeld zodat er replicatie plaats vind.

Wat ik heb begrepen is dat je via dfs referal een "lokatie" uit zet zodat alle verzoeken naar 1 share gaan als je via de dfs verbinding maakt. Echter loopt de bandbreedte van het vpn dan vol lijkt me omdat alle file request dus naar 1 server gaan. En dat willen we juist dus niet.

Ik wil dus dat wanneer er op 1 lokatie een file geopend wordt deze op de andere lokatie niet te openen is dmv een lock oid.
Want anders krijg je dus wat hier boven al gemeld wordt als er 2 man een zelfde bestand openen.

Is hier een oplossing voor ??

groetjes

sebas

[Verwijderd]

Ook hier hetzelfde probleem. Als je naar de DFS / FRS artikelen op Microsoft kijkt, dan zie je verborgen tussen de regels door dat Microsoft dit meer ziet om statische bestanden te synchroniseren dan dynamische gegevens zoals userdata.

Wat ook optreedt en nog steeds niet verholpen is, betreft de "by design werking van FRS". Als je bestanden hebt van een redelijke omvang, die je constant bijwerkt, slaagt FRS er nooit in om de replicatie te voltooien (LET OP: FRS Repliceert volledige bestanden, geen delta's/wijzigingen!!!!!). De Staging FOlder loopt vol met steeds nieuwe versies van de bestanden en uitendelijk is het gewoon einde verhaal.

Ik he ooit geprobeerd een soort failover te realiseren. Meze door bovenstaand probleem (het achterblijven van de replicatie bij regalmatig wijzigen van (grotere) bestanden, ging de hele strategie mis.

Ook het locking probleem is iets waar Microsoft nog steeds geen oplossing voor heeft. Je kunt rustig met zi'n tweenen hetzelfde bestand openen, terwijl dit niet correct wordt doorgestuurd aan het OS. Best wel waardeloos eigenlijk.

[Verwijderd]

Voor de geïntresseerden, dit is een discussie die wij hadden met een support rep van Microsoft: (ik heb er wel wat interne informatie uitgeknipt, maar het verhaal is nog wel consistent)

------------------------
The Windows File Replication Service (FRS) is best suited to replicate
files that are static and do not change frequently. If a change is made
to a file it will cause the entire file (and not just the change) to be
copied around all servers in the replica set. Various things trigger
these file copies including renaming, modifying the data, changing the
security, the time stamp etc.

We do not recommend using FRS to replicate user profiles and home
directories as these tend to change a lot and can cause excessive
replication. Organisations should only implement FRS if they have the
staff, the time, and expertise to monitor the event logs, data logs and
data consistency on a daily basis. We are not saying that it won't work
but from our experience it can cause problems. It may work for a period
of time but it is possible that during an especially busy period or when
more data and users are added to the network that the replication will
not be able to keep up and you will encounter problems.

Some Virus scanning products also cause issues with FRS as they modify
the security or time stamp of the files. This results in all the files
replicating.

I understand your reasons for replicating this data was for backup
purposes. If your requirements are that you have a backup copy of user
profile and home directory data then consider using robocopy.exe to
perform a file copy every night. Although this may seem like a simple
solution it would meet your redundancy requirements and would avoid
problems with FRS such as duplicate files (See Microsoft
http://support.microsoft....aspx?scid=kb;en-us;328492
Knowledge Base Article - 328492 ), "mysterious" file deletions, FRS
failing to replicate (which is needed to for Group Policy / Logon
scripts), journal wrap errors due to an excessive backlog etc etc.
-----------------------------------

Dus... DFS, ja!!!! Geweldig!!! Zeker doen!!!!! Maar probeer het niet te repliceren via standaard Windows FRS. Wil je dit wel dan zijn hier producten van bijvoorbeeld Veritas voor nodig. Maar deze kosten nogal een duit.
Zie link: http://www.veritas.com/Products/www?c=product&refId=50

[ Voor 28% gewijzigd door Verwijderd op 14-06-2004 16:14 ]