On 15/07/10 16:14, Daniel Pittman wrote:
Keep in mind that using rsync like that has absolutely *zero* conflict
resolution support, so you are inviting the data-loss fairy to visit when
there are concurrent modifications.
DRBD, meanwhile, is useless without a cluster file-system on top of it, since
you otherwise can't mount the data at both sites at the same time.
Sadly, I can't right now advise a better solution than these, however, since
it is the main problem I face in trying to bridge two data-centers and provide
coherent and sensible file access.
The best I can offer, right now, is xtreemfs[1] which will give you fair
performance but no local caching, so no disconnected operation.
Regards,
Daniel
Footnotes:
[1] http://www.xtreemfs.org/
We cant be the first people to come across this "branch office" scenario.
My goal is to have the branch office get a copy of all the files (think
MS office) without hitting performance at either end.
something like this rsync thing, with a distributed lock manager would
be the solution to 99% of the problem
The only problem I can see is if person A in Newcastle wants person B in
Sydney to look at their file, they press save and then person B opens it
before the lazy copy has moved it over, Perhaps maintain a write lock on
the file until its synched? with user definable behaviour in the case of
failure.
At the moment the branch office is going to be working over a VPN back
to the main office, with all the files etc sitting inside VM's, the
images of the VM's will get rsynced nightly.
Which all in all is a fairly craptacular solution to be honest.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
