[Linux-cluster] urgenet question about ClusterSuit

[gwood at dragonhold.org]

> As I have studied mannuals of clustersuit , it seems
> that there is only one service up in each
> clustersystems , my question is we this high number of
> users How can I rely just on one servers , I know that
> another server in failoverdomain comesup incase of
> first server failure , but what about load balancing?
Load balancing is actually a totally different issue to the HA side of the
cluster.  You are probably best using GFS to provide shared access to the
SAN, and then just running local copies of the apps on each machine -
since you don't want the applications to failover to other servers and
instead just stay where they are.

> I have studied about pirnaha for IP load balancing but
> it seems that I can not use GFS with Pirnaha?
Depending on budget & expertise within your company, I think it would
probably be easiest to use a pair of hardware load balancers in this case
- since that way you can get things like session affinity very easily.  If
you'd rather stick with a Linux solution throughout, then piranha is
probably the most appropriate (unless you want to just configure LVS
yourself).

I've only just quickly looked through the docs on the redhat site, and it
looks like the piranha configuration can be totally separate to the
application servers - the 'real' servers don't even need to be Linux if
you need to run something else behind it... So using GFS/clustering on the
application servers and piranha on the front end servers should work
fine...

However, you /might/ get better performance by using an active/passive
configuration of machines attached to the SAN and other applications using
NFS - depending on the usage of the data & locking performance of GFS

(e.g. You could setup an HA NFS system using cluster suite and 2 nodes
such that one shares out web pages and the other shares out mailboxes -
but that they can each do both if the other fails.  Then all the
application servers can mount the NFS share and use that with possibly
faster response times)