[Gluster-devel] Architecture advice

Harald Stürzebecher haralds at cs.tu-berlin.de
Sat Jan 10 11:29:48 UTC 2009


2009/1/10 Basavanagowda Kanur <gowda at zresearch.com>:
>
>
> On Fri, Jan 9, 2009 at 3:22 PM, Daniel Maher <dma+gluster at witbe.net> wrote:
>>
>> Krishna Srinivas wrote:
>>
>>> Daniel,
>>> Imagine 2 servers afred with each other. On the client side you
>>> configure HA translator with its subvols as the afrs on the two
>>> servers. (Previously we used DNS round robin system) If 1st server
>>> goes down, the HA translator will continue working with the second afr
>>> and this failover happens seamlessly.

[...snip...]

>> I am curious to know how the client decides which of the subvols to use at
>> any given time, and if there is a way to specify a "preferred" subvol.  For
>> example, i have two servers AFR'ing each other.  I have two clients set up
>> to access the AFR cluster via HA.  For reasons of resource distribution, i
>> would like Client01 to prefer to use Server01, and Client02 to prefer to use
>> Server02.
>
> currently HA does not provide facility for specifying this option.

If the HA translator would always try the subvolumes in the specified
order, using "server01, server02" for the first client and "server02,
server01" for the second client would behave like a simple load
balancer.
If it would choose randomly for each file, that would work, too.

IMHO, adding options to use some preferred server instead of choosing
randomly or using a predefined order might lead to user confusion when
trying to choose the right options. ;-)
I had that problem with the "unify" translator and its schedulers on
my first setup. It works now like I wanted it to, but sometimes I
still have doubts that all the options are correct.

Maybe a "loadbalancer" translator is needed here, as its goals might
be different from "high availability".

IMHO, the "high availability" translator should be kept simple (in
code and configuration) to reduce errors and just do "high
availability". If that results in loadbalancing, that would be fine,
too.


Harald Stürzebecher





More information about the Gluster-devel mailing list