I just tried that this week on a Win2K cluster that we are testing on. I
marked the 2 virtual interfaces that migrate during the fail over with a
%hostname in the netmon.seed file. I ran into issues where after a fail
over, the 2 virtual interfaces disappeared all together from the map. Even a
demand poll of the node that was holding the interfaces didn't show them. I
had to remove the % from the seed file, delete the nodes, and rediscover.
The only thing I have been able to key on is the Interface Deleted and
Interface Added events that come from the cluster during the fail over. I
don't think that is a good way to detect a fail over event.
Scott Bursik
Event Systems Management
Pepsico Business Solutions Group
(972) 334-3757
scott.bursik@pbsg.com
-----Original Message-----
From: bill.kellam@worldspan.com [mailto:bill.kellam@worldspan.com]
Sent: Thursday, February 13, 2003 1:07 PM
To: nv-l@lists.tivoli.com
Subject: Re: [nv-l] Strategies for dealing with clusters, interface names,
TEC events
Here's an answer from the other end of the spectrum...straight out of
Netview admin training (7.1.3).
You can configure Cisco HSRP addresses in the seed file. I don't know if a
clustered server would produce the same results, but with HSRP, Netview
polls the virtual address for sysname to determine which real router
currently owns the address. When it detects a name change, it generates an
event to delete the interface from one and another to add the interface to
the new owner. I thought that was pretty slick.
Regards,
Bill Kellam
Enterprise Integration and Management
404-322-4616
|---------+---------------------------->
| | Jon_Austin@bankon|
| | e.com |
| | |
| | 02/13/2003 01:34 |
| | PM |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------
-----------------------------------|
|
|
| To: <nv-l@lists.tivoli.com>
|
| cc:
|
| Subject: [nv-l] Strategies for dealing with clusters, interface
names, TEC events |
>---------------------------------------------------------------------------
-----------------------------------|
We are a legacy installation of NetView, since the 4.x to 5.x days. We are
current at 7.1 heading on the current level this year.
Our implementation was architect way back last millennium. Our mission is
discrete:
Up/Down status polling on server class systems and network
devices (interface/node)
SNMP trap processing
Everything munges through with a single target path: T/EC, and
then an incident management system.
Way back when a decision was made to use /etc/hosts entries to make NetView
objects without domain names. It allowed us not to have to truncate the
names in T/EC.
However, with the increased use of clustering architectures, and assigning
multiple names and IP addresses to a physical server device, we're trying
to grok out how to properly distinguish between a cluster server (with an
associated IP address) and a cluster service (with another associated IP
address) end-to-end, from interface down/node down, all the way to incident
management.
I would greatly appreciate any thoughts on the subject, detailed on
conceptual.
Should we be evolving our NetView configuration away from a local
/etc/hosts file?
Can NetView handle at discovery time associating different names (derivable
from DNS) as labels for different interfaces so we can treat a Cluster
Service (and IP) like a virtual node from detecting interface loss through
to incident management? We are extremely bullish on automation where
possible.
Jon C Austin
Enterprise Management
Technology Operations
Bank One Card Services
(302)282-3498 (phone)
Jon_Austin@bankone.com
**********************************************************************
This transmission may contain information that is privileged, confidential
and/or exempt from disclosure under applicable law. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any
reliance thereon) is STRICTLY PROHIBITED. If you received this transmission
in error, please immediately contact the sender and destroy the material in
its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
|