RE: {bb} Cluster-aware processes?

["Kit Gerrits" <kitgerrits@gmail.com>]

Greg,
 
Thanks for the tip!
 
I'm still analyzing your example-script at the moment.
>From what I can tell, the package-based hostname is not installed on the
system the way the script looks at it.
(that's no real problem)
 
After that the script manages to pull the package status out of cmviewcl.
 (I was working on a similar system)
 
My problem is, that not all required processes are defines in the cluster
configuration.
The, ehm, supplier provided a minimal Cluster Configuration, where an
internal watchdog monitors the processes.
90% of the processes could be down and cmviewcl still shows the package as
up and running (quite literally).
 
 
Is there any way to provide the functionality of bb-proc based on the, ehm,
designated cluster node?
(if the current node is the designated node for a package, a certain set of
processes are supposed to be running)
 
 
Thank you for your time!
 
 
Kit Gerrits
 
 


________________________________

	From: Greg Martin [mailto:Greg.Martin@SPARROW.ORG] 
	Sent: donderdag 12 april 2007 19:52
	To: bb@bb4.com; kitgerrits@gmail.com
	Subject: Re: {bb} Cluster-aware processes?
	
	
	Kit - 
	 
	Don't try to include your critical processes in the generic proc
test, but  use a BB external script on the client.
	 
	Use cmviewcl to determine whether the package is running and whether
it is running on the current host.
	 
	If running on the current host, check for the process(es) you want
to check for.  
	 
	Combine or use as many individual test reports as you want to report
cluster status, whether and 
	where the package is running, and application processes and
dependencies.  (Send to server using bb command.)
	
	>>> kitgerrits@gmail.com 4/12/2007 12:18:31 PM >>>
	

	Hello all!
	
	I'm currently using BB 1.9 to monitor a fair number of servers.
	Some of these servers happen form a cluster, where processes move
around a
	lot.
	If a cluster application switches to another node, 
	  the corresponding processes are no longer running on the default
host, 
	  which causes BB to issue a warning.
	
	
	I'd like to have BB recognise the fact that the cluster has switched
and
	that the processes are no longer required to run on that specific
system.
	For instance: systems foo1 and foo2 host package foo and systems
bar1 and
	bar2 host package bar.
	(We also have a cluster where hosts foo1, foo2 and foo3 host
applications
	foo and bar on separate hosts)
	
	
	I have found 2 ways of accomplishing this:
	A/ changing the BB configuration with each cluster switch
	    This would involve replacing the configuration files on the
cluster
	node
	    and HUP'ing / restarting the BB process
	I would prefer not to do this, because 
	  A) this is a HP-UX system and I'm not very familiar with
MC/ServiceGuard
	and 
	  B) I don't trust the software supplier to keep his hands off the
cluster
	configuration script, undo-ing my bb hook
	  C) Messing with the cluster configuration may void any warranty on
the
	system.
	
	B/ use the hostname variable in the configuration file.
	    The cluster package associates with a specific address which can
be
	found in the 'hosts' file.
	    If the cluster package 'foo' is active on that node, the IP
	associated with hostname 'foo' is also active on that host.
	Is is possible to hook processes in the bb-proc file into the 'foo'
	hostname?
	Would BB notice the fact that the IP associated with that hostname
has been
	(de)activated 
	  and (de)activate monitoring of the related process?
	
	
	Thanks,
	
	Kit
	
	
	
	
	--
	
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=
	To unsubscribe from this list, or to subscribe to the bb-digest list
	send e-mail to mailto:majordomo@bb4.com with unsubscribe bb -and/or-
	subscribe bb-digest in the BODY of the message.
	


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=
To unsubscribe from this list, or to subscribe to the bb-digest list
send e-mail to mailto:majordomo@bb4.com with unsubscribe bb -and/or-
subscribe bb-digest in the BODY of the message.