SPBM Host-Based Rules: Storage I/O Control via Policy

As we wrap up the SPBM series, this episode we will look at the difference between Storage I/O Control version 1 and 2. Unlike SIOC v1, v2 is policy based and allows for storage I/O control at the VM level.

A quick overview of SIOC; SIOC v1 is used for VMFS and NFS datastore, vVols and RDMs are not supported. SIOC v1 is enabled at the datastore level monitoring storage I/O congestion. It can throttle I/O using a datastore-wide disk scheduler which allocates storage resources to VMs based on shares.

When enabled, you can configure SIOC using either a percentage of throughput or specific latency.

SIOC v1 Control

Based on the shares allocated at the VM’s disk SIOC v1 will allocate or limit I/O in times of contention. These shares may be changed to either ensure or limit the I/O the disk receive. Something to note SIOC v1 is only active if there is I/O contention on that datastore. Otherwise, it does not affect I/O.

VM disk I/O shares

When we look at SIOC v2, available from vSphere 6.5 and above, the difference is v2 is policy based and is applied at the VM level rather than the datastore level. SIOC v2 uses vSphere APIs for I/O Filtering (VAIO) which gets direct access to the VM’s I/O path regardless of the underlying storage. With this level of granularity, you can limit or ensure your VMs get the intended I/O. SIOC v1 and v2 may be used in conjunction or independently as they focus on different areas of storage control. Another benefit of SIOC v2 is array and datastore independence; remember it’s controlling I/O at the VM level.

SIOC v2 enabled via SPBM policies under host-based rules when creating a new storage policy.

Enabling host-based rules

After choosing “Enable host based rules” you then select the “Storage I/O Control” tab where you can use either pre-defined or custom I/O share allocation. Under “Use storage policy component” you have the option to select low, normal, or high.

Selecting Share Allocation

Each of these allocations sets specific IOPS, limit, reservation, and shares for that policy.

Low I/O share allocation:

Normal I/O share allocation:

High I/O share allocation:

For more controlled allocation you have the option of choosing “Custom” where you may tailor the IOPS settings. The default values for limit and reservation deactivate that setting unless changed. IOPS shares have a default of 1000. You may use a single or combination of these settings. For example, for test and dev where you want to limit the IOPS VMs are allowed to use. Conversely, for your critical machines, you want to ensure they receive a minimum amount of IOPS. The combinations are limitless.

Custom Storage I/O control settings

An additional benefit from using policies to manage I/O, they may be applied to a single disk in a VM, allowing incredible control over individual disks.

Independent disk policies

Once the policies are applied, you can see the resource allocation at the cluster level under Monitor, Resource Allocation, Storage in the H5 client. Here you can see the Win10-3 has specific allocation based on the policy applied.

Review Share Allocation

Generally, the default low, normal, and high work for most applications needing VM I/O control. When an SPBM SIOC v2 policy is applied to a VM, it follows or controls that VM despite being moved to different datastores. If a datastore isn’t compatible with the policy, it will not be available for selection during a migration. If the policy becomes non-compliant, a vCenter alarm may be set to alert the admin.

Utilizing policies and the SPBM framework to manage your storage environment allows for more straightforward automation. For example, PowerCLI can easily apply or change policies for one or numerous VM’s in your environment; something not easily achievable without policy-based controls. Make sure to check out other posts in the SPBM series showing the various ways SPBM policies can be utilized.