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.
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
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.
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).
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:
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.
Configure the Operations Center server to not restart automatically.
For more information, see the Operations Center 5.0 Server Configuration Guide.
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.
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.
Install, configure and start the OvORB on the NNM server machine.
For instructions, see Section 10.0, ORB Installation.
Start the Operations Center server and launch the Operations Center console.
Create an OpenView Network Node Manager adapter for each instance of NNM.
For instructions, see Section 5.1, Creating an Adapter.
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.
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 |
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:
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.
Delete the adapter instance.
Create a new NNM adapter.
Use the same adapter name as the legacy adapter.
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.
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.
The Operations Center
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 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.
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.
To reload all OpenView alarms in Operations Center to restore missing alarm information:
In the
pane, right-click the top-level server manager element for the NNM adapter, then click .All alarms reload from HP OpenView to the NNM adapter.
To configure the HP OpenView ovalarmsrv process to write out alarm state more frequently:
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
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:
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
Start the OvORB.
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 |
The following are suggestions for resolving common problems that occur in the integration:
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
option in the NNM console to update the status.If submaps are not found, perform the following steps:
Verify that persistent submaps are on for all levels.
From the NNM console, click
> to open the Map Properties dialog box.Select
under , then click .Verify the
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. |
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:
. 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
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>
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
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
Adapter property to .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.
To integrate NNMi:
Start the Operations Center server and launch the Operations Center console.
Create an HP NNMi Integration adapter for each instance of NNM.
For instructions, see Section 5.1, Creating an Adapter.
Modify the HP NNMi Integration adapter properties.
For instructions, see Section A.14, HP Network Node Manager i-series.
Start the HP NNMi Integration adapter.
For instructions, see Section 5.2, Starting, Stopping, or Deleting an Adapter.
Each running integration instance has four top level folders:
, , , and .and 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.
and are object-based element tree branches.
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 element branch, even if that node is a member of more than one node groups.
element branch represents the hierarchical parent/child structure of Node Groups and Nodes in the same structure as the NNMi web based client’s / 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
and branches by editing the and adapter properties.Create
subfolders for inventory objects using the 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.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.
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
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 |
|
Node Groups and Node Group Inventory Alarms |
None |
Node Elements and Node Inventory Alarms |
|
Interface Elements and Interface Inventory Alarms |
|
IP Address elements and IP Address Inventory Alarms |
|
IP Subnet and IP Subnet Inventory Alarms |
|
L2 Connection and L2 Connection Inventory Alarms |
|
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 |