There is another option I believe (it works for NetView on NT anyway, and I
have a feeling it also works for UNIX -- since it really has its roots in
MLM technology).
The basic concept is to have mid-level NetView systems appear as mid-level
managers (without changing their configuration). Don't know if this is
a better idea or not than just converting to mid-level managers (but I'm
just
explaining the option here).
In the V6 distribution there is a /usr/OV/tcl directory. In that directory
there is a program called iface_status.tcl. What you do is put this program
as the automatic-action to interface-up, and interface-down, on the
lower-level
NV systems.
What the trap does is generate mid-level manager traps and send them to your
top-level NetView system ... the receiver of the traps.
What this porvides is the off-loading of polling to the lower-level NetView
systems. An added benefit... is that when the top-level NetView system
receives
a mid-level mgr interface up/down trap from a device that isn't in its
database...
it immediately goes out and discovers the device, and adds it to its
topology.
Now on NetView NT what you also have to do (to make everything happen
automatically)
on your top-level manager is to goto "Server Setup >> Discovery", and select
the check-box "Recognize MLM nodes whether or not in MLM Seed-File". Don't
know
what the UNIX equiv is -- maybe Leslie knows.
In summary...
a) You only have to add the TCL-program to the lower-level systems.
b) You only have to select the check-box on the higher-level system.
c) It off-loads status-polling to lower-level systems.
d) The higher-level system will automatically do node-configuration, once
it receives
a mid-level mgr trap from a device it doesn't know about.
I've used this on NV NT for some time. Its cool...
Regards,
Gary Boyles, Intel
-----Original Message-----
From: Leslie Clark [mailto:lclark@us.ibm.com]
Sent: Monday, January 15, 2001 4:09 AM
To: IBM NetView Discussion
Subject: Re: [NV-L] NetView architecture suggestions needed?
You are on the right track. The MLM approach solves several problems that
go with changing IP addresses - access lists and trap destinations in
particular.
But you will want your Netview server to do all of the discovery, not the
MLMs.
Netview has much better control over discovery than does MLM. After the
server discovers them, make the appropriate MLM take over the status
polling.
This is most easily done by enabling the APM function (C5d daemon). Then
you can use the Smartset editor to modify the definition for the Smartset
created
for each MLM to tell that MLM that it is responsible for those nodes.
The definiton of what is assigned to an MLM via APM must resolve to nodes,
not
interfaces. If you use the subnet form of the Smartset definition, this is
pretty easy.
The default definition will be the subnet that the MLM is on. Expand that
to additional
subnets. I have done this with fairly large numbers of subnets by
maintaining a file
and cutting and pasting this into the text form of the smartset editor.
Membership
is dynamic, so new nodes will automatically be assigned to the MLM.
The MLMs forward status changes to the Netview server, where simulated
status events are generated. So you lose nothing of Netview's function.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(248) 552-4968 Voicemail, Fax, Pager
Steve Damron/Boulder/IBM@IBMUS@tkg.com on 01/15/2001 12:41:23 AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: nv-l@tkg.com
cc:
Subject: [NV-L] NetView architecture suggestions needed?
I am looking for suggestions for the architecture problem that our NetView
team has been handed.
Our system = AIX 4.3.3 , NetView 6.01
Situation
-We currently have a NetView box (boxA) that needs to be migrated to a new
box and new ip address (we are putting this new NetView box (boxB) in a
HACMP cluster for failover, this has been decided by higher ups and
changing this setup is not an option.) All devices in our environment are
currently configured to send traps to boxA. So migrating to boxB means
changing SNMP settings on all our devices to send traps to the new NetView
boxB, this is bad as we have a very large environment.
-We are also building a new NetView box (boxC) in another building to
handle our expanding environment. The network devices in this building
have been configured to send traps to this new NetView boxC.
-It has been determined that one NetView box cannot handle monitoring of
the environments in both buildings, not because of high CPU utilization but
because of excessive network traffic such as receiving traps and doing
polling (so the new NetView boxB can not take over monitoring of both
building's environments all by itself)
Goal
The two main goals are to keep only one map for operations to watch (a map
that covers the environments in both buildings - we set our map up with
smartsets of customer's devices). And, not having to change all of the
SNMP settings on all of the devices in our environment to send traps to
different NetView boxes, as we have a very large number of devices.
Considered Idea
One idea was to make boxA and boxC into mid level managers (MLM), and have
them both forward events to the main boxB in the HACMP cluster. My concern
here is that 1) MLM's discovery is limited to its subnet and this would
create a maintenance nightmare as our devices have multiple interfaces on
multiple subnets and we want to monitor all interfaces, and devices are
added and removed frequently 2) We lose some of NetView's monitoring
features by running MLM's ? like rulesets, forwarding to TEC and the web
server.
Any ideas would be welcome as well as corrections/solutions to the MLM
problems I have identified.
Steve Damron
swdamron@us.ibm.com
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
|