Gluster users - Jun 2015 - geo-replication vs replicated volumes

On 10 June 2015 at 12:24, Gabriel Kuri <gkuri at ieee.org> wrote:
> I need some clarification on how geo-replication (gluster => 3.5)
> operates, as I'm not fully understanding how the new and improved
version
> works from the docs.
>
> Let's assume the following scenario, three servers setup in a geo-rep
> cluster all separated by a WAN:
>
> <server a> -- WAN -- <server b> -- WAN -- <server c>
>
> Does this scenario allow for a client with the a volume mounted to write
> to any of the servers directly and the write then gets replicated from that
> server to the other servers? For example, a client has the volume mounted
> (via FUSE) on server C and writes a file, does that file get written to
> server C directly and then the file replicates (asynchronously) to server A
> and server B ? Or is it that the writes only occur on the
"master" of that
> geo-rep volume? I'm trying to understand if the replication for geo-rep
> occurs in a master-master setup or if it's still master-slave ? What
was
> the big change for geo-rep in 3.5 ?
>
glusterfs doesn't support master-master yet. In your case, one of the
servers (A or B or C) should be a master and your client should write to
only that volume. Other two volumes should be read-only till volume in
server-A fails for some reason.

The big change in glusterfs-3.5 was the design of the geo-replication.
Earlier one single node in master volume was responsible for syncing data
to slave (which has lots of performance problems). So from > glusterfs-3.5,
the responsibility of syncing is shared across servers of volume in master.
>
> If it's not master-master, how does one get master-master replication
> working over a WAN?
>
AFAIK, there is no work around as of now, at least I am not aware of it

Best Regards,
Vishwanath

> Thanks ...
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20150610/f73f2fb1/attachment.html>

> glusterfs doesn't support master-master yet. In your case, one of the
servers (A or B or C) should be a master and your client should write to
only that volume.
> Other two volumes should be read-only till volume in server-A fails for
some reason.

So the writes from the client will go directly to whichever server is the
master, even though the client has mounted the volume on one of the slaves?
What about the reads, do they still hit the server (ie slave) the client is
connected to or do the reads hit the master as well?

In the case of geo-rep, how is split-brain handled? If the network is down
between server A (master) and server B (slave) and the client has mounted
to server B, I assume server B will then become the master and writes will
then be committed directly to server B, but if writes were also committed
to server A by other clients while the network was down, what happens when
the network is back up between server A and B, does it just figure out
which files had the most recent time stamp and commit those changes across
all the servers?
>> If it's not master-master, how does one get master-master
replication
working over a WAN?
> AFAIK, there is no work around as of now, at least I am not aware of it
Does the basic replicated volume work in this fashion, reads and writes to
all servers? The only problem is it's meant for a low latency network
environment?

Thanks ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20150610/9590d2da/attachment.html>