Original Post:
http://blogs.vmware.com/vsphere/2012/03/debunking-storage-io-control-myths.htmlI had the pleasure of presenting to a number of our customers and storage partners last week. Both sessions were very interesting as it gave VMware technical marketing a chance to elicit some good feedback about what's working well and what's not working well from a vSphere perspective. One of the things which surprised me was how some people are still not using the Storage I/O Control (SIOC) feature, which I see as one of the most helpful storage performance management features that we have in vSphere. So I started to ask why customers weren't using it and these are the responses I got.
1. Some customers don't actually know about this feature and what it does.
Read all about the cool features of SIOC here in Duncan Epping's great blog post<http://www.yellow-bricks.com/2010/09/29/storage-io-fairness/>.
2. Some customers find that it is too difficult to configure.
Well, it is quite straight forward to do. First you have to enable it on the datastores. Only if you want to prioritize a certain VM's I/Os do you need to do additional configuration steps such as setting shares on a per VM basis. Yes, this can be a bit tedious if you have very many VMs that you want to change from the default shares value. But this only needs to be done once, and after that SIOC is up and running without any additional tweaking needed.
3. The feature is not granular enough.
I have heard that some customers want IOPS to be managed via resource pools in much the same way as CPU and Memory resources can be configured. Using this method, a group of VMs residing on a datastore can be given a maximum number of IOPS to use, and a different group of VMs placed in a separate resource group, but on the same datastore, can be given another maximum amount of IOPS. This would allow a more granular approach to controlling I/O, as well as easing the configuration steps, and give it the same look and feel as we have for resource pools right now. Right now SIOC works off of all the VMs on the whole datastore, but we may look at this at a later date.
4. Customers who require all VMs to get equal access to the datastore don't believe that they need SIOC.
The thing is, without SIOC, you could definitely hit this noisy neighbour problem where one VM could use more than its fair share of resources and impact other VMs residing on the same datastore. So by simply enabling SIOC on that datastore, the algorithms will ensure fairness across all VMs sharing the same datastore as they will all have the same number of shares by default. This is a great reason for admins to use this feature when it is available to them. And another cool feature is that once SIOC is enabled, there are additional performance counters available to you which you typically don't have.
5. Some customers are finding it hard to identify the correct latency threshold to set on the datastore.
I admit that this can be difficult to determine, and that we currently set a 30ms threshold by default, without ever profiling the underlying datastore to see if this is an ideal threshold. However 30ms is an appropriate threshold for most applications. All I can say at this point is that we understand that this is a concern, and we are actively working on a mechanism to automatically determine an appropriate latency value for datastores. In the meantime, you may want to have a discussion with your storage array vendor, as they often make recommendations around latency threshold values for SIOC.
6. Some customers mentioned that they are seeing 'external workloads' causing issues for SIOC.
One reason that this can occur is when the back-end disks/spindles have other LUNs built on them, and these LUNs are presented to non ESXi hosts. Check out KB 1020651<http://kb.vmware.com/kb/1020651> for details on how to address this.
7. Certain customers couldn't use it because they do not have correct licensing edition.
SIOC does indeed require Enterprise Plus.
8. Lastly, some customers are using a version of vSphere that doesn't have SIOC.
For block storage you would need to use vSphere version 4.1 or later. For NAS storage, you would need to use vSphere version 5.0 or later. In this case, these customers will need to update to a newer version of vSphere to use SIOC. Its a great reason to upgrade.
If you are not yet using Storage I/O Control, I would be interested in hearing why. If there is some other concern which is preventing you from using this feature, I would also like to hear from you. Please feel free to leave a comment.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: [http://blogs.vmware.com/.a/6a00d8341c328153ef014e8a7e2282970d-800wi] <http://twitter.com/#%21/VMwareStorage> @VMwareStorage<http://twitter.com/#%21/vmwarestorage>
