Memory overcommitment, not for production servers.
Recently I had to prepare a business case on virtualization for a client and, while collecting data and writing the document, I realized that one of the key point those pushing for VMware often use is actually not suitable for production environments servers. I’m talking here about memory overcommitment which VMware has been using intensively to promote their virtualization solution. Memory overcommitment basically consists of assigning an amount of memory to several VM’s while the total amount of allocated memory is greater than what is physically available on the host system.
This is technically possible because in most case VM’s are not using the total allocated memory, thus allowing for more VM’s on a single host. However, if you are thinking of implementing High Availability and have the ability to “live migrate” VM, memory overcommitment does not make sense. If you overcommit memory on hosts and a member of a cluster has a major problem, you won’t have enough resources available for you failed VM’s to be loaded. This alone makes memory overcommitment irrelevant for a production environment.
VMware also state the following in their Performance Tuning Best Practice for EXS server:
Make sure the host has more physical memory than the total amount of memory that will be used by ESX plus the sum of the working set sizes that will be used by all the virtual machines running at any one time.
With this in mind and considering here that we are talking about production environment in which you will want to have High Availability capability, there is no way memory overcommitment can be used as an “advantage” of VMware. In most scenarios I’ve seen on the Internet, people compare VMware with overcommitment vs. Microsoft Hyper-V, but in a real world production environment, you cannot consider these scenarios. Of course, for a development or test environment were High Availability, failover or live migration are less critical, you could consider memory overcommitment but you would still have to keep a close eye on usage.
This is a terrific piece of writing, im delighted I discovered this. Ill be back again later on to check out other posts that you have on your blog.
In the real world, mem overcommitment is actually used. How? Well, VMware recommends to do a max. overcommitment of 160-180 percent. So if your host has 24GB that gives about 38GB of memory to be commited. Most companies subtract 20 to 30 percent from this. Intel, for example, subtracts 20 percent giving about 30GB to be commited.
You are right saying that memory overcommit is possible. However, my point here is that using overcommitment would reduce or cancel your ability to implement High Availability and Failover of production VM in the event a host as a hardware or other major failure and VM’s need to be transfered on other host of the cluster. Most article about overcommitment are considering only VDI or SMB. In the case of large enterprise, you have to keep in mind that HA and failover will be implemented and if you are overcommiting your memory, you will lose those abilities quite fast.
This is a terrific post, but I was wondering how do I suscribe to the RSS feed?
This is a amazing piece of writing, I discovered your weblog browsing yahoo for a similar theme and arrived to this. I couldnt come across to much additional information on this piece, so it was awesome to find this one. I will likely be returning to look at some other articles that you have another time.
[...] use this feature in a production environment (read this blog post for an explanation why: Memory over commitment, not for production servers), this new technology is perfect for use in the development and testing Hyper-V environment at [...]
While I agree with your post I must add that the overcommitment must be seen as a crucial advantage of VMWare’s ESX hypervisors over the competition – even in a production setting – since it improves flexibility by orders of magnitude.
Granted, one should not make a practice out of overcommiting memory resources, however, one will not have to reserve huge amounts of idle servers in one’s clusters to allow for high HA since… they don;t need to! One can keep a very small percentage of idle servers since even if a large proportion of the cluster’s resources fail, memory overcommit will kick in and easily save the day. The same cannot be said for the competition since with e.g. hyper-v or Xen, the degree of HA is decided by the number of reserved idle servers in clusters.
Iˇve read a few good stuff here. Definitely price bookmarking for revisiting. I wonder how a lot effort you put to make one of these wonderful informative website.