cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 12

Why does SolarWinds recommend hosting the Orion database seperately ?

Jump to solution

I have been running Orion for more than a year now and would like to co-locate the database and the Orion server on the same hardware.

I haven’t found a good explanation for the following excerpt from the administrators manual (page 10)

 

Orion NPM Requirements

SolarWinds recommends installing Orion NPM on its own server, with the Orion database hosted separately, on its own SQL Server. Installations of multiple Orion NPM servers using the same database are not supported.

 

 

The server that I deployed NPM + APM + IPSLA on is a very nice piece of hardware. It is a HP DL380 G5 with the following specs:

  • ·        Dual quad core Xeon @ 3.16Ghz
  • ·        32Gb Ram consisting of 8 x 4096 MB 667 MHz memory modules
  • ·        800+Gb of usable disk provided by an array controller configured like this:

 

All in all this is not a shoddy box. I had the money and spent it!


 

The system is not even breathing hard doing the job of my main polling engine + web server + alerting engine as you can see by the following stats taken from Orion monitoring itself:

 

 

 

NOTE: The high CPU utilization was related to the 10.x update. The system is feeling much better now

 

Even right now I have so much horsepower and disk space left over, I'm considering using it as my work mp3 server!

 


 

So my question is this:

Why does SolarWinds recommend separating the database away from the application?

Some architectural considerations that might be the reason:

  • Separation of database from application in a 3 tiered application is considered the norm.
  • DBAs like to keep their toys separate from the application people
  • There can be some economies of scale achieved by running multiple databases on the same server. Sometimes.

Note: 20+ years of IT operations tells me these are just platitudes

 

Chris.

0 Kudos
1 Solution
Level 13

It is pretty simple really.  There are 2 good reasons for it.

The first is that the app for bigger installs can be be very IO itensive as far the DB server goes.  Tons of tiny reads and writes.  All in all it will thrash a SQL server pretty hard all by itself, so having it coexist with another app or other DBs means they all will suffer.

Secondly, its a great idea to keed it seperate from your other SolarWinds servers for redundancy.  The app is very modular, everything centralizes off of SQL so any part can be rebuilt and so long as your DB is there nothing else needs to be done.  The same is for SQL. 

View solution in original post

0 Kudos
4 Replies
Level 11

not sure,  my server is a lot less spec then yours and runs fine,  i did have the database on a different server and  in the graphs i have lost data,  so put the database back on the same server and it's perfect

0 Kudos

I would like to add this.  For a small install it is perfectly fine.  But if you have mutiple modules (especially netflow) and you have a large install you would find its not the best way.  You would end up with SQL and SolarWinds fighting for resources and starving each other out.

0 Kudos

Totally agree, I just moved my SQL to a separate server for exactly that reason. Netflow was killing my server.. now it's running so much faster than it was before.

0 Kudos
Level 13

It is pretty simple really.  There are 2 good reasons for it.

The first is that the app for bigger installs can be be very IO itensive as far the DB server goes.  Tons of tiny reads and writes.  All in all it will thrash a SQL server pretty hard all by itself, so having it coexist with another app or other DBs means they all will suffer.

Secondly, its a great idea to keed it seperate from your other SolarWinds servers for redundancy.  The app is very modular, everything centralizes off of SQL so any part can be rebuilt and so long as your DB is there nothing else needs to be done.  The same is for SQL. 

View solution in original post

0 Kudos