How to optimize SAF NMS server load

Large network monitoring and maintenance requires a sophisticated network management system (NMS). Therefore, the NMS server hardware selection should not be done in a hurry, as nobody would like to experience the placidity of the server at the most unsuitable time.

To ensure that NMS manages the network as efficiently as possible, the first step is to choose the right hardware, considering the size of the existing network and its possible expansion. Over time, SAF Tehnika has defined the following hardware and software recommendations for the proper operation of SAF NMS:

Table 1. SAF NMS server hardware and software requirements.

It is not easy to estimate the exact technical requirements for the NMS server to achieve the desired performance, because there are many variables:

• the number of monitored network elements (NEs),
• the amount of polled parameters for each NE,
• the selected polling frequency / interval for each parameter.

Additionally, SAF NMS has passive and active monitoring processes: the first one is a trap listener, the second is a polling process. Trap listener receives traps and generates alarms in the SAF NMS, as a result you cannot determine how much space in the HDD you will need, because you cannot predict how much traps you will receive. As SAF NMS registers each of them, less traps requires less space on the HDD.

Fortunately, it is possible to calculate the storage required for the active poll process, because it sends requests and processes responses continuously according to user defined polling frequency. Each polled parameter value is written in the database. SAF NMS uses the MySQL database management system (DBMS) for data storage, which increases over time depending on the number of monitored NEs and the list of polled parameters.

For simplicity, let's imagine that the monitored network consists of 1000 NEs and each NE polls parameters for 1 KB per minute. For all NEs it would roughly result in 1 MB per minute, 1.4 GB per day, 40 GB per month, 500 GB per year. To get an idea of the required additional storage for the SAF NMS database, see the table with approximate database sizes.

Table 2. Estimated SAF NMS database size depending on the number of monitored NEs within a specified period.

SAF NMS supports database housekeeping (archiving) procedure, which periodically cleans up all time-series data tables and saves cleaned-up data into files or data warehouse if configured properly.

Such a procedure keeps the size of the database constant in time, unless the amount of monitored NEs has not changed. If the monitored network is large, it would be worthwhile to reduce the default housekeeping procedure period (12 months), as without a network-specific housekeeping settings database will become slower and slower due to ever-increasing data.

An example of SAF NMS server default data archiving settings.

One more option to prevent the NMS server from being overloaded is related to its architecture.

The DBMS and NMS server can be installed separately for distinguishing the NMS Server service part from the MySQL DBMS. In this case, the operation of NMS Server will not be affected by resource-consuming MySQL activity.

Another significant way to improve the efficiency of SAF NMS server utilization is to optimize the polling parameter list.

A shorter list of polled parameters and increased poll periods will slow down the growth rate of database size and may relieve also the HDD usage by MySQL.

It should be noted that such an approach would result in a resolution reduction of performance graphs, which represent monitored parameter historical values. Consequently, performance graphs may miss the drastic parameter value changes.

If it is necessary to get high-resolution graphs with real-time values (not historical ones), the "Live graphs" module should be used because it gets parameter values directly from devices and does not store values in the database, accordingly this module does not load the server HDD.

An example of SAF NMS section for customizing poll parameter list.

Summing said above - not polling too often, and not saving too much data by selecting the most prior poll parameters is the key to optimizing NMS server functionality. It follows that choosing the suitable hardware and software, determining your own monitoring needs and selecting the proper poll parameters with the appropriate polling frequency is extremely important and is a kind of Herculean task that can simplify someone's life if done well.