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

Re: [hobbit] Virtual hosts, floating IPs, clustering



Anton,

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 service2-fs

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

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

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