To: | nv-l@lists.us.ibm.com |
---|---|
Subject: | Re: [nv-l] [NV-L]: Status Polling Public Addresses on MSCS Clusters |
From: | Stephen Hochstetler <shochste@us.ibm.com> |
Date: | Fri, 17 Mar 2006 14:29:07 -0600 |
Delivery-date: | Fri, 17 Mar 2006 20:29:42 +0000 |
Envelope-to: | nv-l-archive@lists.skills-1st.co.uk |
In-reply-to: | <s41ace8c.098@email.chop.edu> |
Reply-to: | nv-l@lists.us.ibm.com |
Sender: | owner-nv-l@lists.us.ibm.com |
Jon,
Sorry about that. My concerns at this point are more theoretical..... NV 714, FP4 MCSC Cluster - Microsoft Cluster, how almost all Microsoft High-Availability clusters get built. Think HACMP in AIX.... Active/Passive Configuration - IP address and shared resources managed by MSCS. When cluster 'fails over', IP address and shared resources are taken over by the passive node. In a successful failover, from NetView's perspective, The IP Address gets deleted from one Node object and added to another node object. The scenario I've been asked to solve is the unsuccessful failover, where the IP address gets deleted from one Node object but doesn't get added back to another node object. Just wanted to see if anyone else had solved the issue and would like to share....... Jon Austin Tivoli/Unix Administrator Information Systems Children's Hospital of Philadelphia 267-426-0433 austinj@email.chop.edu >>> jshanks@us.ibm.com 3/13/2006 3:00 PM >>> Jon, I cannot follow much of this. I wouldn't know an MSCS Cluster from my sainted aunt, nor what the failover process was supposed to be, complete or not. But I do know a little something about the StateCorrelation Engine (SCE) and how it plays a role in events sent from TEC, and even with that, I can't for the life follow what you mean by, > Doesn't look like SCE under NV->TEC adapter did anything to the events sent over to TEC. To have the SCE do something other than what it ships with by default, you'd have to write your own rules in xml, add them to the nvsbcrule.xml file, and unless the action you wanted was already defined in a current jar file in the ZCE_CLASSPATH, which lists those jars from /usr/OV/jars/ that provide functions for the SCE to execute, you'd have to provide a new jar as well, containing java code you wrote to do the job. Is that what you are doing? Not one customer in 500 is that ambitious, I think. We've never actually documented in NetView how you would do anything like that, since TEC owns the code and the APIs. So let's take a step back and you can start at the beginning about what's going on. What NetView platform? What version and release? What events are we talking about and how were they supposed to look when they got to TEC? What do you get instead? James Shanks Level 3 Support for Tivoli NetView for UNIX and Windows Tivoli Software / IBM Software Group "Jon Austin" <AUSTINJ@email.ch op.edu> To Sent by: <nv-l@lists.us.ibm.com> owner-nv-l@lists. cc us.ibm.com Subject [nv-l] [NV-L]: Status Polling 03/13/2006 11:14 Public Addresses on MSCS Clusters AM Please respond to nv-l@lists.us.ibm .com I'm building up a new (greenfield) NV environment and looking toward implementing as much 'automated' status polling as possible. NV is forwarding to TEC using the out-of-the-box TEC_ITS ruleset, rules, and such. For our Microsoft Clusters, I'm being asked by our architect to solve the problem of the unsuccessful cluster failover. In this scenario, let's take a simple two-node, active-passive configuration. Both nodes with proper SNMP configuration, and for fun, status polling is done via SNMP rather than ICMP. In the example, MSCS doesn't completely fail over to the a passive node for some reason, but both devices are still online via their primary interfaces, and can respond to SNMP GETs. In the scenario, the active has dropped it's cluster IP address, but it hasn't been assigned onto the passive node. In testing using nmdemandpoll to speed up the polling interval, I've seen for a successful failover, the TEC_ITS_INTERFACE_STATUS events come through from NV on the primary node for the interface deletions, but no events from NV on the passive node for inteface additions. An ovtopodump does show the interface object moved from active to passive. trapd.log shows the deletes and adds. Doesn't look like SCE under NV->TEC adapter did anything to the events sent over to TEC. Anyone care to share their thoughts on solving this particular scenario that doesn't make it harder to maintain NV.?? Jon Austin Tivoli/Unix Administrator Information Systems Children's Hospital of Philadelphia |
<Prev in Thread] | Current Thread | [Next in Thread> |
---|---|---|
|
Previous by Date: | Re: [nv-l] [NV-L]: Status Polling Public Addresses on MSCS Clusters, Jon Austin |
---|---|
Next by Date: | Re: [nv-l] [NV-L]: Status Polling Public Addresses on MSCS Clusters, Francois Le Hir |
Previous by Thread: | Re: [nv-l] [NV-L]: Status Polling Public Addresses on MSCS Clusters, Jon Austin |
Next by Thread: | Re: [nv-l] [NV-L]: Status Polling Public Addresses on MSCS Clusters, Francois Le Hir |
Indexes: | [Date] [Thread] [Top] [All Lists] |
Archive operated by Skills 1st Ltd
See also: The NetView Web