posted

Part 1 of this series explains the new reservation capabilities of the ESXi storage scheduler in vSphere 6.0 called mClock.  That article explains how to calculate the number of entitled IOPS during times of contention.  This article will expand on that topic with a couple new scenarios.  The previous article assumed that all the VMs were evenly consuming the storage resources at the same time.  In the real-world though, some VMs will be consuming resources while others will be idle.  This should help explain how the IOPS are distributed when there are idle VMs in the environment.

Scenario 3
In this scenario the third VM is idle, while the other 3 VMs are consuming storage IOPS.  For the sake of this example, it will be assumed that VM3 will be consuming only 10 IOPS. Unlike memory reservations, the storage scheduler will allow the unused resources to be consumed by other VMs.

The first step is to determine what percentage of the resources each host will receive. In this example there are a total of 5000 shares across all hosts.  Then you would calculate how many shares are assigned to each host to determine the percentage each host will receive.  In this example, Host 1 has 3500/5000 (70%) of the shares, and host 2 has 1500/5000 (30%) of the shares.  This will result with the following entitled IOPS for each host.

Host1: 70% * 8000 IOPS = 5600 IOPS
Host2: 30% * 8000 IOPS = 2400 IOPS

Once the I/O distribution for the hosts are calculated, the VMs will have their entitled resources calculated using the share distribution within the host.

VM1: (1000/3500) * 5600 = 1600 IOPS
VM2 (2500/3500) * 5600 = 4000 IOPS
VM3: (500/1500) * 2400 = 800 IOPS (Only using 10 IOPS)
VM4: (1000/1500) * 2400 = 1600 IOPS

Since VM3 is only using 10 IOPS, the 790 unused IOPS would be distributed to the remaining VMs on the host.  In this case, VM4 would be entitled to 2390 IOPS.  However, VM4 has a limit of 2000 IOPS, which means that there will be 390 IOPS that can still be distributed.  Those 390 IOPS will then be distributed across the VMs on Host1.

In the end, this is how the IOPS allocation would be distributed:

VM1: 1600 + ((1000/3500) * 390) = 1711 IOPS
VM2: 4000 + ((2500/3500) * 390) = 4279 IOPS
VM3: 10 IOPS
VM4: 2000 IOPS (Due to limit)

Scenario 4
Now let’s take the same environment, but calculate the effective IOPS if VM1 was the idle VM. Again, for the sake of this example, the idle VM will be consuming 10 IOPS. The first thing to do is calculate the percentage of the resources each host will receive. In this example there are total 5000 shares across all hosts. Since the environment has not changed, the entitled IOPS per host is unchanged from the previous example.

Host1: 70% * 8000 IOPS = 5600 IOPS
Host2: 30% * 8000 IOPS = 2400 IOPS

Once the I/O distribution for the hosts are calculated, the VMs will have their entitled resources calculated using the share distribution within the host.

VM1: (1000/3500) * 5600 = 1600 IOPS (Only using 10 IOPS)
VM2 (2500/3500) * 5600 = 4000 IOPS
VM3: (500/1500) * 2400 = 800 IOPS
VM4: (1000/1500) * 2400 = 1600 IOPS

Since VM1 is only using 10 IOPS, the 1590 unused IOPS would be distributed to the remaining VMs on the host.  In this case, VM2 would be entitled to 5590 IOPS.  However, VM2 has a limit of 5000 IOPS, which means that there will be 590 IOPS that can still be distributed.  Those 590 IOPS will then be distributed across the VMs on Host2.

In the end, this is how the IOPS allocation would be distributed:

VM1: 10 IOPS
VM2: 5000 IOPS (Due to limit)
VM3: 800 + ((500/1500) * 590) = 997 IOPS
VM4: 1600 + ((1000/1500) * 590) = 1993 IOPS

Hopefully this helps explain how entitled IOPS are calculated and distributed using the mClock storage scheduler in vSphere 6.0.  The important thing to take away is that unused IOPS are not held and wasted, and they distributed across the environment automatically providing the most efficient use of your resources.