Network Management Center Blog : iSPI Performance

NNMi integration with HP System Insight Manager ( HP SIM)

aruna13 — Fri, 11 Sep 2009 04:40:00 GMT

Hi,

I have had several questions lately asking about the integration between NNMi and HP System Insight Manager.

The HP NNMi–HP SIM integration provides actions for accessing several SIM tool from the NNMi console. Wit this integration,

NNMi users can detect and investigate potential network problems for HP ProLiant servers and storage devices.

Detailed documentation outlining this integration can be found in our latest version of deployment and configuration guide at:

http://support.openview.hp.com/selfsolve/document/KM763632/binary/nnmi_deployment_guide_81x_p5.pdf .

Read chapter à Integrations and Plug-ins à HP System Insight Manager

Thanks,
Aruna Ravichandran
Sr. Product Marketing Manager
Network Management Center,
HP Software
aru@hp.com

NNMi / NNMi Advanced / NNM iSPI Performance patch available has new functionality

Michael_Procopio — Mon, 16 Feb 2009 03:58:00 GMT

Network Node Manager i (NNMi) 8.11 is now available. This applies to NNMi, NNMi Advanced and NNM iSPI Performance. In addition to a variety of defect fixes, we have included some new functionality. All of the new functionality is turned off by default, so check the docs to see how to turn on what you want.

Some of this functionality may have been discussed before but for completeness…

• Custom poller collection (NNMi NNMi Advanced) – this allows you to pick an OID you would like to poll and set a threshold. You can also define the state of the OID based on a returned value and have that state reflected on the node and/or create incidents. This is useful if you have some special metric you want to monitor and be alerted when it goes off your norm.

We had many requests for this functionality. There is a new doc just for this called - Online Help: Custom Poller for Administrators. In addition, a whitepaper called - NNMi Step-by-Step Guide to Using the NNMi Custom Poller White Paper. You can find these at the same place as all the manuals at the Selfsolve site.

• Application Level Failover (NNMi, NNMi Advanced) – this is the ability to have a backup NNMi system monitor the primary and assume polling et al if the primary is unavailable. This is useful when your organization doesn’t use a cluster technology for failover. Read the post on Application Level Failover

• Enhanced Network Automation Integration (NNMi, NNMi Advanced) – this includes a variety of integration capabilities but there is one I think is really cool – automated duplex mismatch detection. (Note this requires the iSPI Network Engineering Tool Kit).

• MyBSM Integration (NNMi, NNMi Advanced, NNM iSPI for Performance). What is MyBSM? It is portal in our BAC (Business Availability Center) product. NNMi and iSPI Performance windows are now also portlets that are usable by the MyBSM portal. In addition, you can create new portlets.

• Enhanced Performance Insight integration (NNM iSPI for Performance) – this is near and dear to my heart as I was previously the product manager for both these products. In NNMi 8.10, device metrics were added to iSPI Performance. However, the existing Datapipe that brings information from iSPI Performance to Performance Insight only brought interface data over. Now device metrics move to Performance Insight and are shown in the Device Resources reports.

• LDAP support - Support for users, passwords and roles from an enterprise directory service through Active Directory.

• Alcatel Device Support

• Migration tools to help you migrate from 6.x/7.x to 8.x

nnmmigration.ovpl - Runs on the NNM 6.x/7.x system and calls several other migration tools
nnmtrapdload.ovpl - Imports NNM 6.x/7.x trapd.conf definitions as Incident configurations. See the nnmtrapdload.ovpl reference page
nnmmibmigration.ovpl - Imports the MIB definitions from the NNM 7.x snmpmib file.
snmpCapture.ovpl - Lists the NNM 6.x/7.x community strings.
nnmmapmigration.ovpl - Runs on the NNM 6.x/7.x system to gather node group and background information about the NNM 6.x/7.x location submaps for one OVW map

You can find the patches at http://support.openview.hp.com/selfsolve/patches - Search for NNM810W_00002 (updated)

For the Network Management Center Michael Procopio, LinkedIn.com/in/mjprocopio

Join the other conversations

Operations - hp.com/go/ITOpsBlog

Business Service Management - hp.com/go/BSMblog

Application Failover Support Feature – 8.11

Michael_Procopio — Mon, 16 Feb 2009 03:41:00 GMT

NNMi Application Failover is a new feature introduced with NNMi/NNMi Advanced 8.11. NNMi Application Failover functionality gives you the ability to setup two NNMi management stations, namely Primary/Active node and a Standby/Backup node. If the Primary management server crashes, the Backup server will automatically startup and resume NNMi functions (trap handling, analysis, discovery, polling, etc.). The two NNMi systems (Active and Standby) monitor each other using a “heartbeat” signal over the network. If the Active node fails (loss of heartbeat), the Standby node will automatically start NNMi. The Active as well as the Standby server instance uses the embedded Postgres database by default.

Note: Application Failover feature monitors system availability, not the availability of NNMi instance itself; i.e. if NNMi instance crashes or is killed, but the system remains online, Application Failover will not detect this.

How does this work?

The Active node performs periodic database backups
These backups are sent to the Standby node.
Between backups, periodic database transaction logs are created and immediately sent to the Standby node.
If the Active node crashes or is shutdown, Standby becomes the New-Active node
The New-Active node starts NNMi, including the database server.
The database server imports all the transaction logs and is available to NNMi for requests.

Does the Application Failover Support WAN?

The 8.11 release only supports LAN (same subnet). Going across a router is not supported at this time. Future releases will look into adding support for WAN.

What is the compatibility matrix for the active server and the standby server?

OS-consistency across the active and standby server is enforced. Both server need to be HPUX-to-HPUX, Linux-to-Linux, etc. Mix mode OS configuration such as Windows-to-Linux is not supported.
NNMi version and patch level needs to be the same across both servers
Licensing needs to consistent. If license (capacity or features) on Standby is less than Active, nodes will get unmanaged on failover. Eg. if the Standby node has lower node count and/or a subset of features (iSPI-NET, iAdvance, etc.) then when that node becomes Active, those features will be disabled and/or nodes will become unmanaged.
Both servers need to have the same “system” password

How are the 2 servers licensed?

The main Active server will need to have a production license equivalent to the number of nodes that it needs to managed. Standby uses non-production license. The node counts for the Active server and Stand

What if I want to use another external database such as Oracle instead of Postgres?

Application failover is not supported on any external database like Oracle and is only supported with the internal Postgres Database. If there is a need to use an external database such as Oracle, other supported clustering technologies such as MC ServiceGuard for HPUX or Microsoft Clusters (MSCS) for Windows or Veritas for Linux can be used.

Is the application level failover supported for NNM iSPI products?

All the iSPIs (except iSPI Performance) get “free” support to the Application Failover feature as long as they follow the following two conditions:

They use NNM’s Postgres database (then their data is replicated along with NNM’s data)
They use ovstart/ovstop to start/stop their services

iSPI NET as well as the iSPI for Performance do not support Application Failover feature.

In order to avail the Application Failover support of NNMi with iSPI Performance, the following could done:

iSPI Performance must be installed on a 3^rd node (same subnet), without NNMi (cannot co-exist on the same server)
The two NNM nodes both run the script “nnmenableiSPI Performance.ovpl” to point to iSPI Performance station
iSPI Performance is (initially) configured to point to currently-Active node
iSPI Performance detects an NNM Cluster environment, and periodically polls “who-is-current-Active?” using a special command.
When the Active node changes, iSPI Performance reconfigures itself to point to the new-Active node.

Do we support Oracle RAC?

Oracle RAC support is not available at this time.

I am Aruna Ravichandran, the Product Marketing Manager for NNM/NNMi/iSPI products within the Network Management Center for HP Software. I have been with HP for 13 years. I started my career as an engineer in the HP-UX kernel lab, moved on to do application development and was an architect in the High Availability/Clustering lab for couple of years. I then wanted to experiment the “darker” side of the business and moved to product management/Product marketing 5 years ago and marketed Storage products – high end disk arrays (XP) followed by Security Marketing where I created a secure appliance solution for enterprise log management and took it to market. I recently joined the Business Service Management (BSM) organization of HP Software. I have to say that I am still a “techy” at heart, though I totally love the “darker” side of the business.

We have to other conversations you can join. For Operations ITOpsBlog and for Business Service Management the BSMblog.

iSPI for Performance - Report types and when to use them

Michael_Procopio — Fri, 13 Feb 2009 16:19:00 GMT

In the week where nearly 2 million people converged into the (relatively) tiny area of The Mall, in Washington DC, I couldn't help but think about the additional load put on the communication infrastructures in the area for that day. It brings the ideas of 'busy hour' and 'peak load' into sharp focus.

If you're a network manager who happens to have the Performance SPI recording and reporting upon your network then you just might want to go back to Tuesday the 20th of January and take a look at some of the usage patterns. You'll find that the SPI stores data in three distinct ways which are used for different needs.

When you launch the Report Menu you see a series of tabs, each tab represents a different reporting area. The first is 'Component Health', providing reports on things like CPU, Buffer and Memory from device sensors. The second is Interface Health, providing reports based primarily upon MIB-II data from the ifTable - utilization, discards and errors; the last is the Diagnostics tab which has reports on the iSPI for Performance system itself.

Each tab contains a series of thumbnails, representing the various reports you can access. The thumbnails have up to three words below them:

Live

Summary

Dog lover sees bright spot in Network Management economy

Michael_Procopio — Fri, 06 Feb 2009 07:20:00 GMT

I was just reading an article by a fellow dog lover Tracy Corbo of IDC called Technology That Is Relevant in a Recession - Network Infrastructure Management

She points out something that I have been thinking about, that is, in this recession the more selling and other operations that can be moved to the network, the more money can be saved.

There are a couple results of that sentence. One, we are in a recession. That means budgets are tighter including for IT so throwing hardware at a performance problem to make it better –- maybe not.

Two, the network's importance goes up. The American saying is "don't put all your eggs in one basket" – in this case don’t put everything on the network, but we don't have much choice. The cost of moving all those network interactions to phone calls would be astronomic. According to the book Net Income Cut Costs Boost Profits By Wally Bock and Jeff Senné, the average cost of going through a customer call center is US$20. I don't have an exact reference for a number for web transactions but I bet it is less than $1, that is a 20:1 cost increase.

Three, therefore managing the network becomes critical to organizations. And that means network management software is pretty important to have.

The support for this conclusion: a number of network management vendors have recently reported strong earnings. Actually, this was Tracy’s main point.

Here are some tidbits from our customers on how NNMi helped them (paraphrased):

·Health Care Customer: It is nice to have NNMi find a down device before someone needs to go use that lab.
·Beta customer: We found 6 bad power supplies and a couple bad fans using the software, if the redundant units had gone down we have a network down and a scramble. Now we can send a tech out to replace the units in a planned way.
·Internal testing - using the NNM iSPI Performance we found links with duplex mismatch. [Duplex mismatch will create packet errors due to collisions and can exhibit as weird performance problems.] We found them before we put the links into production saving a lot of headaches trying to track them down.

If you have any cost savings examples please put in a comment. Or if you like contact us about being a guest blogger.

For the Network Management Center Michael Procopio, LinkedIn.com/in/mjprocopio

Join the other conversations

Operations - hp.com/go/ITOpsBlog

Business Service Management - hp.com/go/BSMblog

NNM iSPI for Performance - The new kid on the block

Michael_Procopio — Mon, 19 Jan 2009 01:45:00 GMT

If you've seen the latest revision of Network Node Manager i 8.x, then you know that us folks in the R&D labs have been burning the midnight oil. There are a ton of new functions and features, but the one that is closest to my heart is the iSPI Performance. This performance monitoring add-on to NNMi made its debut with NNMi version 8.01 and is following up with a second, enhanced release to coincide with NNMi 8.10.

As an architect within the Network Management Center, and an engineer on the team producing the iSPI Performance, I'll be making regular blog entries on this new product line and how it can help your network environment. Occasionally we might veer off into uncharted territory but that is as much up to you as me.

Today I'm covering the various launch mechanisms for the iSPI Performance from NNMi.

Following the installation of the iSPI, your NNMi box will begin to collect performance data and the iSPI will receive and process this data. You can control the collections using previously grayed out toggle buttons in the monitoring configuration windows of NNMi. But how do you get access to this data? There will be a new 'Action' in your drop down list called 'Reporting - Report Menu'. Clicking on this action will launch a browser displaying a catalog of reports which are available, some show live data (highly granular and right up to the minute), while others show hourly grain summary data over a much longer period. You'll also see archival reports with the fine grain collected data available over an extended period.

This 'Report Menu' is your main launch point into the iSPI Performance reports. If you have selected an element within NNMi then that's going to get passed through to the report and everything you view will be filtered to just that element. When I say element, I mean a node, a node group, an interface or an interface group. You can launch the 'Report Menu' action from the maps, from an incident or from any of the tabular lists within NNMi. So let's say you see an incident on NNMi saying that an interface has gone down - you can now launch directly into the iSPI Performance reports and check the historical availability of that interface to see how frequently this has been happening and for how long each time.

There's one other launch mechanism to launch from NNMi to the iSPI Performance that won't show up immediately - that’s the Path Health report action. If you're looking at a path view on NNMi you will now have a new action - 'Reporting - Path Health'. Selecting this will pass all the nodes and interfaces along your path into the iSPI Performance and you'll see a report on historical usage and exceptions for each node and interface. Now, in one easy step you can see the complete performance for everything along an entire path and pinpoint where the failure is.

Next time I'll talk more about data granularity and what the three types of reports are (Live, Summary, and Archive). If you've seen the iSPI Performance then let me know what you thought, if you have questions or suggestions for future posts then leave a comment.

Cheers - Damian (For the Network Management Center)