[Gluster-users] Gluster on fast and slow networks

[Adrian Revill]

I do have an idea how it could be worked round.

On each of the 10G servers run a special client that connects like a 
normal client, and has the normal configuration.
But this client exposes a server interface. This would mean the server 
client would appear as a server with the whole file system.

Then on the 1G (or wan) clients run a client that has a special 
translator that for reads would load balance its file reads across all 
the servers, but for writes would only write to one server at any time, 
but over all the writes would be load balanced across servers.
If this was configured to talk to the server clients, then any reads 
would be distributed across the servers as normal.
If a re-sync was triggered then it would be handled by the servers 
client on the 10G network, not the client on the 1G network.
Any write would be handled by one of the servers clients and would 
follow the normal layout pattern as defined in the servers clients vol file.





Vikas Gorur wrote:
> Adrian Revill wrote:
>> This is an edge case scenario, but one that I am worried about.
>>
>> Say you have 2 storage nodes as a mirror on a 10G network, and you 
>> write into a client mount also on the 10G network. Then data will be 
>> replicated by the client via the 10G network to the 2 servers.
>> If one server out of sync because it was off line, then any changes 
>> would be replicated by the client on the first read. which on the 10G 
>> network is not a problem.
>>
>> I add more clients that are on a 1G network.
>> Now if one of the servers is out of sync and the first read is on a 
>> 1G client then the data would be replicated via the 1G client. This 
>> would saturate the 1G link on the client and seriously effect its 
>> performance.
>>
>> Is there a work around/solution for this problem?
> The general idea of having "asynchronous" or delayed replication has 
> come up many times on this list.
> Such a feature would involve having a "master" and a "backup" copy of 
> each file, with the backup copy
> lagging behind the master by a few seconds or minutes. This would be 
> useful in the case you mentioned
> and also if you wanted the backup to be at a different location 
> reachable over WAN.
>
> However, we have currently not made any concrete plans about this 
> feature.
>
> Vikas
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________