nv-l
[Top] [All Lists]

Re: nvserverd vs tecad_nv6k for TEC Integration

To: nv-l@lists.tivoli.com
Subject: Re: nvserverd vs tecad_nv6k for TEC Integration
From: James Shanks <James_Shanks@TIVOLI.COM>
Date: Tue, 13 Jul 1999 10:04:37 -0400
Reply-to: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Sender: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
I don't think any performance benchmarks for the two adapters exist, so you'll
have to experiment yourself.  I wouldn't expect any dramatic difference.
tecad_nv6k uses filters and nvserverd uses ruleset to select what to send, but
both are linked with the same libraries to accomplish the sending.

You could set up the internal adapter to forward to a bogus TEC -- a real
machine with no TEC console on it -- and then nvserverd will just cache what he
should send to /etc/Tivoli/tec/cache.   After some period of time you can
examine this file and see what is being sent, and thereby get an idea what your
TEC will see if you switch to the internal adapter.  The actual performance will
be hard to judge, however, because nvserverd will be trying to contact that box
with every event, so it will seem slower. But this will allow you to experiment
with different rulesets if you like, and also to note slot values and that sort
of thing if wish.

When you are tired of testing, you can simply issue the command
     nvtecia  -stop
and TEC forwarding will stop but  the nvserverd daemon will keep going with his
other tasks. Then you can remove or rename the /usr/OV/conf/tecint/conf file
that you created when configuring the setup, so that when you  restart nvseverd,
he does not begin TEC forwarding again.     It is the presence or absence of
this file on startup which determines whether nvserverd forwards to TEC.   You
can even change rulesets on the fly by changing the file and issuing
     nvtecia -reload



James Shanks
Tivoli (NetView for UNIX) L3 Support



Rob Rinear <robr@DIRIGO.COM> on 07/12/99 01:30:25 PM

Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
      <NV-L@UCSBVM.UCSB.EDU>

To:   NV-L@UCSBVM.UCSB.EDU
cc:    (bcc: James Shanks/Tivoli Systems)
Subject:  Re: nvserverd vs tecad_nv6k for TEC Integration





I made that same assumption - newer is better.  But I've not moved away from
tecad_nv6k yet, because I have a concern about performance with the customer
I'm currently working with.  They have every networking device spewing every
possible trap to the Netview box, but I can't change that yet (I just set
them to Log Only, or Don't Log or Display).  With Netview seeing an average
of 2-3 traps per second, all day, every day, I just wonder which method will
cause less of a performance hit?  Again, I know the long term answer is to
eliminate the excessive traps, but for now I have to go with what will
handle it best.  Will ruleset forwarding perform better or worse in this
situation?

Rob

-----Original Message-----
From: Discussion of IBM NetView and POLYCENTER Manager on NetView
[mailto:NV-L@UCSBVM.UCSB.EDU]On Behalf Of James Shanks
Sent: Saturday, July 10, 1999 9:36 AM
To: NV-L@UCSBVM.UCSB.EDU
Subject: Re: nvserverd vs tecad_nv6k for TEC Integration


Well, for what it is worth from me, the NetView internal adapter was
designed to
be simpler and easier to use than the tecad_nv6k one.  That one had already
been
around for a few years before the Tivoli merger, and afterward, NetView
UNIX
development was told to design one that was simpler to use and better
integrated
with the product.  Thus the internal adapter was born and I think it is the
sensible way to go on UNIX.   On NT at the moment you have no choice --
tecad_nv6k is only option.  That is because the nvserverd daemon does not
exist
on N, so the UNIX solution could not be ported directly.

So the decision comes down to this, I think.  If you have several NetViews
and
some of them are NT, and they must also forward events to TEC themselves,
then
you will have to invest some time in learning the tecad_nv6k.  The only
alternative would be to have the NT NetViews forward events to a UNIX one
and
have the UNIX one talk to TEC.    But without the necessity of sending
events
from an NT NetView, I'd use the internal one.  It's almost a no-brainer.

James Shanks
Tivoli (NetView for UNIX) L3 Support



"Giovannini, Tom" <tom.giovannini@EDS.COM> on 07/09/99 06:24:02 PM

Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView
      <NV-L@UCSBVM.UCSB.EDU>

To:   NV-L@UCSBVM.UCSB.EDU
cc:    (bcc: James Shanks/Tivoli Systems)
Subject:  nvserverd vs tecad_nv6k for TEC Integration





We are in the process of converting from HP OpenView NNM to NetView UNIX.
What I am looking for is advise on what is the best way to forward events to
TEC (nvserverd or tecad_nv6k).

My environment is:
                Tivoli Framework 3.6 including TEC 3.6
                NetView 5.1.1
                SMARTS IPFM product (root cause analysis product)

Since I am a new user to Netview I do not have any investment (time,code) in
the use of the tecad_nv6k adapter.

Based on what I have read and some testing it seems to me that the easiest
way to have events forwarded to the TEC is via the nvserverd daemon.  The
NetView Ruleset Editor can be use to select events that will be forwarded.
This editor seems easy to use.

The tecad_nv6k adapter requires updating of the cds, oid and conf files.

Before I commit to the use either of these adapters I would like to get some
advise from those that are much more experienced than I in these products.
Are there any differences that should be considered in making this
selection.  I will need to forward SMARTS IPFM events to the TEC no matter
what.

Please advise.
Regards,

Tom Giovannini
EDS
Enterprise Management Engineering - South
Address:
        5400 Legacy Drive
        M/S:  A4-1C-38
        Plano, TX   75024
Phone:  (972) 604-4105 (8-834) Fax:  -4776
Internet:  tom.giovannini@eds.com

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

Archive operated by Skills 1st Ltd

See also: The NetView Web