[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] Architecture advice

From: Gordan Bobic
Subject: Re: [Gluster-devel] Architecture advice
Date: Mon, 12 Jan 2009 17:17:22 +0000

On Mon 12/01/09 13:32 , Daniel Maher <address@hidden> wrote:
> Gordan Bobic wrote:
> >> How does the HA translator choose a node, exactly ?  Does it
> randomly 
> >> select one from the list of available subvolumes, or does it pick
> them 
> >> in the order they're specified in the config file, or some other
> way 
> >> entirely ?
> > 
> > Not sure what the default is, but you can specify a preferred read
> > server (writes have to go to all servers regardless) with
> > "option read-subvolume" in the volume spec.
> option read-subvolume is available only in the AFR translator, and
> if 
> AFR is being done on server-side (the scenario noted previously in
> this 
> thread), then there would be no AFR declaration in the client spec
> file, 
> and thus no way to set the read-subvolume option.

Not on the client, anyway. But if you're AFR-ing on server side, then your 
client always talks to one server anyway. The traditional way to handle server 
failure in that case is to set up Heartbeat or RHCS to fail over the IP address 
resource to the surviving server.

The TCP connection will reset when the fail-over occurs - I'm not sure how 
gracefully/transparently GlusterFS reconnects.

> The HA translator is not that useful in the context of a
> straightforward 
> client-side AFR setup in any case, since (as i understand it) if a
> given 
> server dies, the client continues to interact with the remaining
> defined 
> servers seamlessly.  This, of course, is part of the attraction of 
> defining AFR on the cleint side ; but in cases where it is not
> feasible 
> (overhead concerns, etc...), using HA with server-side AFR is a very
> interesting prospect.

I wasn't aware of there being a HA translator built into GlusterFS, but unless 
you have proper fencing in place, failing over IP addresses won't work. Without 
proper cluster fencing in place you can easily find yourself in a split-brain 
situation where both servers think they have the same IP address and neither 
can talk to any of the clients.

> Some way to extend simplistic load-balancing features to the HA 
> translator (or, perhaps, another translator working in concert)
> would therefore be quite ideal.

I think you're trying to use a wrong tool for the job. Look into something like 
RedHat Cluster Server.

---- Msg sent via @Mail -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]