Incredibly annoying discovery problem

[Mikael Rönnbäck]

Is there ANY way to successfully PREVENT discovery of a cluster but still be able to manage the actual server node ?

I've now tried unsuccessfully including help from my local HP support to prevent this problem: Whenever any of my Exchange clusters fail over from node A to node B, SIM goes bananas and just renames the nodes so that instead of server A, B, C and D, I will end up with server A, A, A and D.

This does not look very well when one or more nodes goes down and SIM still shows everything as green and happy, I simply have to prevent it from changing the names.

I have tried exclude lists in SIM, I have tried IP filtering in the SMH agents, and I have tried "prevent discovery from chaning the server name" in SIM-node-properties.
No effect, the names are still being changed "randomly".

What if I disable the HP cluster agents ?
Could this solve the MSCS cluster issues ?
What about Veritas clusters (that HP agents cannot detect but the servers still changes names when the IP adress changes) ?

Is there any way to just detect the dedicated IP adress, discover the name from that and then prevent any change to that name and IP on a specific node entry in SIM ?

Please help since this is getting enourmously frustrating having to delete 80 servers and rediscovering them every other week, not to mention it takes quite some performance from the server during which SIM is quite slow for all users.

[Daniel Leblanc]

Just remove CLUSTERING INFORMATION in you re HP AGENT on you re server that you do not want it to discover the clustering.

Do not ferget to apply you re point, TY

[Mikael Rönnbäck]

Thanks but as I said, that only affects MSCS clusters since the HP agents atm doesn't support Veritas clusters and we have the same problem there so I'm really looking for something a bit more permanent.

[Mikael Rönnbäck]

Happened again, had to delete all machines and rediscover. Removing the cluster agents have absolutely no effect at all.

[Aravindh Rajaram]

Just remove the cluster IP address (the IP address in which the cluster service is hosted) during the discovery. Add the IP addresses of Node A, Node B, Node C and Node D and discover them. You can manage them as normal servers.

[Mikael Rönnbäck]

Thanks, I'll give it another try and see what it comes down to although I do believe I've tried doing that too on some of the machines without success, but I'll make sure to do it now just to have that option done from my list.

However, would you happen to know if excluding the address from auto-discovery also affects data collection ? Since I'm not sure that it is just the discovery task doing this. But we'll see.

Still a heck of a job, finding and excluding some 100-150 different IP adresses manually, but oh well, if it does the job...

I think I'll start with two of the clusters to test first :)

[Aravindh Rajaram]

Excluding the address from auto-discovery does not affect data collection. I personally was successful in monitoring just the nodes of the cluster (as normal servers).

[Mikael Rönnbäck]

Well, it does not seem to solve it completely, my Exchange clusters at least does not seem to change names now, however those are only 30 servers, the remaning 40 are Veritas clusters and they still switch names and IP adresses with each other so that you may think you see the correct server responding but when you look behind the name in the query-view you find out that it is actually a completely different node that is responding.

[Aravindh Rajaram]

Make sure that all the 40 nodes (part of veritas cluters) are having unique GUID's. If they have the same GUID's then there is a possibility that you end up with this issue. GUID's will NOT be unique if you would have opted for image based deployment for those servers.

[Mikael Rönnbäck]

They are definitively unique, we do not use image based installation but thanks anyway ;)