2.12 HP OpenView Network Node Manager

Operations Center offers two adapters that integrate with HP OpenView Network Node Manager software. The basic integration required an ORB installation to integrate with the software. The other, the NNMi adapter does not.

2.12.1 HP OpenView NNM

The HP OpenView (NNM) adapter works in conjunction with the OvORB. OvORB provides the following features:

  • Starting and stopping automatically with NNM as an OV daemon process, not on a per-console basis. The OvORB is an OV managed process.

  • Managing alarm data. The adapter can run without the OvORB to manage object, symbol and topology data.

  • Lazy and Auto Discovery.

  • Access to SNMP Varbinds in alarms.

  • Importing NNM event definitions from the trapd.conf file and displaying them in Operations Center.

  • Alarm Normalization Customization. Derives Object ID, Event Source, Event Time, and Severity of an event on a per Event OID basis.

  • Access to all object, symbol, and submap information of elements.

  • Condition algorithms on elements.

  • Manage and Unmanage element commands.

  • Map properties available from the root element property pages (Details page).

  • Event descriptions available from the root element property pages (Event Descriptions page) and from alarm properties.

  • Acknowledge, Unacknowledge and Delete alarm commands.

Ping and Traceroute originate from the OvORB machine. If the OvORB is not installed, they originate from the Operations Center server.

Operations Center displays graphical representations of OV symbol, submap, and connection icons. Elements in the Explorer pane use the OV icon to identify the class of an object, or use a connection symbol to show a connection object.

The OvORB manages all alarm and event logic. The NNM adapter is responsible for representing the map, symbol and topology data. The NNM adapter is also responsible for normalizing NNM event data into Operations Center alarms. It performs this normalization based on metadata derived from the NNM event definition and the alarm normalization data.

If the OvORB goes down for maintenance or a crash, the integration continues to run. When the OvORB restarts, the integration automatically recovers without requiring stopping and restarting the adapter. After the OvORB restarts, it automatically resynchronizes changed alarm data.

Integration without the OvORB

It is possible to integrate the HP OpenView (NNM) adapter and Operations Center without the OvORB. When configuring the OpenView adapter properties (see Section A.13, HP OpenView Network Node Manager), leave the adapter.orb port blank (the default). Start the NNM adapter and it should connect to the ovw map; the adapter icon should change to green. If the connection is unsuccessful, the icon is red (CRITICAL).

Setting up the Integrated Environment

Because of HP architecture limitations, the following requirements exist for proper function of the NNM integration:

  • The default map must be read/write. The NNM integration always uses the default map and it requires read/write permissions. The adapter can only attach to the default map. This is a limitation of the HP NNM API.

  • An NNM console must remain open for the integration to maintain a session with NNM. However, it is not necessary for this console to be the default read/write map.

The integration with HP NNM is a two-part process. It requires a one-time setup of the Operations Center server, followed by installation of the OvORB software. Even if there is no plan to manage alarms or use the OvORB services, it is necessary to install the software on the NNM machine because the adapter requires some files.

To integrate OpenView:

  1. Stop the Operations Center server.

    For instructions, see Stopping the Operations Center server in Windows and Stopping the Server and the mosdaemon manually in UNIX in the Operations Center 5.0 Server Installation Guide.

  2. Configure the Operations Center server to not restart automatically.

    For more information, see the Operations Center 5.0 Server Configuration Guide.

  3. On the Operations Center server machine, copy (or symbolically link) the libovw.jar file from the HP Network Node Manager distribution to the /OperationsCenter_install_path/classes/ext directory.

    The libovw.jar file is on the NNM server machine in the /opt/OV/www/htdocs/classes directory.

    For OpenView 7.5, copy an additional file, launcher/ovlaunch.jar, to the /OperationsCenter_install_path/classes/ext directory. This path is relative to the location of libovw.jar in the HP Network Node Manager distribution.

  4. Update or install the license file through the Operations Center Customizer, if applicable.

    The license file must contain one or more key entries for com.mosol.integration.nnm.NNMntegration.

  5. Install, configure and start the OvORB on the NNM server machine.

    For instructions, see Section 10.0, ORB Installation.

  6. Start the Operations Center server and launch the Operations Center console.

  7. Create an OpenView Network Node Manager adapter for each instance of NNM.

    For instructions, see Section 5.1, Creating an Adapter.

  8. Modify the HP OpenView Network Node adapter properties.

    For instructions, see Section A.13, HP OpenView Network Node Manager.

    The two nnm.jar files, the Operations Center server integrations/nnm.jar and the OvORB classes/nnm.jar should be the same. Otherwise, a warning message is issued.

Port Communications Setup

To establish communication between the NNM adapter and OvORB, use the following port assignments:

NNM Adapter Port Number

OvORB Port Number

1572

Any port

1573

Any port

Any port

1572

Any port

1573

Any port

3700–3720

Any port

2447

Upgrading a Pre‑3.5 Adapter

The Operations Center upgrade process automatically upgrades all legacy adapter definitions. However, the installer only performs the upgrade on the existing adapters.ini file in the /OperationsCenter_install_path/database directory.

After performing a clean installation and copying the configuration files (such as adapters.ini) to the new installation directory, it is necessary to manually upgrade all pre‑3.5 NNM adapter instances. These steps require deleting the adapter instance and creating a new NNM adapter.

Use the following steps to manually update the pre‑3.5 version adapters.ini file. It is necessary to follow these steps only if backwards compatibility is required with a pre‑3.5 version OpenView adapter instance.

To manually upgrade a pre‑3.5 adapter:

  1. Open the adapter properties for the pre‑3.5 adapter and determine the adapter instance from the DName.

    The adapter instance is found after the openView: part of the DName. For example, if the DName is openView:4=MyOV/root=Elements, the instance is 4.

  2. Delete the adapter instance.

  3. Create a new NNM adapter.

    Use the same adapter name as the legacy adapter.

  4. Specify the legacy adapter’s adapter instance in the Adapter Instance property.

    Note that some adapter properties are no longer available in the adapter properties setting for the NNM adapter. Command.Ping and Command.Trace.Route now run in the ORB and are configured in the new OvORB. RequestDepth is not available because topology information is requested directly through the NNM API in the adapter, rather than through the ORB.

Managing and Unmanaging Elements

Manage or unmanage objects using the element menu options in the Operations Center console. Integrations using OpenView NNM version 6.0 support the Manage and Unmanage element commands.

For details on using these options or commands, see Managing and Unmanaging Elements in the Operations Center 5.0 User Guide.

Symbol Status Change Rules: Symbols representing unmanaged objects do not receive status updates from applications. All symbols representing an object on a particular map, regardless of the symbol status source, change to the UNMANAGED state if the underlying object is unmanaged.

Viewing and Updating Alarms

The Operations Center Alarms view displays the alarms that display in the NNM Alarm Browser. When the integration starts with a connection to the OvORB, the integration is ready to begin receiving real-time alarm data from NNM and displaying them in the Alarms view.

The element to which the alarm attaches is the alarm’s affected element. By default, this is the object that corresponds to the alarm’s NNM object ID. In cases where the NNM object ID is 0, the alarm attaches to the adapter manager element. However, alarms with a non-zero NNM object ID sometimes attach to the manager element when the adapter has not yet discovered all the objects in the map.

When the adapter discovers an element, it re-parents the alarms with the newly discovered element. It is possible to specify a particular alarm column or varbind as the event source and affected element from the Event Descriptions property page that is available from the root element or from the alarm property pages.

Events normalize into alarms at startup and in real time. Not all events become alarms. Alarm normalization data is in a file in the /OperationsCenter_install_path/database directory on a per-adapter instance. If the file does not exist, a default file is created. The file name consists of concatenating NNMEventDefinitions with the adapter name.

Note the following alarm changes that affect both Operations Center and NNM:

  • Severity changes are unidirectional between Operations Center and NNM. Changing the severity of an alarm in NNM changes the severity of the corresponding alarm in Operations Center.

  • Alarm deletion is bidirectional between Operations Center and NNM. Deleting an alarm in one system deletes the corresponding alarm in the other.

  • Category assignments are unidirectional from NNM to Operations Center. Assigning an alarm a category in NNM changes the category of the alarm in Operations Center.

  • Alarm acknowledgement and unacknowledgement changes are bidirectional between Operations Center and NNM. Acknowledging (or unacknowledging) an alarm in one system acknowledges (or unacknowledges) the corresponding alarm in the other system. Acknowledgement and Unacknowledgement of alarms does not affect the alarm counts.

Warnings such as the following appear in the formula.trc file if objects are no longer in the map (e.g., they have been deleted), but alarms exist for these objects:

2007-03-15 12:31:36,371 WARN Integration.nnm.NNM 75 on camaro.DefaultDataSource - Cache resolver could not resolve object id to associated symbol list for object id 2017; will cache 'null': Object not on map.

Loading Historical Alarms

The HP OpenView ovalarmsrv process maintains the current state of the alarms displayed in the native OpenView alarm browsers. However, because ovalarmsrv writes out the state information at periodic intervals, the NNM adapter might be missing historical alarms (at adapter start up) that occurred between the update intervals.

Reloading All OpenView Alarms

To reload all OpenView alarms in Operations Center to restore missing alarm information:

  1. In the Explorer pane, right-click the top-level server manager element for the NNM adapter, then click Reload All Alarms.

    All alarms reload from HP OpenView to the NNM adapter.

Configuring the HP OpenView Ovalarmsrv Process

To configure the HP OpenView ovalarmsrv process to write out alarm state more frequently:

  1. Use the –s argument to specify the interval in seconds in the ovalarmsrv.lrf file.

    For example, the following code in the ovalarmsrv.lrf file sets the interval to 10 seconds:

    ovalarmsrv:ovalarmsrv:
    OVs_YES_START:pmd:-s 10:OVs_WELL_BEHAVED:20:PAUSE
    

Reducing Delay Time in Reading Events

As described above, setting the recommended alarmsrv parameter to ‑s 10 should reduce the delay in reading events when the OpenView adapter starts. However, if a significant delay still exists, define the event reading interval in the /OperationsCenter_install_path/config/ovorb.properties file before starting OvORB for HP OpenView Network Node Manager.

To define the event reading interval:

  1. Change the following line in ovorb.properties from:

    # /opt/OV/bin/ovdumpevents -x 1 -f /tmp/ovdumpevents.out
    

    to:

    DumpCmd=/opt/OvORB40/bin/ovorbdumpevents  -f /tmp/ovdumpevents.out -l <interval minutes> -f1 /tmp/log1
    

    This command retrieves the most recent events.

    The following code uses a 60 minute interval:

    # /opt/OV/bin/ovdumpevents -x 1 -f /tmp/ovdumpevents.out
    # or otherwise: cmd -f  /tmp/ovdumpevents.out -l 60 > /tmp/log1
    DumpCmd=/opt/OvORB40/bin/ovorbdumpevents  -f /tmp/ovdumpevents.out -l 60 -f1 /tmp/log1
    
  2. Start the OvORB.

Permissions on Element Menu Operations

Table 2-17 details the ACL permission on various element menu operations.

Table 2-17 ACL Permissions for Operations

Class

Operation

ACL Permission

Root Element

Clear All Alarms

Define

Reload All Alarms

Define

NNM Element

Manage

Manage

Unmanage

Manage

Ping

Access

Traceroute

Access

NNM Alarm

Acknowledge

Manage

Unacknowledge

Manage

Delete

Manage

Change Severity

Manage

Change Category

Manage

Troubleshooting

The following are suggestions for resolving common problems that occur in the integration:

Operations Center does not reflect status changes

The map must be read/write to receive status changes from NNM. This is a limitation of the HP NNM API. If the map is not read/write, use the Refresh option in the NNM console to update the status.

Submaps are not found

If submaps are not found, perform the following steps:

  1. Verify that persistent submaps are on for all levels.

    From the NNM console, click Map > Properties to open the Map Properties dialog box.

  2. Select IP Map under Configurable Applications, then click Configure for this Map.

  3. Verify the On‑Demand: to what level should submaps be persistent? option is set to All Levels.

    By default, this is not automatically set in the Windows version because the Windows version cannot scale as well as the UNIX versions.

The NNM databases that maintain object and topology information can become out of sync. Use the commands listed in Table 2-18, derived from the HP NNM documentation and ITRC forums, to resolve the problem. For more information about these commands, see the ovw reference page in NNM’s online help.

Table 2-18 HP NNM Commands for Synchronizing

Step

Command

Description

Step 1:

ovstop netmon

Stops the netmon service.

Step 2:

ovw ‑mapcount ‑ruvDR

Checks the consistency between the map database and the object database. Checks the values of map reference counts stored in the object database and corrects these values, if necessary.

Step 3:

ovtopofix ‑chs

Runs a utility for cleaning up problems in the topology database and correcting inconsistencies between the topology and the object databases.

For more information, see the ovtopofix reference page in NNM’s online help (or the TNIX main page).

Step 4:

ovstart netmon

Starts the netmon service.

Adding Custom Alarm Properties

It is possible to define custom OpenView alarm properties that are not included in the standard alarm property pages. These custom properties display in the Customer Fields property page. It is necessary to understand how to use the XML-based HierarchyFile, which is a Operations Center mechanism used by adapters to interpret and organize the events reported by management systems.

For more information on the HierarchyFile, see Section 9.0, Using the HierarchyFile.

In order to display custom properties on the Customer Fields property page, it is necessary to define in the HierarchyFile custom alarm fields using an underscore prefix (_). For example: _TEST. The Customer Fields property page only displays if there is at least one field defined using an underscore prefix.

The following HierarchyFile displays the Customer Fields property page for all CRITICAL alarms. A custom field named TEST displays on this page.

<!DOCTYPE hierarchy (View Source for full doctype...)> 
  <hierarchy case="yes">
  <!-- 
 A hierarchy file is required for the NNM Integration.
         The example below can be commented out if not needed. 
  --> 
  <filter operator="and" invert="false">
  <test type="script" expr="var returnCode = true; var sev = alarm.getField( 'SeverityName' ); if( sev != null ) { if( sev.toString().equals( 'Critical' ) ) { alarm.setField( '_TEST', 'TEST FIELD' ); } } returnCode;" invert="false" /> 
  </filter>
  <group name="Alarms" class="gen_folder" affected="no">
  <group name="By Category" class="gen_folder" affected="no">
  <generator field="CategoryName" class="gen_container" affected="yes" hold="no" /> 
  </group>
  </group>
  </hierarchy>

2.12.2 HP OpenView Network Node i-series (NNMi)

The NNMi 8 Integration populates Operations Center elements and alarms based on mining information from NNMi 8 inventory objects (Nodes, Node Groups, Interfaces, IP Addresses, IP Subnets, L2 Connections) and incidents.

NNMi 8 incidents and inventory objects are polled by the integration at specific intervals as specified in the Poll Period (secs) adapter property. New objects are created when incidents and inventory objects are discovered, existing objects are updated, and objects are removed if no longer returned.

Because the NNMi 8 web services API does not have a last update time for incidents and inventory objects, all objects must be polled for to compare against. If an exception occurs during a poll (i.e. connection timeout) then the remainder of the poll is skipped, and another poll is performed at the regular poll period interval. However, no data should be lost.

The integration is a hybrid of an event-based and object-based integration in the following ways:

  • Incident alarms are sent through the hierarchy file to allow for organizing incidents as determined by the hierarchy file.

  • By default, alarms representing inventory objects are sent through the hierarchy file to allow for organizing inventory as determined by the hierarchy file. This can be disabled by setting the Process Inventory Alarms Adapter property to false.

  • Elements representing the NNMi inventory objects are represented in the elements tree to reflect the inventory objects as in NNMi.

NOTE:The Operations Center HP NNMi Integration adapter requires a NNMi SDK Enablement license from HP.

Setting up the Integrated Environment

To integrate NNMi:

  1. Start the Operations Center server and launch the Operations Center console.

  2. Create an HP NNMi Integration adapter for each instance of NNM.

    For instructions, see Section 5.1, Creating an Adapter.

  3. Modify the HP NNMi Integration adapter properties.

    For instructions, see Section A.14, HP Network Node Manager i-series.

  4. Start the HP NNMi Integration adapter.

    For instructions, see Section 5.2, Starting, Stopping, or Deleting an Adapter.

Customizing the Elements Tree

Each running integration instance has four top level folders: Incidents, Inventory, Topology Inventory, and Topology Maps.

  • Incidents and Inventory are event-based branches as determined by the hierarchy file. The names of these two folders and their element structures are determined by the hierarchy file MODL definition.

  • Topology Inventory and Topology Maps are object-based element tree branches.

    Topology Inventory contains an element for each NNMi inventory object (Node, Node Group, Interface, IP Address, IP Subnet, L2 Connection) that is discovered. Only one element for any given NNMi inventory object exists under the Topology Inventory element branch, even if that node is a member of more than one node groups.

    Topology Maps element branch represents the hierarchical parent/child structure of Node Groups and Nodes in the same structure as the NNMi web based client’s Topology Maps/ Node Group Overview view. There is only one element per inventory object in NNMi. The parent/child relationship is represented in the integration through element links. Child Nodes and Node Groups are linked to parent Node Groups. In addition to showing Nodes and Node Groups, Interfaces are linked to associated Node, and IP Addresses are linked to their associated Interface.

The element tree can be customized by doing the following:

  • Change the names of the Topology Inventory and Topology Maps branches by editing the Topology Inventory Folder Name and Topology Maps Folder Name adapter properties.

  • Create Topology Inventory subfolders for inventory objects using the Use Pattern adapter property. You can create subfolders if there are a large number of inventory objects. For example, IP Addresses under one parent can be broken out into subfolders representing a portion of the IP Address name, like a subnet.

Property Pages

All incidents and inventory objects have property pages defined but only properties available through the NNMi Web Services API are shown in the adapter. There is an information property page (i.e. “Node Information”, “Interface Information”, etc.) and for inventory objects that support notes, there is a notes property page (i.e. “Node Notes”, “Interface Notes”, etc.) with the notes property.

Operations

Various operations are available for incidents and inventory objects, but only those available via the NNMi Web Services API are shown in the adapter. Since the integration is polling based, changes made in NNMi or through an operation in the integration do not show until the next poll period is complete.

For example, if the integration polls every minute and it takes a minute to poll completely, changing a Node’s Note property via the Change Notes operation in the integration might not reflect on the Node’s property page for two minutes or until the next poll period is complete.

Table 2-19 lists available NNMi operations.

Table 2-19 NNMi Operations

Object Type

Available Operations

Incident alarms

  • Change Lifecycle State. Available settings are Registered, In Progress, Completed, Closed.

  • Change Notes

  • Delete

Node Groups and Node Group Inventory Alarms

None

Node Elements and Node Inventory Alarms

  • Change Management Mode. Available settings are Managed, Not Managed, Inherited, Out of Service.

  • Change Notes

  • Delete

Interface Elements and Interface Inventory Alarms

  • Change Management Mode. Available settings are Managed, Not Managed, Inherited, Out of Service.

  • Change Notes

IP Address elements and IP Address Inventory Alarms

  • Change Management Mode. Available settings are Managed, Not Managed, Inherited, Out of Service.

  • Change Notes

IP Subnet and IP Subnet Inventory Alarms

  • Change Notes

L2 Connection and L2 Connection Inventory Alarms

  • Change Notes

Severity and Condition Mapping

In Operations Center, alarms have severity and Elements have condition. The severity of NNMi alarms and condition of elements are based on properties of the NNMi incidents and inventory objects as described in Table 2-20 and Table 2-21.

Table 2-20 Severity and Condition Mappings for Objects

Object Type

Property

Incident

severity

Node Group

status

Node

status

Interface

status

IP Address

none

IP Subnet

none

L2 Connection

status

Table 2-21 Severity and Condition Mapping for Property Values

Property Value

Severity/Condition

CRITICAL

CRITICAL

WARNING

INFO

MINOR

MINOR

MAJOR

MAJOR

NORMAL

OK

DISABLED

UNKNOWN

UNKNOWN

UNKNOWN

NOSTATUS

UNKNOWN