vSAN 6.2 adds a quality of service feature that limits the number IOPS an object can consume. In underutilized configurations, limits might or might not be necessary, because objects likely have sufficient resources to effectively meet the needs of their workload. While it is entirely desirable to have more than enough resources, it does not come without cost. Efficiently sized configurations are typically a good mix of cost and available resources. The metrics of appropriate resources for workloads can change over time, especially as utilization grows, or as workloads are added over the lifecycle of a platform.

There are several situations where it might be advantageous to limit the IOPS of one or more virtual machines. The term noisy neighbor is often used to describe when a workload monopolizes available I/O or other resources, which negatively affects other workloads on the same platform. In environments where there is a mix of both low and high utilization, it could be detrimental for a virtual machine with low utilization during normal operations to change its pattern and start to consume massive resources, in turn starving others for enough to operate properly. Particularly at a larger scale, the impact of this situation might affect multiple business units, tenants, or customers.

A good example of a noisy neighbor situation includes end-of-month reporting. Consider those virtual machines generating reports residing on the same four-node Hybrid vSAN cluster as other Tier 1 applications that have stringent service level agreement requirements. What would happen if one or more large reports were generated, consuming a larger percentage of IOPS than were available for the minimum service level requirements of the Tier 1 applications? It is quite possible the Tier 1 applications would not be able to satisfy the requirements of the service level agreement. Implementing IOPS limits on the reporting solution VMs could prevent the situation where the reporting solution starves the Tier 1 applications for IO.

With the Quality of Service addition to vSAN 6.2, IOPS limits are now available. Quality of service for vSAN 6.2 is a Storage Policy-Based Management (SPBM) rule. Because quality of service is applied to vSAN objects through a storage policy, it can be applied to individual components or the entire virtual machine without interrupting the operation of the virtual machine.

 

Quality of service for vSAN is normalized to a 32-KB block size, and treats reads the same as writes. An example with an IOPS limit of 500 (regardless of block size up to 32 KB) results in 500 IOPS, while a block size of 64 KB results in 250 IOPS. It is important to consider the workload profile when configuring IOPS limits.