[Gluster-devel] Architecture advice

[Gordan Bobic]

It just occurs to me that if you're using server-side AFR and want HA of servers, likely the best, fastest and most graceful way to achieve it is to have AFT GlusterFS on the servers and export the share via NFS/UDP. You'll need the patched fuse package to alow you to do this. If you're using NFS/UDP the failover when RHCS migrates the IP to the surviving server should be totally transparent (well, apart from a few seconds' delay while the cluster notices a server has died, fences it, migrates the IP, and ARP propagates).

If you want to load balance the servers between multiple clients, you have a floating IP on all the servers, and each set of clients connects to one server. If that server fails, another server will assume it's IP address and the clients can continue pretty seamlessly. When the dead server gets resurrected, RHCS will notice, and hand it's IP address back to it and it can pick up it's share of the load again. The only caveat is that all the locks held will become invalid when the server fails over. How important this is will depend on your application, but most solutions will have this problem.

Gordan

On Mon 12/01/09 13:32 , Daniel Maher <dma+gluster at witbe.net> 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.
> 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.
> Some way to extend simplistic load-balancing features to the HA 
> translator (or, perhaps, another translator working in concert)
> would 
> therefore be quite ideal.
> -- 
> Daniel Maher 
> 
> 
---- Msg sent via @Mail - http://atmail.com/