Steve,
Leslie has responded with sugg's regarding MLM's. I had a bit of input
regarding the handling of traps for your devices. One product I checked out
a couple years ago (but could never get funding for) was a trap exploder
from Empire Technologies. This can run on Unix, NT and Linux and you
configure all your devices to send their traps to it. You can then filter
out ones you don't want and then forward the rest on to FM platforms. It
adds a failure point, to be sure, but it can help standardize device
configurations as you don't need to track which systems/zones send their
traps to which FM system. Everything goes to one trap exploder (or two if
you want the redundancy) and you configure that one system to get what you
want.
Regards,
Steve Elliott
Sr. Network Mgmt. Engineer
epicRealm, Inc.
214-570-4560
-----Original Message-----
From: Steve Damron [mailto:swdamron AT us.ibm DOT com]
Sent: Sunday, January 14, 2001 11:41 PM
To: nv-l AT tkg DOT com
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 AT us.ibm DOT com
|
