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
|