|
Todd H. wrote:
> Hrmmm. Suppose your NetView server is not a managed
node. :-( What then?
>
> BTW--I'd be curious on
the pros and cons of having NetView being a managed node.
The first argument for NetView residing on a Managed Node
is that there is no other option unless you are one of those few who understand
the product well enough to install it without the support present on a Tivoli
Managed Node. You MUST install NetView for Unix on a Managed Mode or know
how to hack the NetView image from the distribution media and THAT requires a
TMN. NetView for Unix's only installation alternative was
through the Tivoli Desktop "Create" function on Version 5.x and is through
the "Product Install" on 6.0. (Or their command line
equivalents.)
This is true of all the other Tivoli applications which exist
in the Framework environment. (I happen to consider the Tivoli Management Region
Server as one of the applications and the TNM as really an Application Support
Facility but that's another topic.)
There is one exception I know of; NetView for NT. It
uses InstallShield. I don't know for sure about Tru64 NetView since I
haven't worked with it but I believe it's just another species of NV for
Unix.
Once you're installed you need not activate the TMN dispatcher
but there's a lot of value to installing a Tivoli Management Agent on
the box and using the Tivoli family of management services.
Warning; lots of opinion follows from an old hand whose been working with
NetView in all its flavors since 1975. I retired from the IBM SystemView
Technical Staff and became a consultant two years before IBM acquired Tivoli
Systems and handed them the SystemView personnel and product line to manage
and market. Yes, the NetView family has been around that long
although the "NetView" trademark wasn't coined until ten years later and
the NetView for AIX product released until five years after that.
PROS and CONS
The CON side is easy; there isn't much
required interaction today except installation. NetView for
Solaris originally required the Tivoli Desktop to do what is now available
through ServerSetup. Prior to Tivoli and the Solaris support NetView
for AIX used SMIT. I'm not sure what Polycenter NetView for the
Tru64 used.
The PRO side has a couple parts.
Useful pieces of the Framework applications are optional; the
interfaces to Inventory, management of user accounts by UA, secure
authentication for TEC integration, use of the Scheduler for backups, use of RIM
for storing data in RDBMSs and all the other things the CORBA base
brings.
The second piece of the action is the future prospects of
tighter integration of the NetView and Framework desktops. The Web
Client ("rumored" to be even more improved in NV 7.1), the Tivoli Business
Systems Management/NetView 390 desktop and the direction of the future
desktop for the Tivoli Framework products are all in the same Java based
technology. I anticipate developments in this area (and I'm aching to
see 7.1 changes). We may see the end of the X-windows based, memory
intensive consoles someday. Unix and Windows client machines will be
able to use Unix, Windows and Mainframe servers without special
middle-ware like Hummingbird Exceed. Today Unix includes AIX, Solaris and
Tru64; in the future it should include HPUX and any other flavor supporting
Java for the client and Linux at least for the client and maybe for the
server. (All this is already present or tea leaves; the
developers haven't shared inside information with me recently.)
I'm also one of the few who characterize NetView as primarily
the SNMP front end to the Tivoli Management Environment. It works
with TEC as a partner to Distributed Monitoring as the CORBA front
end. MIB data collection and DM data collection are companion functions as
well. It is also the SNMP front end to Inventory and could be the SNMP
front end to User Administration and Software Distribution with a little
work. UA needs a method using SNMPSET with the super-user community string
to modify the router settings but SD just needs to be told where to find
the source image and where to store that image for TFTP. Just
imagine distributing Cisco IOS images to TFTP repositories with Tivoli SD and
scheduling changes for Cisco operator permissions using UA and the
Scheduler. (First we need secure SNMP widely available.)
NetView's MIB Data Collection will gather information and
use the Tivoli RDBMS Interface Manager to feed it to a relational data base for
Tivoli Decision Support (or Concord Network Health) to use for
statistical analysis and proactive decision making. Eg. RouterX is
trending toward saturation on three links and nearing it's CPU capacity so we
need a larger box or another box to share the load.
With the Tivoli NetView for OS/390 Multi Systems Manager you
can feed the Tivoli Business Systems Management data base from both NetView for
Unix and the TME. This consolidates your entire enterprise on a
single topology server and Java based set of operator consoles. Once we
have a Java desktop for the TME we'll be complete.
I see the topology maps and MIB Browser as diagnostic
tools and not primarily for monitoring. No sane person watches
the screen for something to turn red so they can spring into action; if they do
they aren't going to be sane for long. TEC automation allows the automatic
opening of a trouble ticket and dispatch of the appropriate assigned specialist
according to the duty roster and preferred method (e-mail or
pop-up).
Enough? We can take this offline if you (or anyone else)
want more punishment. My employer will be happy to rent me out for user
groups, weddings or Bar Mitzvahs as well as NetView
implementations. I hope it addresses your concerns.
|