SolidFire demo: SIOC & QoS Interoperability

I watched a very cool demonstration this morning from the All Flash Array vendor, SolidFire. I spoke with SolidFire at the end of last year, and did a blog post about them here. One of the most interesting parts of our conversation last year was how SolidFire’s QoS feature and VMware’s Storage I/O Control (SIOC) feature could inter-operate. In a nutshell, QoS work at the  datastore/volume layer whereas SIOC deals with the VM/VMDK layer. Last week, Aaron Delp and Adam Carter of SolidFire did an introduction to QoS, both on vSphere and on the SolidFire system. And they also did one of the coolest demos that I’d seen in some time, namely how they have managed to get SIOC and QoS to work in tandem.

The initial part of the demo spoke about solving the age-old problem of noisy neighbours. They discussed the SIOC approach where it tries to achieve fairness between virtual machines running on the same shared datastore. They also highlighted areas where SIOC may not be able help. In particular, when the storage is used by applications that are not known to vSphere (external workloads). Also, the latency congestion threshold that triggers SIOC to start throttling is too high for flash storage.

To address the above, SolidFire have a plugin to the vSphere client which allowed them to create a relationship between SIOC shares on the VM and QoS levels on the volumes. Keep in mind that QoS is related to datastores and SIOC is related to VMs. What SolidFire have done is that they have used the SIOC settings on the VMs to automatically dictate the QoS settings on the underlying volume to meet the correct level of IOPS. SIOC shares, set on a per VMDK basis, are used to define a minimum number of 4K IOPs, and the SIOC Limit IOPS setting, also set on a per VMDK basis, is used to define the maximum number of 4K IOPS. Burst, since there is no SIOC burst setting, is defaulted to be 4 times the Limit IOPS setting. Here is a screenshot showing the SolidFire plugin on the vSphere web client enabling SIOC-QoS:

Congestion threshold is also set to 5ms on the datastore since 30ms is too high. This is the minimum the system will allow.

Now the most interesting part of the demo was the migration of a virtual machine from datastore A to datastore B. The QoS settings on the volumes automatically adjusted as the VM was Storage vMotion’ed. The source datastore, which now has one less VM, adjusted QoS downwards, and the destination datastore, which now has an additional VM, adjusted QoS upwards. This enabled the underlying volume of the destination datastore to meet the  performance requirement of the existing virtual machines and the newly arrived virtual machine without any of the VMs taking storage resources from one another. Basically storage performance now follows the VM around the infrastructure. This is a superb enhancement in my opinion.

You can catch the whole demo by clicking here. The first 19 minutes is an introduction to  QoS in general, including SIOC. From 19m onwards there is a discussion about the impact of noisy neighbours, etc. The SIOC demo begins in earnest at 27m, and the Q&A, which has some really good questions starts at 38m.

Great job guys.