Hi Jon,
I wonder if there is a simple but perhaps not elegant answer available.
You correctly talk about a Cluster Server vs a Cluster Service. You even
go so far as creating a virtual node by way of a different hostname for
your Cluster Service interface.
For handling Cluster Server: this is just a server like any other that
you have. You have a great process, so why change things?
For handling Cluster Service: You have it as a virtual node. So you know
when it truly goes down, but you don't know when it goes from primary
Cluster Server to secondary Cluster Server. Couldn't you have a script
that runs forever, that is run out of CRON. You should know the
system.sysName of your Cluster Servers? Cannot the script access that
value via the Cluster Service interface and determine if it is on the
primary or secondary Server? Then generate a trap (already configured in
NV and TEC) if on secondary server which goes through your great event
handling system you already have built? You don't have anyone sitting
at your NV screen, but if you wanted to, you could add a symbol to the map
and have a second SNMP trap change status of that symbol.
Application running on that Cluster Service: I would expect that you have
ITM handling this chore.
Kind regards,
Stephen Hochstetler shochste@us.ibm.com
International Technical Support Organization at IBM
11400 Burnet Road Austin, TX 78758
Office - 512-838-6198 (t/l 678) FAX - 512-838-6931
------------------------------------------------------------
http://www.redbooks.ibm.com
Jon_Austin@bankon
e.com To:
<nv-l@lists.tivoli.com>
cc:
02/13/2003 12:34 Subject: [nv-l] Strategies for
dealing with clusters, interface
PM 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)
|