by Duncan Epping
Just a limited offer, two days only… The VMware vSphere 4.1 HA and DRS tech deepdive is free. WHAT? Yes it is free… $ 0,-. So hop over to amazon and pick up your free Kindle copy today!
For those who have been living under a rock, this book will explain the ins and outs of both vSphere HA and DRS. Admission Control, Resource Pools, Limits, HA Restart Timelines… it is all in there. Pick it up!
At the end of 2010 I wrote an article about cluster sizes… ever since it has been a popular article and I figured that it was time to update it. vSphere 5 changed the game when it comes to sizing/scaling of your clusters and I this is an excellent opportunity to emphasize that. The key take-away of my 2010 article was the following:
I am not advocating to go big…. but neither am I advocating to have a limited cluster size for reasons that might not even apply to your environment. Write down the requirements of your customer or your environment and don’t limit yourself to design considerations around Compute alone. Think about storage, networking, update management, max config limits, DRS & DPM, HA, resource and operational overhead.
We all know that HA used to be a constraint for your cluster size… However these times are long gone. I still occasionally see people referring to old “max config limits” around the amount of VMs per cluster when exceeding 8 hosts… This is not a concern anymore. I also still see people referring to the max 5 primary node limit… Again not a concern anymore. I guess we can generalize things and using the 2010 article and applying that to vSphere 5 I guess we can come to the following conclusions:
Once again, I am not advocating to scale-up or scale-out. I am mere showing that there are hardly any limiting factors anymore at this point in time. One of the few constraints that is still valid is the max of 8 hosts in a cluster using linked clones. Or better said, a max of 8 hosts accessing a file concurrently. (Yes we are working on fixing this…)
I would like to know from you guys what the cluster sizes are you are using, and if you are constraint somehow… what those constraints are… chip in!
For those who hadn’t seen it yet, the “vSphere 4.1 HA/DRS Deepdive” is available in the Kindle Lending Library! The Kindle Owners’ Lending Library is a collection of books that Amazon Prime members who own a kindle can borrow once a month, with no due dates. (Yes you will need a Kindle Prime subscription!) If you have a Kindle or are using the Kindle App check it out:
Check it out, and let me know if you like it by leaving a comment… this is a trial for us as well, we might end up enabling it on all books in the future.
Last week at VMworld and on the VMTN community I had a couple of questions around resource management and HA Admission Control. It appears people were using HA Admission Control for managing resources within their environment. In other words, the amount of VMs that HA would allow you to restart would be leading for managing resources. But is that what you should do?
If you look at how HA works and what HA is intended to do the answer in short is, No. Now the reason for this is that HA is all about getting your virtual machines up and running again. If you look at HA Admission Control in vSphere 5.0 you will quickly see that for instance the default value for CPU has been decreased from 256MHz to 32MHz, if no CPU reservations are specified that is. Now in many scenarios virtual machines will consume and demand more than that. Another thing to point out is that if no memory reservation is specified the memory overhead of the VM is used. These values are more than likely much lower than what your virtual machine currently consumes or demands. The thing to keep in mind is that these CPU and Memory values only represent what HA needs in order to power-on your virtual machines.
If you want to manage resources, avoid severe overcommitment, guarantee a certain experience you should start looking at the DRS statistics. You should start exploring tools like VC Ops, Cap IQ… Don’t (ab)use vSphere HA for this. It is not designed to solve this problem. One thing to think about though is maybe increasing the minimum value for slotsizes to avoid scenarios where environments are fully overloaded!? If you have a consolidation ratio in mind it should be fairly simple to figure out which value to use:
available memory esource per host / consolidation ratio = das.vmMemoryMinMB
or
available CPU esource per host / consolidation ratio = das.vmCpuMinMHz
I am not saying that you should do this, but I think it might not be a bad practice in environments where multiple people have access to vCenter and can deploy VMs. At least people will be triggered when you are running out of “slots” to start VMs.
A couple of weeks ago I was contacted about an issue with vSphere 5.0. When a VM Storage Profile was disabled / enabled it looked like HA and DRS got disabled as well. After diving in to the problem it appeared that both HA and DRS were still working. It seems that some how the vSphere Client thinks it is disabled. Again, although it looks like it is disabled it is still fully functioning… but indeed it is very confusing. A simple work around would be enabling HA/DRS. This problem has just been published in our Knowledge Base, and hopefully will be addressed soon.