vSphere 7 - DRS Scalable Shares

Submitted by Robin van Altena on Mon, 09/28/2020 - 07:08
 
 
Follow your favourite author

Leave us your email address and be the first to receive a notification when Robin posts a new blog.

vSphere 7 - DRS Scalable Shares
April 2020 vSphere 7 went GA (General Availability). With this new release of vSphere there are many new features including the very cool DRS Scalable Shares. Check out how this new feature works and how to enable it in your environment.
Image
Scalable Share on a Resource pool
Textarea

In my previous blog I showed some cool new features within vSphere 7 DRS and ended with an example of what Sharable Shares does. Now I will show you how the shares are calculated and how I tested this feature.

Textarea

Scalable Shares

Scalable Shares are not enabled by default, but when enabled they allow to have dynamic and relative entitlements within resource pools. If you have used resource pools before, you might know that assigning a VM to a resource pool with high shares configured isn’t a guarantee that the VM receives more CPU cycles than a VM in a resource pool with low shares configured. Scalable Shares solves this. But remember that methods like this only work when resources are scarce. When there is resource contention.

Let me explain with an example that I build in our LAB. I created a resource pool with a limit of 8 Ghz CPU cycles. Within that resource pool I created two resource pools; Production and Test. The Production resource pool has high shares (8000) and the Test resource pool has normal shares (4000) configured. In total there are 12000 shares to be divided, meaning 5,333 Ghz for Production and 2,667 Ghz for Test. So far so good.

Textarea

Resource calculation with normal DRS Shares

Now for some reason there are more VM’s in the Production resource pool then there are in Test. Even though the VM's in the Production resource pool also have a high Shares value they end up receiving less CPU cycles then a normal shares VM in the Test resource pool. Have a look at the following pictures:

Configured resource pools
Image
VM’s in the Production resource pool
Textarea

As you can see the 3 Production VM’s each get 33% of the 5,333 Ghz assigned to the Production resource pool. So, in a worst-case scenario the VM would receive about 1,78 Ghz of CPU cycles. This number can be viewed under the monitoring Tab of a VM.

Image
Worst case CPU utilization for a Production VM, 'OLD' DRS
Textarea

Now the Test VM is alone and receives 100% of the 2,667 GHZ.

Image
VM’s in the Test resource pool
Image
Worst case CPU utilization for a Test VM, 'OLD' DRS
Textarea

As shown in the pictures above the total 8 Ghz of CPU cycles are divided as followed:

Amount of CPU cycles using 'OLD' DRS
Textarea

Resource calculation with Sharable Shares

Sharable Shares isn’t enabled by default but can be enabled on a vSphere Cluster or on Resource Pool level. When enabled on the Cluster level it is enabled for all resource pools within that cluster.

Image
Scalable Shares on Cluster level
Textarea

After a view seconds, a minute at most, the new calculation method is active within the cluster.

The new calculation method is described as followed:
Resource Pool Shares = (4 vCPU * Shares of Pool) * (Total number of shares of all vCPUs in resource pool)

With the following facts:

  • A resource pool looks like a VM with 4 vCPUs and 16GB of memory to DRS
  • Scalable Shares looks at the total amount of shares in the Resource Pool (all vCPUs!)
  • For a resource pool: high is 8000 shares, normal is 4000 shares and low is 2000 shares
  • Note that this is based on 4 vCPUs, so the real values are 2000, 1000, 500

In practice this means that the total number of shares is calculated based on the number of VM is the total pool. Each VM gets a portion based on the number of its own and the resource pool shares.

So how does this work for our example?

We have 3 VM’s, each with high CPU shares (2000), in a Production resource pool with high shares (8000 = 4 vCPU). 3 * 2000 * 2000 (1 vCPU) = 12000000 shares. The test VM has normal CPU shares 1000, in a resource pool with normal shares (4000 = 4 vCPU). 1 * 1000 * 1000(1 vCPU) = 1000000 shares. The total number of shares in our example = 13000000 shares.

A VM in our Production resource pool will receive 4000000 shares out of the total 13000000 shares where the VM in the Test resource pool will receive only 1000000 shares. Which make the assignment of the resources more logical and predictable.

We can also see this by looking at our ‘Worst Case Allocation’ again.

8 Ghz divided by 13000000 shares times 4000000 shares for our production VM is 2.46 Ghz.

Image
Worst case CPU utilization for a Production VM, Scalable Shares
Textarea

And the VM in the Test resource pool now only receives 0,6 Ghz, a quarter of what the production VM’s receive in a worst-case scenario. 8 Ghz divided by 13000000 shares times 1000000 shares = 0,61538 Ghz.

Image
Worst case CPU utilization for a Test VM, Scalable Shares
Textarea

As shown in the pictures above the total 8 Ghz of CPU cycles are divided as followed:

Amount of CPU cycles using Scalable Shares
Textarea

Again, bear in mind that mechanisms like Scalable Shares only start to work when there is more demand than resources. That’s why I found the best place to test and check the scalable shares using the ‘Worst Case Allocation’ number.

Hopefully you enjoyed this blog and if you would like to read more about VMware product check our other blog posts or read some of the blogs that got me interested in the new improvements of vSphere 7 DRS.

Questions, Remarks & Comments

If you have any questions and need more clarification, we are more than happy to dig deeper. Any comments are also appreciated. You can either post it online or send it directly to the author, it’s your choice.
Let us know  

 
 
Questions, Remarks & Comments

Message Robin directly, in order to receive a quick response.

More about RedLogic