Fine-Tuning Hyper-V with Storage QoS

One of the more exciting features of Microsoft Windows Server 2012 R2 Hyper-V is Storage Quality of Service. QoS enables IT admins to control the minimum and maximum number of IOPS a virtual machine can consume. This is an important feature in the cloud era for many reasons.

For starters and to tackle the obvious, we want to be able to control the "noisy neighbor" VMs. This is a situation when a particular VM for a number of reasons is consuming most of the IOPS and limiting the available IOPS for the rest of the VMs, thereby degrading performance.

Controlling IOPS is important for multi-tenant purposes, but another equally important use case could be to suggest a price band for the availability of IOPS to VMs. For instance, you might be charged by your cloud service provider based on the amount of IOPS you request. Storage QoS provides a mechanism for them to limit the IOPS and run allowed for chargeback. Conversely, on your private cloud you can do similar tasks by guaranteeing a number of IOPS for a particular VM, useful especially as you are starting your cloud journey and as the different departments in your organization are used to paying for their hardware and ensuring complete and uninterrupted access. Storage QoS is a great tool that you can use to provide them with a similar guarantee and also report against it to prove that they are taking max advantage of resources.

Storage QoS allows you to set the maximum number of IOPS per virtual hard disk, as well as a minimum. The idea here is that you can reserve a minimum number of IOPS below which you are saying that the VM would not be running optimally. When a VM is not getting the minimum number of IOPS, it flags a warning message alerting you to take corrective measures. If you are able to accurately pinpoint the minimum number of IOPS that a VM needs and configure it accordingly then I guess this would be pretty useful.

The thing I don't like about this implementation at this stage is that IO throttling is limited to the Hyper-V host and the VMs that live on that host. Hyper-V contains a technology known as the QoS IO Balancer, which is responsible for throttling the IO and ensuring that each VM's reserves are met. The problem is, because this IO Balancer is implemented at the Hyper-V host and because your storage is most likely shared storage accessible by multiple Hyper-V hosts, it is very possible that a VM living on a different Hyper-V host would consume more IOPS and starve your VMs, which aren't governed by the IO Balancer. To get around the limitation (sort of), alerts will kick when a VM is not able to consume its minimum required IOPS. This really explains why the minimum field even exists in this implementation -- it is so that alerts can go off when a VM is starved for IOPS considering the IO Balancer again resides at the host level.

The final analysis is that Storage QoS is a very welcome step for Hyper-V, but I am looking forward to a bit more enhancement in this area in the near future.

Posted by Elias Khnaser on 07/01/2013 at 1:22 PM