Best Practice – SQL 2012 & IIS in VMWare

sql-server-2012

We are pretty new to VMWare and looking for some thoughts on our environment.
We have a VMWare cluster that has on one host:

VM#1: MS Windows 2008 R2 Enterprise & SQL Server 2012
VM#2: MS Windows 2008 R2 Standard & IIS

The IIS asp.net app talks directly to the SQL Server. We had this similar environment on physical servers a few months ago and just recently moved to the virtualized environment.

Regarding the setup, we have not tweaked any of the vm resource parameters — all is set as standard and all is working.

What is observed is that the VMs seem to spool down and we get lags in response. Of course this sin't as fast as the old physical environment, but I am wondering if:

*is it a good idea to run the SQL server and the IIS server on the same host? They are the only two VMs on it. The host is a new Dell R620 with 192 gb mem.

  • does it make sense to change any CPU or memory reservations when it doesn't seem like there is any contention

  • is there a way to keep the VMs spooled up to eliminate delays?

This is a brand new squeaky clean vanilla install.

What are your thoughts?

Best Answer

Assuming that there is no resource over-commitment, reservations aren't going to get you a whole lot.

You need to track down what the cause of the slowdown is.

What is observed is that the VMs seem to spool down and we get lags in response.

What you need to do is find out what resources are causing this. Also "spool down" isn't really a description of anything. You need to do some digging into performance monitoring and see what's causing this.

*is it a good idea to run the SQL server and the IIS server on the same host? They are the only two VMs on it. The host is a new Dell R620 with 192 gb mem.

If you have two VMs that communicate a lot and generate a lot of I/O, it's a good idea to have them on the same host, but separate volumes/LUNs. Doing this will allow all network traffic between the two to stay on the vSwitch and never touch your physical networking infrastructure. There can be pretty decent performance improvements this way.

You should keep them on separate LUNs, because you don't want disk contention.


TL;DR - Profile your app. Find out where the bottleneck is. Reservations only matter if you have resource contention. There's no point in setting up reservations as a diagnostic measure, you need to do your diagnostics first and then worry about that if it's appropriate.

Related Topic