XtremIO X2 Tech Preview #1 - Quality of Service (QoS)

Unplug you storage pipeline

Construction noises from the street, your baby sister is crying, your neighbor is practicing for his American idol audition, and all you want to do is watch your favorite series on TV. You decide to put on your headphones and turn up the volume so these noises will stop bothering you.
Now you solved the noise problem but the volume from your headphones is too high. Without volume limitation, you can cause a serious damage to your ears.

As people can cause damage by using their headphones without resource control, so does virtual machines in a storage system. A single virtual machine can use more resources than expected and cause the array to malfunction by raising service times for all other applications on the array.

Without resource limitation, one application or a “noisy neighbor” can easily consume an unfair share of resources, leaving little available for others.

XtremIO QoS technology is focused on preventing application starvation caused by those noisy neighbors, also enabling service providers to ensure that their customers won’t use more resources than they paid for. This is done by limiting the maximum bandwidth or IOPS per any volume/host/application in the system.

An example for a potential noisy neighbors can be caused by different applications running different workloads on the same array, or test/dev environments sharing the same resources as production volumes.

XtremIO unique integrated Copy Data Management (iCDM) technology allows to create multiple copies of each volume/application and present them to various development teams without any performance impact on production. Yet, in some heavy load environments, there is a potential to max up the array so limiting the test/dev copies will make sure the production volumes won’t be affected.

XtremIO Implementation

XtremIO QoS is policy driven and can be assigned to any Volume, Consistency group (application) or Host/s (Initiator Group/s) in the system.

QoS policy should only be set once, which contributes to the simplicity of XtremIO management.
The policy can then be used for different storage objects.

QoS policies can be set for IOPS, BW, or IO-Density units. IO-Density is IOPS used per capacity. For example: you can define a 5000 IOPS per 1TB policy. Assigning this to a Consistency Group with 2 volumes of 6TB provisioned size in total will limit the Consistency Group to a maximum of 30,000 IOPS.
The IO limitation dynamically changes upon add/remove volumes from the Consistency Group.

Burst IOPS can also be set to extend the MAX IOPS limit for a short period of time. When a volume runs below the MAX IOPS limitation, burst credits are accumulated and the volume can then use these credits up to the burst limit.

One of the key benefits of XtremIO web interface is the availability of performance data on the storage array, such as weekly pattern, performance over time and block size histogram. This makes the process of assigning QoS policy fast and reliable by easily viewing the workload patterns of each application and match the best QoS policy to it.
For example, the image below shows the weekly pattern of a volume in the system. Hovering on a specific day-time shows the number of IOPS and BW during that time. From this image we can learn the amount of IOPS in normal working hours and during peak and assign the MAX IOPS limitation and the Burst IOPS accordingly.