3

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?

Sven
  • 97,248
  • 13
  • 177
  • 225
Dan Ribar
  • 31
  • 1
  • 2
  • You really need to provide more info. Things like what version of VMware, CPU and memory assigned to each guest, what kind of storage you have running in the backed end, how you have your networking configured, what kind of performance monitoring metrics you have already gathered.. etc.. – Rex Sep 12 '12 at 14:40
  • As far as combining IIS and SQL, in most cases it is not a good idea. Especially for security and maintenance. – Serhiy Sep 12 '12 at 18:01
  • 1
    @Serhiy it usually isn't a good idea to combine them because it limits scalability, but could you explain security risks a bit further? It actually is a bit more secure to run them on the same box so that you can turn off remote connections on the DB instance... – MDMarra Sep 12 '12 at 19:41
  • From security standpoint - one of my servers had Administrator account been brute forced on one of the IIS servers (yes I did not rename build in administrator account at that time). Plus, IIS and .NET applications add more holes. For me, personally, main point of separating them is as you said - scalability and maintainability. – Serhiy Sep 12 '12 at 19:53
  • "Of course this sin't as fast as the old physical environment" - my personal experience is that, in most cases, VMs are faster and more responsive then physical machines except Terminal/Citrix servers. I hit memory limit or Disk I/O then any CPU limits. I would say that storage performance makes biggest difference, especially with SQL. – Serhiy Sep 12 '12 at 20:02
  • 1
    @Serhiy "my personal experience is that, in most cases, VMs are faster and more responsive then physical machines" <-- I think you just wandered way off the reservation there. – Chris S Sep 12 '12 at 20:43
  • 4
    @Serhiy As a community of professional systems admins, we value empirical data, not gut feeling. There is an overhead to a machine being a VM. Because of this, most VMs take between a 2-5% performance hit (depending on hypervisor and configuration) vs being run directly on the same physical hardware. If you're going to go against the grain with your comments, you need to back them up with data. We're all open to alternative views, but in something as cut-and-dry as performance, you're going to have to supply reliable data to back up claims like that otherwise you wont be taken seriously. – MDMarra Sep 12 '12 at 20:47

2 Answers2

3

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.

MDMarra
  • 100,183
  • 32
  • 195
  • 326
  • I would say that giving 1MHz CPU reservation is always a good thing and most of the times removes delays when you access a server after it was idle for some time. It helps even when there is only one VM on ESX host. Sure, for more complex setups there are resource pools, etc... – Serhiy Sep 12 '12 at 17:56
  • 1
    Do you have any documentation to support this? In a server that does not suffer from resource contention, this reservation should do absolutely nothing. – MDMarra Sep 12 '12 at 19:24
  • VMs after being idle a bit have a small lag when you first connect to it and it is supported by my personal experience with ESX 3,3.5,4 (usually 3-4 physical hosts attached to SAN and 3-50 VMs). I did not try 5.0 yet, however we will migrate to 5.0 this or next month. As far as documentation - it is favorite question in VMware community :) – Serhiy Sep 12 '12 at 19:48
  • "In a server that does not suffer from resource contention, this reservation should do absolutely nothing" - theoretically it is correct, but practically, small CPU reservation helps and I do not know why. Also, it is a quick thing to try and does not hurt anything :) In my current setup, I do not do any CPU reservations per VM, but on resource pool level. – Serhiy Sep 12 '12 at 20:09
-1

According to this thread at the VMWare community forums...

To eliminate delays, change CPU reservation:

  1. Right click on your VM and choose "Edit Settings"
  2. Click Resources tab
  3. Click CPU and on the right put a few MHz as a reservation
  4. Click Ok.

Generally, you do not need to change Memory reservation.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Serhiy
  • 174
  • 1
  • 1
  • 9
  • 4
    Can you explain this or link to some collateral about this as I've never heard of this suggestion before and I need to understand why you think this would help in such an non-contended scenario. – Chopper3 Sep 12 '12 at 21:01
  • 1
    These instructions have absolutely no noticeable impact on CPU queue or contention for a several of our ESX 4 and 5 blade center VM environments, with varying degrees of load and CPU request queue length and all manner of assorted guest VMs. Trend lines and logs of these metrics are unaffected, graphs look to be the same as they always do based on ToD, and there's no noticeable impact on OS logs of the guest OSes, or change in how fast or slow the VM "feel" from the inside either. I'm totally confident saying "absolutely no change whatsoever" is resultant from this reconfiguration. – HopelessN00b Sep 14 '12 at 03:23
  • As you wish guys. I got that recommendation from VMware Community forum and it helped me. – Serhiy Sep 14 '12 at 16:29
  • I know links outside are not recommended, but there is one of the similar issues: http://communities.vmware.com/thread/156509 – Serhiy Sep 14 '12 at 16:44
  • @Serhiy Actually, it's just `link only answers` that are kinda frowned upon. Links to provide sources (and avoid the appearance of plagiarism) are **strongly** encouraged. I edited your link into your answer, which is more along the lines of what you should do in the future. And even though the advice in that thread is **wrong**, and won't make a bit of difference, I removed my downvote, now that you've provided a source. – HopelessN00b Sep 16 '12 at 18:54