Server sizing considerations
NNMi server sizing depends
on many parameters, which sometimes cannot be precisely measured and,
more importantly, doesn't give a straight answer as to which server
hardware should be selected. This is a list of parameters which should
be taken into account when you start sizing an NNMi server:
Number of managed nodes
Number of managed interfaces
Number of managed networks
Number of managed segments
Number of managed VLANS
Number of managed HSRP groups
Number of connected ports
Number of simultaneous users
What iSPIs are planned to be used?
HP representatives
use server sizing calculator, which is based mostly on the parameters
listed previously. Calculation output, however, is not accurate. HP
provides several configuration examples on their website, which were
tested, and regarded this as the best source for server sizing. In the
following table, there are three server sizings taken from HP NNMi
documentation. According to these examples, you may decide what server
hardware should be ordered for your infrastructure.
Parameter
|
Small
|
Medium
|
Large
|
---|
Number of nodes
|
Up to 3K
|
3K - 8K
|
8K - 18K
|
Number of discovered interfaces
|
Up to 120K
|
Up to 400K
|
Up to 900K
|
Number of polled interfaces
|
Up to 10K
|
Up to 50K
|
Up to 70K
|
Number of polled node components
|
40K
|
60K
|
80K
|
Number of concurrent users
|
Up to 10
|
Up to 25
|
Up to 40
|
CPU
|
4 CPU cores (2.5GHz for x64, 1.4GHz for IPF or RISC)
|
4 CPU cores (2.5GHz for x64, 1.4GHz for IPF or RISC)
|
8 CPU cores (2.5GHz for x64, 1.4GHz for IPF or RISC)
|
RAM
|
8 GB
|
16 GB
|
24 GB
|
Java heap size
|
4 GB (-Xmx 4096m)
|
6 GB (-Xmx 6g)
|
10 GB (-Xmx 10g)
|
Disk space for application installation
|
5 GB
|
5 GB
|
5 GB
|
Disk space for database
|
60 GB
|
140 GB RAID 1+0 or 5/6 with write cache recommended (4 disk)
|
300 GB RAID 1+0 or 5/6 with write cache recommended (4 disk)
|
Remember, memory is never
enough. So if you have an opportunity, size your server with more
memory than you see in sizing recommendations.
Question: Which Operating System should we choose?
Answer:
Personally, I have neither done detailed tests on NNMi performance, nor
have I met anybody who has neglected the commonly that RISC or IPF
architecture servers perform better than Intel architecture servers.
Also, when you make your decision about OS, consider maintenance costs.
Hardware is only a part of all your costs and I would say not the
largest one. Your headache may increase if you choose OS which you are
not familiar with, or have no professionals who are familiar with it. If
you are a Windows guy, go for Windows. If you are more experienced with
Linux, choose Linux instead. All of them work and having your favorite
OS on operations will reduce MTTR (Mean Time To Repair) and probably MTBF (Mean Time Between Failures), and will increase your satisfaction working with NNMi as well.
When
choosing an OS, also takes into account the iSPI you plan to use. Some
of them are OS-specific and you may be forced to choose a specific OS.
For example, iSPI for Multicast works only on Windows OS. Read iSPI
latest release notes before you make a decision.
How NNMi will impact my infrastructure
Designing management tools, such as NNMi, are not only about sizing a server. The following are important issues as well:
Traffic consumption by the monitoring tool
Security policy changes in your infrastructure
Data storage space for system backups
Infrastructure device naming convention
Traffic consumption by the monitoring tool
When you design an NNMi
system, you should also take into consideration the system impact to the
whole infrastructure. For example, NNMi polls devices on a regular
basis and receives SNMP traps as well. Depending on your monitored
infrastructure size, polling cycle, and SNMP trap flow, you can overload
your network bandwidth. Due to this, you should estimate if you can
afford such traffic consumptions during system design stage.
There is no accurate
traffic load calculator, as NNMi optimizes its polls grouping into SNMP
query bulk reads. Using this method, it is hard to estimate traffic
load. The only way to get a real number is to try it in a lab or
operational environment. Traffic generated by NNMi depends on:
Number of polled interfaces
Polling frequency
Data collection objects (if iSPI Performance for Metrics is used)
Data collection polling intervals (if iSPI Performance for Metrics is used)
So, if you notice that NNMi consumes too much traffic, try reducing one or more parameters listed previously.
Security policy changes in your infrastructure
Before you start NNMi implementation, make sure your firewall has following ports opened:
TCP Ports 80, 443, 1098, 1099, 3873, 4444, 4445, 4446, 4447, 4457, 4458, 8083, 8086, and 8087
UDP Ports 161, 162, 696, and 45588
Antivirus software
slows NNMi performance or even stops some of the functionalities. So
before you start NNMi implementation, make sure that you have disabled
your antivirus. This is a very important point. If you have any issues
launching your NNMi server, the first thing that should be checked
(after you checked whether all services are up and running)—is if you
have antivirus running.
Data storage space for system backups
You will also probably
design an NNMi with regular backups, which have to be stored in some
external data storage. Consider a dedicated safe data storage place for
your backups.
Infrastructure device naming convention
Another recommended, but not
necessary, task is to make sure that your managed nodes follow your
infrastructure's naming convention. There is no technical limitation and
NNMi will work in either of the following ways:
No naming convention at all
Device names were changed after NNMi completed node discovery
Naming convention was applied before NNMi implementation
This recommendation is about
your own convenience. First of all, you will need to make sure that node
names have changed in NNMi after you changed them on managed devices.
Then, if you have used some long-term data for analysis, name changes
will make a mess in your reports. If you have implemented some
integration with third party tools on your own, you may have some
integration issues if your API wasn't designed to be ready for node name
changes.
Licensing policy
NNMi is licensed by discovered
nodes. One node-one license and it doesn't matter whether it is a switch
with several dozens of interfaces or just a workstation with one
network interface. It is a good practice to design the network discovery
to discover only nodes which are needed to monitor and avoid any
additional nodes as much as possible, for the following reasons:
You may reach your
license limit very fast. Please be aware that unlike NNMi 7.x and its
previous versions, NNMi 8.x and newer do not discover any additional
nodes when the license limit is reached.
The
more devices that are being polled, the more the server is loaded. In
other words, by monitoring unnecessary nodes, either the server works
slower, or extra hardware is purchased for upgrades to maintain system
performance.
Also, keep in mind that
NNMi counts nodes that are discovered. So even if you have set a node to
an unmanaged mode, it is still counted against licensing policy.
NNMi installation comes with a 250
nodes license for 30 days, and it includes NNMi Advanced and NNMi iSPI
NET features for the same period of time. You don't need to reinstall
NNMi if you have decided to add your permanent license on top of the
trial version, even if your permanent license has the standard edition.
To check what license is installed currently, go to Help | About HP Network Node Manager i-series:
Licenses are sold by 50 node
incremental, that is, if you monitor 125 nodes, you need 3 by 50 nodes
licenses. As soon as the amount of your discovered nodes is over 150,
you will need additional 50 nodes licenses (even if you have just one
node over; that is, 151 nodes require 200 nodes licenses).
iSPIs
are licensed separately and each of them has its own licensing policy.
Read each iSPI's release note when you size your system or contact HP
representatives if you need assistance counting required iSPI license
capacity.