nv-l
[Top] [All Lists]

Re: [nv-l] [NV-L]: Status Polling Public Addresses on MSCS Clusters

To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] [NV-L]: Status Polling Public Addresses on MSCS Clusters
From: Francois Le Hir <flehir@ca.ibm.com>
Date: Fri, 17 Mar 2006 16:05:40 -0500
Delivery-date: Fri, 17 Mar 2006 21:06:09 +0000
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <OF9C1B293A.6ACAEC08-ON86257134.00703528-86257134.007087B0@us.ibm.com>
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com



If that interface is configured in the seed file for HSRP, then Netview is
going to detect that it disappeared from one machine by doing an snmpget on
the hostname and seeing that it's different than what it was before. My
understanding is that at this point it is going to take the following
actions:
- It will delete the interface from the server where it disappeared
- it will create a temporary new node with that interface and query it with
snmp to get a list of interface
- it will detect that some of theses ip in the list of interface, already
exist in another node
- at that point it will merge the temporary node with the existing node so
that we end up with the IP in the new server.

For this to work, of course it is necessary that:
- The IP is configured in the seed file with the '%' prefix
- The IP, (on both servers) is able to respond to an snmp query. That means
that both servers have snmp enabled.
- The community string must be known by Netview for the name that this ip
resolve to. (ie it's preferable if it is the same community string on both
servers)
- The hostname must be different on the two servers (so that netview will
detect that the IP changed from one to the other)
- The name resolution of the IP must be unique (ie different than the name
of the two servers)

All this was designed to work with HSRP interfaces (in cisco routers).
However it works the same way with other types of clustering (VRRP, HACMP,
and probably also Microsoft clusters.)

Salutations, / Regards,

Francois Le Hir
Network Projects & Consulting Services
IBM Global Services
Phone: (514) 964 2145


                                                                           
             Stephen                                                       
             Hochstetler                                                   
             <shochste@us.ibm.                                          To 
             com>                      nv-l@lists.us.ibm.com               
             Sent by:                                                   cc 
             owner-nv-l@lists.                                             
             us.ibm.com                                            Subject 
                                       Re: [nv-l] [NV-L]: Status Polling   
                                       Public Addresses on MSCS            
             03/17/2006 03:29          Clusters                            
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             nv-l@lists.us.ibm                                             
                   .com                                                    
                                                                           
                                                                           




Jon,

I don't think that in NV it would be deleted. The interface would simply go
Red in an unsuccessful failover. Just because an interface is no longer
found in a reading of the MIB does not cause NV to remove an interface. If
I am wrong, someone just needs to tell me. :-) Usually an interface has to
be unreachable for a predetermined time period before the cleanup routine
removes it.

Stephen Hochstetler shochste@us.ibm.com
International Technical Support Organization at IBM
Office - 512-838-6198 (t/l 678) FAX - 512-838-6931
http://www.redbooks.ibm.com
(Embedded image moved to file: pic17622.gif)Inactive hide details for "Jon
Austin" <AUSTINJ@email.chop.edu>"Jon Austin" <AUSTINJ@email.chop.edu>

                                                                           
                         "Jon Austin"                                      
                         <AUSTINJ@ema                                      
                         il.chop.edu>                                      
                                      (Embedded image moved to file:       
                         Sent by:     pic14890.gif)                        
                         owner-nv-l@l                                   To 
                         ists.us.ibm.         (Embedded image moved to     
                         com                  file: pic10883.gif)          
                                              <nv-l@lists.us.ibm.com>      
                                      (Embedded image moved to file:       
                         03/17/2006   pic10943.gif)                        
                         01:58 PM                                       cc 
                                              (Embedded image moved to     
                                              file: pic01201.gif)          
           Please respond to          (Embedded image moved to file:       
         nv-l@lists.us.ibm.com        pic10701.gif)                        
                                                                   Subject 
                                              (Embedded image moved to     
                                              file: pic24682.gif)          
                                              Re: [nv-l] [NV-L]: Status    
                                              Polling Public Addresses on  
                                              MSCS Clusters                
                                                                           
                                                                           
                                      (Embedded image moved to file:       
                                      pic03524.gif)                        
                                               (Embedded image moved to    
                                               file: pic08895.gif)         
                                                                           
                                                                           



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



(Embedded image moved to file: pic27276.gif)

Attachment: pic17622.gif
Description: GIF image

Attachment: pic14890.gif
Description: GIF image

Attachment: pic10883.gif
Description: GIF image

Attachment: pic10943.gif
Description: GIF image

Attachment: pic01201.gif
Description: GIF image

Attachment: pic10701.gif
Description: GIF image

Attachment: pic24682.gif
Description: GIF image

Attachment: pic03524.gif
Description: GIF image

Attachment: pic08895.gif
Description: GIF image

Attachment: pic27276.gif
Description: GIF image

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web