Replying back to list.
I don't know of a currently available clustered filesystem that allows
bi-directional asynchronous replication. Even in your case where you
can have manual curation, what would you want to happen when two humans
modify the same files at the same time in your two geographic locations?
And don't tell us it will never happen.
Synchronous replication works a bit differently everywhere, so you'll
just want to double-check which is most compatible with your workflow.
In glusterfs, the client talks to all replicas and returns when each
replica has confirmed it has written the data.
In ceph, the client talks to the master replica, and then that master
replica forwards the writes to all the other replicas, and then confirms
to the client that all the replicas are written.
For your async use case, how often does the shared data change? Perhaps
something like a plain rsync every night would be sufficient? Or a ZFS
send/receive if that's faster than rsync?
On 03/17/2014 02:58 PM, Carlos Capriotti wrote:
Being a little bit familiar with Brock's work environment, I think I can
clarify on this: they have a human, manual system of avoiding those
conflicts. Only one person/geographical group will use the files at a
given time.
All that matters then is being able to automate the replication/exchange
process, so, in this case, the question still needing an answer would
be, "is there a way to make geo-rep work both ways ?"
Sorry for taking point here, Brock. I thought this would speed up the
discussion a tad.
On Mon, Mar 17, 2014 at 7:23 PM, Alex Chekholko <chekh@xxxxxxxxxxxx
<mailto:chekh@xxxxxxxxxxxx>> wrote:
You're basically talking about running rsyncs in both directions.
How will you handle any file conflicts?
--
Alex Chekholko chekh@xxxxxxxxxxxx <mailto:chekh@xxxxxxxxxxxx>
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users
