HP OpenView System Administration Handbook [Electronic resources] : Network Node Manager, Customer Views, Service Information Portal, HP OpenView Operations نسخه متنی

9.5 DISTRIBUTED INTERNET MONITORING (DIM)

NNM allows a single management station to manage tens of thousands of geographically dispersed nodes by implementing

Distributed Internet Monitoring (DIM). DIM may be configured one of several ways. An implementation of DIM uses CS, MS, and MSs doubling as CSs to monitor specific portions of a network enterprise. These CSs are "managed" by one or more MSs. The topology and the status of each object are sent from the CS to the management station that "managed" each object. Any detected change in object status at the CS is sent to the MS, thus allowing a single MS to manage more nodes than if it were configured as a standalone system. The discovery and monitoring of the network are now distributed throughout the enterprise and may pass the information to one or more MS's acting central database location. SNMP traps can also be forwarded from the CS to the MS; some are automatically forwarded by virtue of the CS being managed by an MS. Multiple MSs can manage a single CS.

Note

At minimum, an Advanced Edition license is required for any system to be configured as an MS. A CS may use Starter Edition or Advanced Edition. An Enterprise license is required for a Management Station to configure and start the ovrepld process that allows the MS to "manage" a CS to replicate a CS topology.

The architecture of DIM may be configured hierarchically (shown in Figure 9-8) or peer-to-peer. In the hierarchical implementation, configuration data is passed from the CS to the MS. In the peer-to-peer implementation, both the MS and the CS exchange configuration data. Each station type (MS and CS) has a collection domain and nodes in which each is responsible for monitoring and collecting information. These domains may be completely independent or may overlap. This section describes DIM architectures, domain configuration, and the use of topology, discovery, and failover filters. The implementation and synchronization of MS/CS is also covered.

The role of a CS is to act as a collection point in the network management enterprise. A CS performs topology and status monitoring, threshold data collection, and event handling. CSs should be placed strategically in your enterprise to reduce polling traffic across expensive, slow, or congested links. A CS can also be used as a management console server.

The implementation of DIM partitions the discovery and status polling and dramatically reduces traffic on portions of the network. A fully deployed DIDM implementation should support up to 25,000 devices.^[5]

^[5] The upper limit of managed devices depends heavily on the level of monitoring and data collection configured in an implementation. Hewlett-Packard derived this number for a CS containing 5,000 objects for a stand-alone CS with an object-to-node ratio of 2.4. This number varies for network maps containing a larger object-to-node ratio.

9.5.1 CS Configuration

The steps to configure a CS typically include the configuration of several types of filters. Listed here are the detailed steps in CS configuration:

1. Configure and apply a local discovery filter to define the collection domain. Make the required changes to the $OV_CONF/filters file. Be sure to test your filter for syntax errors and accuracy using

   ovfiltercheck and

   ovtilertest . Apply the previously defined filter expression

   CriticalDevices as a discovery filter by selecting

   OptionsNetwork Polling Configuration:IP from the NNM GUI. In the

   General Configuration Area, toggle on the box labeled

   [Use Discovery Filter] . Click

   [OK] . Refer back to Section 9.4.4, "Discovery Filters," for details.

   Sets {
   servers "Set of Servers" { "sv1", "sv2", "sv3" }
   }
   Filters {
   NetsNSegs "All networks & segments" 
   { ((isNetwork) ||(isSegment))
   HPNodes "Hewlett-Packard nodes" 
   { isNode && ( vendor == "Hewlett-Packard" )
   ServersSet "Any designated Server node" 
   { "IP Hostname" in servers }
   ImportantNodes "Important systems"
    { "IP Address" ~15.2.112-119.* }
   }
   FilterExpressions {
   CriticalDevices "HP nodes, nets, segs, or servers "
    { HPNodes || NetsNSegs || ServersSet
    || ImportantNodes }
   }
   

2. Configure and apply a topology filter to determine which objects to be passed to the MS. Make the required additions to the filters file by including the TopoFilter definition below. Apply the filter by modifying the $OV_LRF/ovtopmd.lrf. Refer back to Section 9.4.5, "Topology Filters," for details.

   FilterExpressions {
   TopoFilter "HP nodes, nets, segs, and important sys"
    { HPNodes || NetsNSegs ||
   
    ImportantNodes }
   }
   

3. Configure the

   snmpd.conf for security. The MS needs access to both the get and set community names. Make the following modifications to the

   /etc/snmpd.conf file:

   
   get-community-name: public
   set-community-name: secret
   

   Note

   Configure the community names of the SNMP Agents on the MS and CS to different community names from the rest of the managed network.

4. Restart the SNMP agent by typing the two commands:

   
   /sbin/init.d/SnmpMaster stop
   /etc/snmpd
   

9.5.2 MS Configuration

Prior to configuring the MS, you need to obtain the hostname and get and set community names of the CS. The detailed steps for configuring, testing, and synchronizing with the CS follows:

1. In order to make the CS nodes more visible, turn off auto-layout on all submaps.

   UNIX:

   Select

   ViewAutolayoutOff for all Submaps

   Windows:

   Select

   MapProperties

   Select the

   View tab

   Un-check

   Autolayout

2. Configure SNMP to communicate with the CS.

   UNIX:

   Select OptionsSNMP Configuration and specify the hostname of the CS as the target and the set-community name as defined on the CS in the

   snmpd.conf file.

   • Target:

     hostname

   • Set

     Community secret

   • Click

     Add

   • Click

     [OK]

   
   Windows:

   • Select

     OptionsSNMP Configuration

   • Select the Specific Nodes Tab

   • Click

     Add

   • Target

     hostname

   • Set Community

     secret

   • Click

     [OK]

3. Test the communication to the CS with the

   xnmtopoconf command. Specify the hostname of the CS.

   xnmtopoconf test

   hostname

   The output should look something like this:

   Testing station cs1.hp.com.
   ICMP round trip time = 1 ms.
   Ping test to cs1 (192.50.100.20) succeeded.
   system.sysObjectID.0 : .iso.org.dod.internet.private.enterprises
   .hp.nm.system.hpux.hp9000s700
   Get sysObjectID test to cs1.hp.com succeeded
   Station description: HP OpenView NNM Release B.06.10 for Unix
    Distributed
    Station
   Station filter:TopoFilter
   Station licensed node count: UNLIMITED
   Station managed node count: 50
   Station license expiration date: PERMANENT
   Get topology info test to cs1.hp.com succeeded
   Station is not currently configured to forward events
   Set event forwarding test to cs1.hp.com succeeded
   Test for station cs1.hp.com passed
   

4. Configure, test and apply a discovery filter to be used on the MS. Refer to the previous section on configuring discovery filters for details.

5. If the CS is not included in the MS's collection domain, add the CS to the MS domain using the

   xnmptopoconf command. Specify the hostname of the CS.

   xnmtopoconf add unmanage

   hostname

6. Start managing the CS and immediately join the synchronization process, specifying the hostname of the CS.

   xnptopoconf manage

   hostname

   nmdemandpoll s

   hostname

   You should notice the newly added devices from the CS in the new object holding area in ovw.

7. Display the topology of your system with the

   ovtopodump command.

   ovtopodump RISC

9.5.3 Overlapping versus Non-Overlapping Domains

The simplest DIM configuration is to have completely separate collection domains. In this configuration, each device is monitored by a different NNM station. Each NNM station monitors a separate set of devices. Therefore, each database has a completely different set of data. However, it is not uncommon to have certain devices monitored by multiple collection stations. This configuration is known as overlapping collection domains.

When configuring collection stations, you may chose to have multiple stations poll the same devices. A redundant independent collection is a configuration in which two collection stations monitor all the same devices. This means independent discovery and management of the same network by two management stations. In this configuration, duplicate polling occurs on all devices.

Another DIM configuration is to have partially overlapping domains. For example, you might determine that certain important devices be polled by two separate collection stations. In this configuration, duplicate polling occurs only on the important devices that are managed by both collection stations.

Whenever overlapping occurs, an MS receives multiple versions of the same object from different CSs. The MS must choose one version as the primary. All other versions are treated as secondary versions. NNM uses the following nine rules, evaluated in order, to determine which version is the primary:

1. If only one station reports the object, it is the primary CS.

2. If an object is an interface ( isInterface == TRUE ), skip to rule 7.

3. If only one station reporting the object is managed and has noncritical status or has failed over, that station has primary ownership of the object.

4. If the administrator has expressed a preferred primary CS^[6] (

   xnmtopoconf preferred

   CS

   object ) for the object, that station is the primary CS for the object.

   ^[6] A preferred primary for an object may be configured by executing

   xnmtopoconf preferred CS object on the MS.

5. If only one station reporting the object is managing the object, that station is the primary CS for the object.

6. If one station reports that the object is a gateway, that station is the primary CS for the object.

7. If the object is completely contained in another object, the CS for the container object is the primary CS for the object. For example, a non-gateway node should have the same primary CS as the network that contains it.

8. If one of only two stations reporting the object is non-local (not the MS itself), the non-local station is the primary CS for the object.

9. The first station to report the object is the primary CS for it.

You can determine whether objects are primary or secondary by displaying the topology database with the

ovtopodump RISC command. These options provide the following information:

NNM uses the special characters listed in Table 9-5 to identify objects that are non-local or do not appear in a submap. The output of

ovtopodump RISC will look something like the following:

OBJECT ID(S)   OBJECT             STATUS    IP ADDRESS   STATION 
1014   -                                    IP Internet  local
STATIONS:
1015   -       nnmcs1             Normal                local
1038   -       dbserver           Unmanaged             local
NETWORKS:
1016           IP 15.50.168       Normal   15.50.168.0   local
SEGMENTS:
1019   -       15.50.168.Segment1 Normal                local
NODES:
1018           IP nnmcs1          Normal   15.20.19.1    local
1018/17        IP nnmcs1          Normal   15.20.19.1    local
1035           IP fs1             Normal   15.20.10.2    local

When you configure overlapping domains you must determine how to handle secondary objects. There are three choices in how to handle secondary:

1. Allow Overlap
   Duplicate polling occurs

2. Unmanage
   Duplicate polling does not occur, but the objects are stored in the database. This allows the station to quickly take over with a manual switchover if the primary station fails.

3. Delete Secondary
   Eliminates duplicate polling and duplicate storage of objects in the database for non-connector devices. This does not delete network, segments, or routers that overlap. This is the default behavior with overlapping domains.

The

xnmtopoconf command may be used to display and modify the overlap mode. To display the overlap mode, execute

xnmtopoconf print . The output will be something like this:

STATION   STATUS INTERVAL OVERLAP MODE  FAILOVER FILTER 
Local     Normal 5m       DeleteSecondary off   <none>
nnmcs2    Normal 5m       AllowOverlap    off   <none>

The overlap mode may be modified by specifying one of three overlap modes with the

xnmtopoconf command:

AllowOverlap, UnmanageSecondary, DeleteSecondary . For example, to set the overlap mode to AllowOverlap, execute the following command on the management station:

xnmtopoconf overlap AllowOverlap local

9.5.4 Troubleshooting DIM

Collection stations are identified by the object attribute

isCollectionStationNode . When the remote station answers a MIB query for the NNM MIB, this MIB variable is retrieved. If a collection station is not in the collection domain of a management station, it is not displayed with

xnmtopoconf print . The collection station may be added. If you execute

xnmtopconf add unmanage

collectionStation , the collection station is added to the topology database on the management station but is not managed (no topology is retrieved from it). If you execute

xnmtopconf add

CollectionStation , it starts the synchronization process between the management and collection station.

The SNMP set community name must be configured on the collection station. The set community name of the collection station must be configured in the NNM GUI on the management station. This can be verified by executing

xnmtopoconf test

CollectionStation . If this fails, you will not be able to synchronize with the collection station. This command performs four tests to the collection station including ping, two SNMP gets, and an SNMP set. Observe the output of the command closely to determine reason for failure. Refer back to Section 9.5.1, "Collection Station Configuration," and Section 9.5.2, "Management Station Configuration" for details on SNMP configuration.

Configuration of management and collection station overlap may take a couple of iterations before you get the expected result. You may reset collection station by issuing

xnmtopconf reset

CollectionStation . When you reset a collection station, the topology information is removed from the topology but the station itself is left in a managed state. To completely remove a collection station and its topology, execute

xnmtopoconf delete

CollectionStation .

When configuring automatic failover, the default interval is set to 5 minutes. When a status check of a collection station fails, the status is downgraded one level and an event is generated. After four status checks, or 20 minutes, the management station takes over status polling for the devices for which the collection station was the primary. During initial configuration you may want to set the interval to 5 seconds so you aren't required to wait 20 minutes during testing. You can modify the interval by executing

xnmtopoconf interval 5s

CollectionStation . Make sure to set it back to a reasonable interval when you've finished testing. The following intervals are accepted: seconds (s), minutes (m), hours (h), and days (d).

When troubleshooting the topology database, use

ovtopodump RISC . This lists removed, invisible, secondary, and collection station objects in the database. Another useful option is to execute

ovtopodump using a filter name. You can determine which objects will pass a filter by executing

ovtopodump f

FilterName . Obtain a list of defined filters by executing

ovfiltercheck.

The

ovrepld process must be running on the management station. It is not required to run on a collection station. To verify that

ovrepld is running, execute

ovstatus c on the management station. You can also use

ovrepld to log transferred topology information. All information can be logged to ovrepld.log by executing

ovrepld p COWG . This logs information for every device from the remote collection station. The specified options write the following information to ovrepld.log:

C - Collection station list
O  Report All Activity
W  Wait list: actions awaiting response
G  Global actions: ready queue