That's pretty much it - except that this started as an HACMP 2.1 cluster and keeps getting upgraded as it moves to new hardware - so we're still doing IPAT and don't have either a persistent IP address or IP aliasing to keep the boot address around.

I get more time to look at this next week - right now I've got a ton and a half (7.6 TB) of disk data to schlep around; I also wear the storage admin (and, for that matter, the TSM admin) hat here and we've a model 800 ESS being replaced by a DS-8100 over the next 5 days.

I just wanted to kick the question off and start some ideas floating around internally.

Thanks!

Tom

From: timothy Myers [mailto:timcarol at gmail.com] Sent: Thursday, April 27, 2006 1:39 PM To: hobbit at hswn.dk Subject: Re: [hobbit] I'm starting to look at setting up 'propr' monitoring for my production SAP environment, and wonder if anyone else is playing with HACMP clusters

If I understand what you are getting at, you will want to setup where the resource groups with the resource groups ID as a server. Then you set up a persistent IP - ( if your running HACMP 5.x this is standard) that you use for each LPAR. Then in you resource startup you enable reporting ( you will need to spoof you hostname on the reports) and in you resource shutdown scripts disable the reporting for this resource although you may want to send a report that you are going down to Hobbit this could be a custom report of status on your screen. The node up and down could spawn updates along with the hacmp.out log file or a subset. You could also make your reporting HACMP aware and they could run all the time but only report if they own the resource group. You also have advance event monitoring within HACMP that could spawn a report based on an event in real time.

On 4/27/06, Kauffman, Tom <KauffmanT at nibco.com> wrote:

I need to split the monitoring for SAP and Oracle from the monitoring of the host it runs on -- because, in an IBM HACMP environment, the workload can move. So the oracle tests, *some* of the disk space tests, and *some* of the proc tests move from one box to another.

So does the primary IP address.

I need to be able to track 'colorado' the box (the hostname does NOT move) as well as 'colorado' the IP address. 'Colorado' the address could actually be pointing to the 'thames' or 'yukon' boxes. At which time, 'colorado' the box will be responding to the 'colorado-bt' adapter address (if 'colorado' the box is up at all).

I can get some of what I want by running two clients, one for 'colorado' the box, and one for 'SAP' or some other such synthetic name. The biggest two challenges I see are splitting the OS filesystems from the application filesystems for freespace reporting, and the shifting IP address. I may have an 'out' on the IP address in the future, if I can migrate to what IBM calls 'aliasing' -- where they add the running address as a second address on the adapter and respond to both.

And to make this a bit more fun, I have THREE of these silly environments to work with.

Henrik, is there any way to hang two different IP addresses on the same bb-host entry such that the network connectivity test will be happy if either one responds? They are always on the same IP network, just different host addresses (our convention is to add 100 to the last octet to get the boot-time address for the matching run-time address).

Is anyone else doing something silly like this?

TIA

Tom Kauffman NIBCO, Inc CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in

reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message.

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive
attorney-client or work product privilege by the transmission of this message.