[hobbit] Virtual hosts, floating IPs, clustering

David Gore David.Gore at mci.com
Sun Aug 14 21:21:20 CEST 2005


I believe you are referencing 5.x clustering which is quite a bit 
different, i.e. much better than 4.x clustering or at least so I am 
told.  4.x clusters have one primary and 1 dedicated failover.  We have 
4 node clusters.  So we have one service each running on each of the 3 
hosts, and 1 dedicated failover host.  If 1 service fails it will run on 
the failover host.  If 2 services fail, then you are in trouble because 
it will try to run on the failover host as well.

Each service can only run on one of two hosts, it's home host and the 
failover.  Although each host in the cluster does have common processes 
(the same name and function), the service has a list of processes, it 
runs specific to the service.  So when the service fails and moves to a 
different server (the failover host), I have to accomodate for that. 
The file systems although very similar, if not identical, they do have 
differnent names.

It will look like this:

host1(host-ip1) service1(service1-ip) host-procs disk-fs service1-procs 

host2(host-ip2) service2(service2-ip) host-procs disk-fs service2-procs 

host3(host-ip3) service3(service3-ip) host-procs disk-fs service3-procs 

host4(host-ip4) host-procs disk-fs

So it's easy to report for host1-4, and host-procs and disk-fs and it 
would be easy to report for the services, if they never failed and 
stayed on the same host.

It's when the service fails and it's procs and filesystems are no longer 
running on the host that was originally reporting those procs and 
filesytems, that is a problem.  And then again, when it is failed back. 
  That is why I report the service (host) and physical (host) as two 
hosts on Hobbit and why I will have some duplication.

What I have done is to modify runclient.sh to determine, if the host is 
running a service and to start a second copy of hobbitlaunch.  I have 
also modified the hobbitlaunch to go to hostname specific, PID files, 
and CFG files.  I also have 2 entries in bb-hosts for each server, 1 for 
the physical host and 1 for the service host.  I will check every 10 
minutes via cron, to make sure hobbitlaunch is running and whether it 
should be running 1 copy of hobbitlaunch (failover host) or 2 copies (1 
for the physical host and 1 for the service).

I do not know if this is the best way to handle my situation or not, but 
it should work.

David Gore (v965-3670)
Enhanced Technology Support (ETS)
Network Management Systems (NMS)
IMPACT Transport Team Lead - SCSA, SCNA
Page: 1-800-PAG-eMCI pin 1406090
Vnet: 965-3676

Anton Burkhalter wrote:
> Hi David,
> What is the reason to report CPU and MEM status for a virtual IP?
> These are information’s about real machines with real IP addresses. But 
> there are other information’s which should be reported just ones per 
> cluster. For example on a Tru64 cluster, the file system is the same on 
> all members. It makes sense to send file status information just ones to 
> the Hobbit server, using the DEFAULT cluster alias name as the 
> originator. The client script can run on every member, but only one 
> member will send the status.
> Here is a snipplet for such a situation:
> ------------------o<----------------------------------------
> ### ++ Execute the script on the CFS serving node only on cluster members
> if [ -x /usr/sbin/cfsmgr ]; then
> set -- $(/usr/sbin/cfsmgr -F raw /)
> shift 12
> if [ ! "$1" = "$(/bin/hostname -s)" ]; then
> exit 0
> else
> MyAGENT=`/usr/sbin/cluamgr -s DEFAULTALIAS | head -2 | tail -1 | awk 
> '{print $5}' | sed "s/\./,/g"`
> MyAGENT=`echo ${MyAGENT}.${MyFCT}"`
> fi
> else
> MyAGENT=`hostname | sed "s/\./,/g"`
> MyAGENT=`echo ${MyAGENT}.${MyFCT}"`
> fi
> ### --
> ------------------o<----------------------------------------
> Regards,
> Toni
> To unsubscribe from the hobbit list, send an e-mail to
> hobbit-unsubscribe at hswn.dk

More information about the Xymon mailing list