Hi,
What I understand from the scenario you are talking about is that you want
to achieve active/active geo-replication which is a proposed feature
internally & will be coming soon. :-)
On Wed, Jan 4, 2012 at 3:00 AM, Giovanni Toraldo <gt at libersoft.it>
wrote:
> Hi,
>
> I was thinking about a common (I hope!) use case of Glusterfs
> geo-replication.
>
> Imagine 3 different facility having their own glusterfs deployment:
> * central-office
> * remote-office1
> * remote-office2
>
> Every client mount their local glusterfs deployment and write files
> (i.e.: user A deposit a PDF document on remote-office2), and it get
> replicated to the central-office glusterfs volume as soon as possibile
> using geo-replication feature. After a while, that PDF document should
> be replicated to remote-office1 using geo-replication feature.
> Hopefully an user B on remote-office1 should be able to upload new
> files that get replicated to central-office and remote-office2 too.
>
> In short, this is the scenario I would like to achieve with GlusterFS
> geo-replication:
> remote-office1 <--> central-office <--> remote-office2
>
> Obviously, it's possible to create an unique volume among all
> facilities, but they are connected with 2mbits HDSL and we don't want
> that user applications get stuck if the network is saturated or
> unreliable.
>
> Does this scenario is feasible?
>
> Every suggestion is highly appreciated, thanks!
>
> --
> Giovanni Toraldo - LiberSoft
> http://www.libersoft.it
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>
--
Regards,
Rahul C S
Engineer @ Gluster.
Ph: +919591407901
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20120105/ec1baa3a/attachment.html>