As admission control hasn’t evolved in the past years, we figured we would include another potential Admission Control change. Right now when you define admission control you do this cluster-wide. You can define you want to tolerate 1 failure for instance, but some VMs simply may be more important than other VMs. What do you do in that case?
Well if that is the case then with today’s implementation you are stuck. This became very clear when customers started using the vSAN policies and defined different “failures to tolerate” for different workloads, it just makes sense. But as mentioned, HA does not allow you to do this. So our proposal is the following: Per VM FTT Admission Control.
In this case you would be able to define Host Failures To Tolerate on a per VM basis. This would provide a couple of benefits in my opinion:
- You can set a higher Host Failures To Tolerate for critical workloads, increasing the chances of being to restart them when a failure has occurred
- Aligning the HA Host Failures To Tolerate with the vSAN Host Failures To Tolerate, resulting in similar availability from a compute and storage point of view
- Lower resource fragmentation by providing on a per VM basis Admission Control, even when using “slot based algorithm”
- Of course you can use the new admission control types as mentioned in my earlier post.
Hopefully that is clear, and hopefully, it is a proposal you appreciate. Please leave a comment if you find this useful, or if you don’t find this useful. Please help shape the future of HA!
Marcos Ortiz says
It make a lot of sense more if we have vsan in place, actually a lot of customers disable admission controls instead tunning because are stuck in the case that some criticals VMs needs to be always on, so it´s very interisting in my opinión, i think basic vSphere features will be evolved to meet the “VM or object policies”