Storage Storage Quality of Service (QoS)


Windows Hyper-V Server allows you to run lots of virtual Windows machines (VMs)on a single physical server. Scale-Out File Server lets you store server application data, such as Hyper-V virtual machine files, on file shares. While this is a great way to optimise the use of hardware, all these virtual machines need to be managed, to ensure that they get a fair share of the storage and server resources. Storage Quality of Service (QoS) is designed to manage storage performance for VMs, by setting policies for individual VMs to ensure that a given VM gets enough resources, without hogging them at the expense of others.

What can QoS do?

  1. You need to be able to monitor the end to end storage performance of all your VMs, so you can hopefully anticipate problems before your users report them. Storage QoS starts monitoring performance of virtual machines stored on a Scale-Out File Server as sonn as they are started. And, all these performance details can be viewed from a single location
  2. However, monitoring and reporting is not enough, you need to be able to intercept and automatically fix problems as they happen. Storage QoS can throttle an application that is hogging resources at the expense of other workloads, in fact, Storage QoS will stop one virtual machine from hogging all the storage resources by default.
  3. You can tailor policies to manage throughput in terms of IOPs or MB/second for different storage virtual machine (SVM), volumes, LUNS, or VMDK files within an SVM. For example, instead splitting different types of workload onto different dedicated resources, you can define policy groups for critical production, less critical production, application testing and development, and run all these workloads together. Storage QoS will then ensure that the dev/test workloads do not adversely affect the production workloads.
  4. Within these policies, you can set both maximum and minimum performance levels. Why would you need a maximum limit? Well, imagine that you are implementing a shared cloud environment, where individual customers have SLAs. The first customers onto the cluster would get excellent performance, probably exceeding their SLA. As more customers are added, that performance will drop, and while it will still be within SLA, it could be perceived as an issue by the customer, who is not getting the performance she was used to. If you use maximum performance levels from the start, then you will manage the performance expectations of your customer better.
    Now all this sounds good, but in real life, you will be adding more and more applications into the mix, until eventually the environment becomes overprovisioned and SLA performance cannot be met automatically. When this happens, Storage QoS can send alerts to warn that VMs are out of policy

QoS Terminology

Here is some defintions for Storage QoS terms

Normalized IOPs
IO operations to disk move different amounts of data, depending on what the application is doing. Larger IOs take longer by definition, so to get a sensible time comparison between IOs, Normalised IOPs (Input/output operations per second ) are used. By default, any IO that is 8KB or smaller is considered as one normalized IO. Any IO that is larger than 8KB is broken down into multiples of 8KB. So, a 512KB IO would then be 64 normalized IOPs.
With Windows Server 2016, you can change this default 8KB value and chose your own value for a normalised IOPs.
A flow can be thought of as the storage connections used by a VM. Every VM will have files open on a VHD, and every open file handle that is opened by a Hyper-V server to a VHD or VHDX file is considered a 'flow'.
This is the name of the virtual machine
This is an identifier that matches the virtual machine ID. VMs can have identical Initator Names, but the Initiator ID is always unique.
The Storage QoS policies contain the properties that are used to manage the VM performance. These include the PolicyId, MinimumIOPS, MaximumIOPS, ParentPolicy, and PolicyType; and are stored in the cluster database.
This is an Unique identifier for a policy.
The minimum number of normalized IOPS that Storage QoS will try to deliver. It is sometimes called the 'Reservation'.
The Maximum number of normalized IOPS or the 'Limit' that will be applied by Storage QoS to VMs with this policy.
A type of policy type where the specified MinimumIOPS & MaximumIOPS and Bandwidth are shared among all flows assigned to the policy.
A type of policy type where the specified Minimum & MaximumIOPs and Bandwidth are managed for individual VHD/VHDx.

Storage QoS Deployment Scenarios

Storage QoS supports Hyper-V using a Scale-Out File Server or Hyper-V using Cluster Shared Volumes.
The Hyper-V with Scale-Out File Server scenario requires both a Storage cluster that is a Scale-Out File Server cluster and a Compute cluster that has least one server with the Hyper-V role enabled. The Failover Cluster is required on Storage servers, but the compute servers are not need to be in a failover cluster. However all the servers must be running Windows Server 2016.

The Hyper-V with Cluster Shared Volumes requires both a Compute cluster with the Hyper-V role enabled and a Hyper-V using Cluster Shared Volumes for storage. A Failover Cluster is required and all servers must be running the same version of Windows Server 2016.

As Hyper-V servers launch virtual machines, they are monitored by the Policy Manager. The Policy Manager communicates the Storage QoS policy and any limits or reservations back to the Hyper-V server, which controls the performance of the virtual machine as appropriate. When there are changes to Storage QoS policies or to the performance demands by virtual machines, the Policy Manager notifies the Hyper-V servers to adjust their behavior. This feedback loop ensures that all virtual machines VHDs perform consistently according to the Storage QoS policies as defined.

back to top