The reason is that SQL is so demanding of resources to support the high I/O to the database. There are many, many threads in Thwack discussing the ins and outs of this, but in short, if you have more than about 2000 elements (nodes, interfaces and volumes) monitored by Orion, then you will get much better performance out of the system by having SQL on its own server. Keep in mind that I am talking about only basic Orion NPM data. If you add any other modules such as APM or NetFlow (especially NetFlow), then that places even more demands on server resources.
If hardware availability is really a critical issue, then you may have no choice but to be very selective in what you decide to monitor with Orion.
Hope this helps.
We do have APM with many perfmon counters polling. So are people recommending this setup:
Server1: IIS and Orion APP
Server2: Orion Poller
Server3: Orion DB
How many element? How Many APM Pollers?
APM Pollers: https://orion/Orion/APM/Admin/LicenseSummary.aspx
I have 800 APM pollers and 1900 elements running a virtual IIS/App server (2008 R2) and separate DB servers (2008 R2 Core. Yes, the DB is virtual too) and it runs really well.
(oh, replace the "https://Orion" with whatever your Orion server is running)
As others have already said, it really depends on your environment and how may elements you're monitoring. In most cases though, you really should have a dedicated SQL box. SQL can be extremely heavy on IO reads & writes. The IO patterns on an IIS/Application server could be completely different. If you were to putt all three on the same physical server, you would create disk contention which would hurt performance.
In our environment, we have 1 VM for NPM, APM & NCM apps and another physical SQL box full of 15K SAS disks in a RAID 10.