Early 2015 Frank Denneman and I had a discussion during a flight to San Francisco. We came up with this concept for Resource Pools where the number of shares would be determined by the number of VMs and the priority of the pool. In other words, we wanted to avoid the dilution of shares in an environment with resource pools and basically solve the resource pool pie paradox problem described here. We worked with the DRS team on describing the concept, we filed a patent for it and got the patent granted in 2019. Today I am happy to share that the feature made it into a release and will be part of vSphere 7.0.
Scalable Shares is a feature that is part of DRS. You either enable it on the Cluster or you enable it on the Resource Pool. Personally I would always enable it on the Resource Pool level. So how does it work? Well normally when you create a resource pool with High Priority and one with Normal Priority, the RP with Priority High will have 8000 shares and the RP with Priority Normal will get 4000 shares. In other words, a 2:1 ratio between High and Normal. Now if you have 8 VMs in High and 1 in Normal, you can imagine that this single VM in Normal will get more resources than the 8 in High when there is contention simply as the 8 share the resources of the pool while the single VM doesn’t share the resources.
When Scalable Shares is enabled, DRS does a calculation using the ratio (4:2:1 – High:Normal:Low) and the number of VMs. In other words, 8 VMs with a 1000 shares in High would be *4, and 1 VM with a 1000 shares in Normal would be *2. The result being:
- Normal = (1*1000)*2=2000
- High = (8*1000)*4=32000
I hope that makes a bit sense? It took me a while to fully grasp. If you are wondering what this looks like in the product, and what the impact could/would be when you switch from “traditional” to “scalable shares”, I created a demo that shows this below.
This looks great and addresses a problem I think most vSphere admins will have run into in any resource pool heavy environment. Thank you.
Question though, how will vCenter consumers respond to the change? For instance, VCD, which creates its own resource pools – are we going to have to wait for a vNext of all of them to begin utilizing the feature? I presume there may be some significant performance and behavior changes as a result of this that will need to be addressed in their resource allocation models.
This is timely – we are being asked to create separate clusters to isolate CPU (java app) spikes – thanks
(I am assuming this requires enterprise license vs standard?)
Awesome! I’ve done this task manually once a week between customer/internal/mgmt/service RPs (service provider).
Does it take in consideration the number of vCPUs per VM when calculating shares?
Can’t wait to test it out!
I will do a short write up to explain how it is calculated. I didn’t want to go too deep, but I guess it makes sense to explain
More details: https://wp.me/p9Yzn-54L
Hi Duncan
This is really great!
Can we utilize this feature with custom shares as well ?
Yes, I will do a short write up soon about how it is calculated actually.
More details: https://wp.me/p9Yzn-54L