[Gluster-users] gluster ha/replication/disaster recover(dr translator) wish list

[Keith Freedman]

At 09:32 AM 1/27/2009, Prabhu Ramachandran wrote:
>On 01/27/09 02:21, Keith Freedman wrote:
>>At 10:36 AM 1/26/2009, Prabhu Ramachandran wrote:
>>I dont see any problems with your config.
>>other than, if your network connection is very sporadic, then 
>>you'll be caught often by waiting for timeouts which will make 
>>things seem slower.
>
>Network connection isn't usually a problem but when the network does 
>go it could be gone for a while.  In the worst case could I 
>temporarily disable the replicate/AFR feature?

you wont need to.  it'll know that the other replica is down and will 
continue working without it, then will auto-heal when it comes back up.

so there should be no need to change your configuratoin, unless you 
hate seeing all the connection down messages in your logfile.

>>What you seem to want is for gluster to serve local files 
>>instantly, but it can't because in HA mode, it needs to know that 
>>either the replica is down, or that is has the most current 
>>version.  if your network is spotty, then it will constanly be 
>>waiting to decide that the network is down before continuing on, 
>>that's likely the concern that was raised earlier.
>>but if it's more likely that the network will be down for a while 
>>then up for a while, then it's not a big deal and you should be just fine.
>
>I could use this option:
>
>read-subvolume (default: none)
>
>This might actually be the best solution in this case.  I could have 
>each client only read files from the local subvolume and sync the 
>writes when that happens.  There will be a problem with any writes 
>though but I might just have to live with that or disable AFR for a while.

in any case where the client and server are the same machine (which 
is my configuration), It only makes sense to use read-subvolume.

you would also use it if you have disparity among your server 
capabilities, for example:
if server A has a faster network connection or generally faster disk, 
then it would make sense to prefer server A for reads.

Theoretically, you could have a DR server across an ocean so you 
would definitely not want to have round-robin reads across that.

hopefully in a future version we will have the option of specifying 
multiple read-subvolumes:
imagine the case of a distributed web farm... you may want to 
replicate the data across dozens of boxes spread across many data 
centers, and you want to make sure they read locally from the 
fileservers local to that data center.  You'd have a tiny bit of 
overhead for Replicate to insure the latest version is local, but 
then you're at local speed, otherwise, your entire web farm would be 
running at WAN speed which would not be desirable.

>Thanks for all the clarifications and your patience!
>
>cheers,
>prabhu