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://gluster.org/pipermail/gluster-users/attachments/20120105/ec1baa3a/attachment.htm>
