[Gluster-users] Again on GlusterFS and active/active WAN Replication

[Vijay Bellur]

On 02/13/2014 11:29 PM, Gionatan Danti wrote:
> Hi All,
> I have a few questions about GlusterFS used in active/active WAN-based
> replication scenarios.
>
> Let first start with a little ASCII chart:
>
> HQ Linux w/SMB share -> low speed link -> Remote Linux w/SMB share ->
> WIN7 clients
>
> In short I had to replicate a local server share on a remote Linux box,
> and I would like to use GlusterFS (pre-seeding the remote side to lessen
> first-sync bandwidth requirements). However, I realize that writes to my
> local fileserver will be slowed down by the fact that GlusterFS use
> synchronous replication between the two bricks.
>
> At first I thought to work-around this issue using tuning the
> write-behind behavior, but that seem to have no effect on replicated setup.

write-behind can help with write operations but the lookup preceding the 
write is sent out to all bricks today and hence that affects overall 
performance.

>
> So my questions are:
>
> 1) it is not possible to increase local write speed while concurrently
> issuing a background sync against my remote target?

Not as of today.

One possibility is to let local clients assume that the remote target is 
not reachable and hence all operations happen locally. self-heal-daemon 
can perform background syncs when they notice that there is a delta. 
Achieving this form of near synchronous replication will involve some 
amount of work. If the same file is updated from multiple sites, then 
there are chances of running into split-brains and we would need good 
conflict resolution mechanisms too.

>
> 2) in current 3.4.x branch, it is possible to use geo-replication for
> active/active setup (I bet no, but...)

The answer is no, however if you do not require all of your data in a 
single namespace, you can configure geo-replication over two volumes in 
different directions.

i.e vol1 (Site A) ==========> vol1 (Site B)

and

vol2 (Site B) =============> vol2 (Site A)

>
> 3) any advise of how to tune GlusterFS to suite this specific scenario?
>

Cannot readily think of anything that does not involve code changes.

Thanks,
Vijay