1 of 1 people found this helpful
Installing Orion on VM is fine, just be sure CPU and RAM meets our min specs and that its dedicated CPU & Memory.
As for SQL Server, we would not support NPM\Netflow on a SQL Server with a VM.
Here is best practice for SQL Server:
2 x Raid 1 disk (Mirroring) For operating system
2 x Raid 1 disk (Mirroring) Place pagefile here and also can be used for applications and ad hoc Stuff
4 x RAID 1 +0 Stripping and mirroring for database files (2 partitions 1 for Data File and 1 for Log File)
Also the following pdf is a great resource for SQL sizing and performance tuning:
We do not recommend:
1 SANs depending on setup.
2 Slow Disks 10K
3 RAID 5/6 (Especially with Netflow)
4 SQL Servers on Virtual Machines
5 SQL Server Installed on Same Server as Orion with NETFLOW.
SQL Server performance is a hot topic these days, especially if you're leveraging your SQL Server for a high performance NMS.
This can become even more critical when you add applications like NetFlow which tend to carry a significant I/O burden.
In some organizations you can rely on the DBA team to own/maintain/optimize the database servers for you.
Unfortunately, for many of us this isn't an option either because we dont' have a DBA team or because it's such a political mess trying to work with them.
This causes us to have to implement and maintain our own database servers to support our apps.
The thing is, most of us network engineers don't know diddly about database servers.
So, with that in mind, here are a few tips for optimizing your SQL Server:
Head Geek's Top 5 Tips for Improving SQL Performance
#5 - Add more RAM. Doesn't really matter how much you have, adding more will almost always help.
Be sure that your SQL instance and OS are capable of consuming the additional RAM and if not make it so.
#4 - Just say "no" to RAID 5. It's great for application servers but horrible for database servers where I/O performance is important.
#3 - Place the data and log files (.mdf and .ldf) on separate logical drives and separate channels or controllers.
#2 - Unless your SAN is optimized for high I/O vs. large I/O stick with a locally attached disk array.
#1 - Buy disk controllers with battery backed-up write-back cache. The more the better, but at least 256MB.
Based upon experience with support, I'd recommend against putting anything on a VM.
Despite exceeding recommended resources (cpu, mem, storage,...), support had a tendency to blame the configuration or performance of the VMs when dealing with any issues.
Now that we have all components (DB, app, pollers) on physical machines we've been able to eliminate that noise and press for resolution (or bug documentation) on issues.