[Linux-cluster] RHCS 4.0 HowTo?

[Lon Hohberger]

On Sun, 2005-09-18 at 19:40 -0500, David.Sullivan wrote:
> I'm completely new to clustering and am trying to set up a "proof of
> concept" configuration in-house.  Our customers run a back-office POS server
> and must currently do a manual failover that involves moving hard drives if
> the server fails.  Using VMware Workstation 5, I have created several VM's
> configured with dual NICs and RHEL 4.0/RHCS 4.0.  System-config-cluster
> seems to abstract so much from the Administrator that I'm having trouble
> getting things working.  Some specific things I don't understand:
> 
> *  How do you tell it which NIC to use as a heartbeat, and which to use for
> the services offered?  I have a private LAN set up that I want to use for
> heartbeat, but don't think it's being used at all.  Both the public and
> private IP's are set up in /etc/hosts.

With RHCS4, it goes by "uname -n".  An easy thing to do is to set up
dummy hostnames matching the IP on the private network and set your
hostnames to them.

e.g. 10.1.1.1 node1
     10.1.1.2 node2

...then set hostnames to node1 and node2.

Service IPs are (and have always been) selected based on matching
specified IPs to already existing IPs on NICs.  E.g. 192.168.2.10/24
would go on the same NIC as 192.168.2.1/24, even if it's a different
interface from what the cluster is using for internal communication.


> *  Building on the above, is it wise for other cluster services (e.g. dlm)
> to communicate across the private heartbeat link?  If so, how do I configure
> that?

I think DLM will use the private network, as will rgmanager, and
everything (except services).


> *  Insofar as hardware fencing is required with RHCS 4.0, will I be able to
> demonstrate failover functionality to management at all?  I'm basically
> looking for a means to automagically fail over to a "hot standby" server.

Automagically won't work (and is *dangerous*).  You'll have to use
manual fencing.  However, you could probably put together a fencing
agent which asked the VMWare server to power off a guest...

-- Lon