On Thu, 27 Feb 2014 07:23:41 +0100 "Joachim Tingvold" firstname.lastname@example.org wrote:
So, a bit sorry for dragging up this old thread, but I figured it would be as good as starting a new one (-:
And sorry for the late reply!
I'm an old NAV-user (previous "job"), and haven't used it in a while. We use some commercial systems at work, that in ways does the same as NAV (though, most of them does some of the things far more un-userfriendly than NAV). Thinking of trying it out, partly because I know it has some nice features, and partly to try out new/improved features since last time I used it.
Are you working in an academic or enterprise setting? We'd love to have som feedback on your ongoing experience with NAV :)
We also have ~1700 access points, but these are controller-based, so I guess they don't have much use to be added to NAV. I.e. I'm not even sure they speak SNMP for themselves (only via the CAPWAP-tunnel). Maybe only for monitoring of uptime, but, meh, we already have plenty of tools for that.
None of our customers monitor their WLC slave APs through NAV, just the wireless LAN controllers themselves. They prefer Cisco's own WLC-related software to monitor the slaves. Oftentimes, the slaves won't even have their own IP addresses.
Anyways. What hardware requirements are we looking at here? In terms of storage, CPU, memory. I guess we need to have two servers; one for NAV, and one for the PostgreSQL. Based on your experiences with ~900 units; should I expect to double the hardware, in order to handle ~1500 units? Keep in mind that I don't want to upgrade this setup if we go down the road where we add servers as well (but I guess they impose less load per unit, compared to switches/routers that speaks SNMP, so not sure how much more overhead we need?).
There should be no need to double the hardware, the resource requirement is not linear. The single most important thing you can do is have a dedicated PostgreSQL server, so that the database doesn't have to compete with the rest of NAV's processes for system resources. Throw lots of RAM at PostgreSQL, so that the most important bits can be kept cached at all times.
Use reasonably modern hardware, fast disks (or even SSDs) and opt for RAID striping if you can (we use RAID 10 in production).
Also, unless you equip all your servers with SNMP agents that you wish NAV to monitor, they will not cause much load - NAV will just ping them (and monitor any services you explicitly configured it to).
Not sure if the system load is very different depending on what NAV-features one wants to use? 'Arnold' and 'Syslog analyzer' are two things that comes to mind that we won't be using.
These aren't really resource-intensive. SNMP processing and data storage are what make up the bulk of NAV's resource usage.