I recently saw a question pop up on the SolarWinds community forum, Thwack, asking if the SolarWinds database could be virtualized. It absolutely can and I would say these days it is becoming increasingly rare for people to dedicate a physical host to their monitoring database.
Despite how common it is to do, one of the issues I often run into at client sites is poorly configured SQL servers. So that prompted me to put this post together to try and point out some of the common sticking points that people have when setting up a virtualized SQL database for SolarWinds. Much of this info will apply for any SQL database, but I’m going to be focusing on things I have found to be specifically relevant to SolarWinds.
Building the Server
It should go without saying, but check the current admin guides for the modules you intend to install and make sure you meet at least the minimum specs listed.
I think there is a bit of a sense that “It’s only the monitoring platform” so people seem reluctant to allocate the necessary resources but if you short change your database on any of those requirements you will absolutely feel it when you are browsing the web console and running reports.
Also, remember to revisit your system if your monitoring environment grows over time. The amount of memory needed to run NCM for 100 switches is probably not going to cut it if you increase the license counts and add NPM, NTA, and SAM for the entire department a few years later.
CPU and memory requirements are pretty straight forward, just make sure your hosts aren’t overallocated. For environments larger than 2000 elements the admin guide breaks down a disk configuration that uses 6 separate logical disks.
The first mistake I frequently see with virtual SQL servers is that people map all 6 of these to the same generic datastores that they use for anything. This kind of layout can work if your storage admins are on top of things and your shared storage has a good auto tiering policy and high speed resources to burn.
On the other hand, many people find themselves in environments where storage resources are more limited and making sure your disks are set up correctly is a major factor in the responsiveness of your application. If all the logical drives are mapping back to a small pool of physical disks that can’t support the workloads then you haven’t accomplished anything useful.
SolarWinds recommends you split up your system drive, pagefile, database, transaction logs, tempdb file, and tempdb logs. I/O loads on the database and log files will be significant so for these drives you will want to use a high-performance raid type such as 0,1, or most commonly 1+0.
In any case, you do not want to be using Raid 5 or 6, they hurt performance too much for this use case. I routinely see Orion databases running steadily over 1,000 IOPS so you will want to plan storage resources accordingly.
So, moving ahead a bit, your VM is ready, SQL is installed, the SolarWinds application is installed on your primary polling engine, and the database was created during that installation. There are a few things that many people do not know how to do that can be important.
The first thing you should do is set up a SQL maintenance plan. SolarWinds has a built in database maintenance that it performs nightly, but there are some steps that need to be done within SQL. This link from SolarWinds goes over the basics of setting up a scheduled maintenance in SQL.
You have the option to set up index defragmentation here as part of the SQL maintenance or you can enable it as part of the Orion maintenance plan as documented here, either method works fine.
One of the parts of the SQL maintenance you will need to do is set up your backups. I shouldn’t have to explain to you why running without backups is going to be a bad move.
One of the perks of virtualizing your server is that backing up and restoring can be pretty painless, so you can do database backups in SQL or if you have a VM image level backup feel free to use that. Whatever backup method you choose make sure they are completing as scheduled and tested periodically. With those considerations in place your virtualized SQL server should be ready to roll.
Field Systems Engineer