Server Requirements

clerum

Just curious what your opinions are with requards to server speed, and network size reqirements.

Currently I'm running on a Windows Server 2000 1Ghz P3 with 1GB of RAM. SQL 2000 runs on this box as well. It's only a 100 node license, but I'm polling all devices every 10 sec, and interface stats every minute. Basically it's our core network nodes, and I want to catch everything. DB size hovers just below 600MB. It does the polling fine, but the webpages are kind of slow to load.

I the next 2 months we will be upgrading to the 250 then SLX versions of the software, and migrating off of HP Openview where we currently monitor customer connections (about 1000 of them, and growing fast). These will be polled about every 3 minutes, and interface stats every 5 minutes.

The box I'm currently eyeing is a dell 2850 specs follow:

Dual 3Ghz Xeon
4GB of RAM
Server 2003
SQL 2000
280GB of Storage

It's going to be a staged rollout with this box doing everything, then offloading the DB to another server at some point, and a remote poller as well for an distant operation.

What do you think, will it handle it?

iunderwo

Polling every 10 seconds is going to clobber that machine if you load it up fully.

Consider the Orion docs specify a 3GHz server for under 10k elements, with a remote SQL database and a polling/stats interval of 9 minutes. Your current license will only allow a maximum of 300 elements, so this isn't too bad right now. Add

For the amount of stuff you want to implement, you're better off building the SQL server now instead of trying to move it and eat up another license later. 600mb isn't much of a DB, but moving a ton of customer connections will balloon that number quickly into the multi-gig range. Granted, this depends on how often you do status rollups.

Bear in mind, that the more granular stats you have, the longer this is going to take to process during the nightly update. I would like to see DB maintenance made a separate application which can be installed on the SQL server itself. The local access will save a lot of time in the process, and won't bog down the poller box.

Remote pollers are generally a bad idea unless you plan to implement a high-availability, distributed SQL server. The ratio of polling traffic to DB traffic is about 1:10 in my experience, and can easily chew up a megabit or two of bandwidth. Also, losing access to the DB doesn't help the poller's stability, especially since the poller isn't designed with this in mind.

// Ian Underwood - Service Management
// Level 3 Communications