Understanding Smart Plug-ins (iSPI)
iSPI is a Smart Plugin, which can be installed on top of the Network Node Manager for feature expansion.
NNMi has a pretty long list
of features, especially when we consider the information it provides in
regards to network topology and all other information related to it.
Every network is unique in terms of technologies it uses and purposes it
is designed to. For example, carrying voice over IP, where voice
converges with IP networks. MPLS is another unique technology, which in
some terms can be treated as a separate science and needs additional
management approach. Multicast is another story, with its own features
and headaches from an operations perspective.
All these technologies and
features are not rocket science, but it is really an additional effort
to be developed as a management tool. Most of NNMi users have hardly any
of these technologies, so why should they pay for features they never
use?
Mostly, SPIs use NNMi's
discovered nodes and their configuration as a primary source of
information. Also, iSPI provides some information back to NNMi, that is,
additional features or technology configuration, configuration changes,
performance parameters, or alarms.
Here is a list of major SPIs:
iSPI for MPLS:
Allows users to discover and monitor MPLS-specific objects and
parameters. For example, L2/L3 VPNs, MVPN, Pseudo wire VC, VRF, PE-CE,
PE-PE links, and so on.
iSPI for IP Telephony:
This iSPI discovers and monitors VoIP-specific objects and parameters.
It supports VoIP monitoring from Avaya, Cisco, and Nortel vendors.
iSPI Network Engineering toolset:
This iSPI is a set of additional tools, which allows NNMi operator to
initiate some routine actions, which helps in troubleshooting issues.
iSPI for Performance:
After NNMi version 8.11, this iSPI has been divided into two separate
iSPIs: iSPI Performance for Metrics and iSPI Performance for Traffic.
These iSPIs collect and report performance specific data—Network Engineering Toolset (NET). This iSPI provides additional troubleshooting and diagnostics tools for network engineers.
iSPI for Multicast:
This iSPI provides multicast network specific features, such as
discovering and monitoring IP multicast routing topology, multicast
enabled nodes, PIM interfaces and neighbors, and so on.
Questions such as"Do I need SPI? If so, which one of these to choose? Will it do what I expect?" are ones commonly asked while designing NNMi. Let's take a look at the major SPIs.
iSPI for Performance
Before NNMi 8.11,
there was iSPI Performance, which was introduced as two separate iSPIs
on later NNMi versions. Legacy iSPI performance was collecting
performance metrics based on SNMP queries on managed nodes. Later on, HP
introduced the ability to collect data from flows, as flow data has a
different list of features than performance data collected by SNMP.
These iSPIs are:
iSPI Performance for Metrics: Legacy iSPI performance with few improved features.
iSPI Performance for Traffic: iSPI, which collects, analyzes, stores, and presents flow data.
Let's take a look at both in detail.
iSPI Performance for Metrics
The iSPI
Performance for Metrics adds the performance management capability to
NNMi by analyzing, processing, and aggregating metrics collected by NNMi
from different network elements. This release of the iSPI Performance
for Metrics includes the following features:
Path health reports
Component health reports
Interface health reports
Custom polled reports
Also, unlike in previous NNM
versions (7.x and earlier), we cannot trigger alerts based on
performance data in basic NNMi versions. That is, we need to receive
alarms when the device CPU load exceeds 95%, the interface utilization
exceeds 70% or comes below 5% for longer than one hour. Default NNMi
can't handle it. iSPI performance brings this feature into NNMi. Now, we
can say that NNMi and iSPI Performance both together cover fault and
performance monitoring areas.
The network performance data adds more functionality for network management. It improves your network management by:
Allowing operators to retrieve more data during investigations
Enriching your monitoring by providing alerts based on performance data
Providing
information to network planners and analysts, where they can see
long-term statistics, which makes future planning more accurate
iSPI Performance collects,
stores, arrays data, and presents it in drill-down reports. Using data
mining in reports, we can drill down until we reach the node or
interface, which causes issues.
Users have relative
flexibility in creating their own reports, as custom SQL queries can be
created on reports by user-specific needs, such as a report with custom
time period, or metrics, which are monitored. iSPI reports are reached
from the NNM console, and no additional logins and passwords are needed
as iSPI recognizes usernames or passwords used by NNMi. Reports running
after they are selected and take up to 15 to 20 seconds. To eliminate
this query at runtime, you can schedule the report to run in advance, as
the scheduled report is displayed immediately.
All monitored metrics
can trigger threshold alarms, so operators can be notified before real
impact occurs. Performance-based alarms also reflect the status of the
nodes, which makes the map status more accurate for monitoring.
Previous NNM versions (7.x and earlier) represented node status only based on status poller results.
Earlier NNM versions used
to cause a lot of confusion when performance-based alarms indicated
possible outages or upcoming service impacts, and map icons remained in a
normal (green) state.
NNMi iSPI Performance
for Metrics may be licensed to monitor a smaller number of nodes than
its corresponding NNMi. Consider, if you are a service provider and only
a small part of your managed nodes has a requirement to be monitored
features, which are supported by iSPI performance for metrics. Buying
licenses for all the nodes would be a waste of money. Another wasteful
example would be, if your NNMi, except routers and switches, also
monitors a Users have relative flexibility in creating their own
reports, large number of workstations or servers which don't need to be
covered by iSPI Performance for Metrics.
NNMi can be configured to poll
vendor proprietary MIBs, issue a threshold incident, set status on the
map to alert operations, report on values and with NNMi iSPI performance
for metrics.
iSPI is not a
replacement to HP Performance Insight (OVPI), but depending on
particular requirements, sometimes iSPI Performance for Metrics may be
used as an alternative to OVPI. The following table provides high-level comparison of iSPI Performance for Metrics and OVPI:
|
NNMi iSPI Performance for Metrics
|
Open View Performance Insight
|
|---|
|
Tightly integrated with NNMi
|
May be integrated into NNMi as well as can be a separate product
|
|
Short to medium term data is stored
|
Long-term data is stored
|
|
Collects MIB data using SNMP
|
Customized data collection methods can be used, that is, Operations Manager or Performance Manager agent
|
|
Designed to be used for proactive monitoring and generating alarms
|
Designed for long-term reporting
|
|
Tool very handy for operations
|
Tool for operations, analysis, planning, and reporting to management
|
If you are, or plan to be
an NNMi system administrator, you should be prepared to be asked whether
or not iSPI Performance for Metrics loads a network with extra ICMP or
SNMP traffic. Although the answer is yes, iSPI queries extra
information, but on the other hand, it wouldn't load a network as much
as it would separate a tool from a third party vendor, because iSPI uses
the same SNMP process to collect performance and status information. It
means that it eliminates extra polling, as the data is queried and
responded using same packet bulks.
iSPI Performance for Traffic
By introducing this
iSPI, NNMi took a step into network service monitoring. This iSPI uses
flow data and can detect reports such as performance issues, like
separate traffic types HTTP, mail, and FTP traffic. It can report about
top sources or destinations, and so on. So now, the NNMi operator can
take a look on what's happening inside IP traffic, as iSPI Performance
for Traffic analyzes flow data. The following flow versions and vendors
are supported:
iSPI Performance for Traffic is very useful for troubleshooting network issues, such as:
These issues are a
headache not only for operators, but for network or service analysts and
planners as well. If your data channel is divided into traffic classes
based on traffic type (that is, 20% of traffic for HTTP, 30% for mail,
and so on), this iSPI will also tell you about your traffic classic
behavior.
Example: Why is my HTTP
browsing is so slow, while my interface utilization is below 70%?
Answer: HTTP traffic is configured to take max 30% of your bandwidth,
and HTTP takes all of it while other traffic classes are less loaded,
which makes total bandwidth utilization less than 100%. So, instead of
constant questions and unclear situations, iSPI Performance for Traffic
gives a clear answer, with evidence, that it is time to change traffic
class allocation limits. This can be seen in the following diagrams:
This iSPI can be used
in conjunction with iSPI Performance for Metrics, which provides
navigation between Metric and Traffic data.
iSPI Performance for Traffic cannot trigger an alarm.
Traffic generates performance reports from the IP flow records as follows:
Aggregates the IP flow record.
Correlates obtained IP flow records with NNMi topology for context-based analysis.
Enriches
the IP flow records by providing the ability to add or update the
available fields in the flow records. For example, DNS name resolution
and application mapping.
Flow data is collected
using flow collectors, which can be designed as two tier collectors:
local and master. NNMi supports either of the two scenarios: co-located
and non-co-located deployment of leaf, master collectors, and NNMi, as
well as NNMi iSPI Performance server. The following figure represents
the two-tier, hierarchical flow collection and processing:
Leaf collectors: They are responsible for flow filtering, application mapping, DNS name resolution, and summary data feed to master collector.
Master collector:
This collector is responsible for collecting and correlating all
summary records as central point from all leaf-level collectors.
Common NNMi iSPI Performance Reporting Server:
This server is responsible for building traffic analysis reports, which
are done on the same server as iSPI Performance for Metrics.
Multiple leaf collectors per physical machine can be supported.
Can this iSPI be used as a
replacement to OVPI? General answer is no. However, there may be some
cases when iSPI Performance for Traffic may cover the required features.
The following table provides a general comparison between iSPI and
OVPI:
|
iSPI Performance for Traffic
|
Open View Performance Insight
|
|---|
|
Tightly integrated with NNMi
|
May be integrated into NNMi as well as can be separate product
|
|
Short to medium term data is stored
|
Long-term data is stored
|
|
No alarms can be triggered
|
Alarms can be triggered based on threshold settings
|
|
Focused on flow collection
|
Focused on long term trending, forecasting and capacity planning
|
|
Tool, very handy for operations
|
Tool for operations, analysis, planning and reporting to management
|
|
Supports Net Flow (v5, v9) and sFlow (v5)
|
Supports Net Flow (v5) and sFlow (v5, with IUM collector)
|
