Fast storage does not guarantee that every workload sharing it will receive predictable performance. Several systems can be reading and writing at the same time, and one unusually demanding workload can consume enough resources to affect everything around it.
Storage Quality of Service introduced a way to manage that competition centrally. Instead of watching individual disks and reacting after performance deteriorated, administrators could define storage performance policies and monitor whether workloads were operating within them.
The storage system could monitor demand across workloads and use policies to establish minimum or maximum performance objectives rather than allowing every workload to compete without limits.
Shared Storage Created a Competition Problem
A storage system has a finite amount of performance. Drives, controllers, network paths, caches, and processors all contribute to how many operations can be completed and how quickly those operations finish.
When many workloads share those resources, their demands are rarely identical. One may generate occasional small requests while another continuously produces heavy I/O.
- A busy workload can create substantially more storage requests than its neighbors
- Several workloads can become busy at the same time
- Available performance can change as demand changes
- High storage latency can affect an application even when processor and memory usage remain normal
- One unusually demanding workload can reduce the performance available to others
This behavior is sometimes described as a noisy-neighbor problem. The workload causing the contention may be functioning normally from its own perspective while still consuming a disproportionate share of a common resource.
IOPS Became a Useful Way to Describe the Demand
Storage performance can be discussed in several ways. Throughput describes how much data is transferred over time. Latency describes how long an operation takes. IOPS describes the number of input and output operations completed each second.
Simply counting requests, however, can be misleading because storage requests are not necessarily the same size. A small operation and a much larger operation can place very different demands on the storage system.
Storage QoS could express activity as normalized input and output operations. An operation at or below the configured normalization size counted as one operation, while larger requests were counted as multiple normalized operations according to their size.
The default normalization size was 8 KB, although the storage cluster could use a different normalization size. This gave the policy system a more consistent unit for comparing storage activity.
A Policy Could Put a Ceiling on Storage Activity
| Policy control | Purpose |
|---|---|
| Maximum IOPS | Restricts how many normalized storage operations the applicable workload can consume |
| Minimum IOPS | Defines a performance reservation or objective that the system attempts to provide |
| Maximum bandwidth | Restricts the amount of storage data that can be transferred over time |
| Performance monitoring | Reports IOPS, bandwidth, latency, and policy condition for monitored storage flows |
A maximum was useful when a workload needed to be prevented from consuming excessive storage performance. Instead of allowing its demand to grow until another workload suffered, the policy could establish a boundary.
Bandwidth could also be limited. This mattered because a workload performing large transfers could consume substantial throughput even when its operation count did not appear unusually high.
A workload can reach an IOPS limit because it performs many operations or reach a bandwidth limit because it moves large amounts of data. When both controls are configured, whichever boundary is reached first can become the effective restriction.
A Minimum Was Different From a Maximum
A maximum establishes how much performance a workload is permitted to consume. A minimum addresses the opposite concern by describing performance that should remain available to a workload.
This did not manufacture storage performance that the underlying hardware did not possess. If the combined demand and configured reservations exceeded what the storage infrastructure could deliver, the system could report that the policy objectives were not being satisfied.
A storage policy could describe the performance a workload should receive, but the physical storage still determined how much performance actually existed.
This distinction made monitoring important. A policy was not merely a throttle. It also provided information about whether the infrastructure was capable of meeting the expectations assigned to it.
The Control Point Could Be Centralized
Managing storage limits independently on many machines becomes difficult as an environment grows. A setting that makes sense when only a few workloads exist may become inappropriate when dozens of workloads begin sharing the same storage.
Storage QoS introduced centralized policy management for supported clustered storage configurations. The policy manager could observe storage flows and communicate the applicable limits or reservations back to the systems controlling those workloads.
Storage activity could be monitored across the shared infrastructure instead of considering each workload in isolation.
Policies could establish performance boundaries or reservations for selected storage flows.
Administrators could see whether workloads were operating within the conditions expected by their policies.
The important change was the scope of the decision. Storage performance management could become an infrastructure function rather than a collection of unrelated settings scattered among individual workloads.
Several Virtual Disks Could Share One Policy
A policy did not necessarily have to describe only one virtual disk. Storage QoS supported policy models that allowed performance controls to be associated with multiple storage flows.
This made it possible to think about storage allocation according to the workload or service being protected rather than treating every virtual disk as an unrelated object.
Storage performance limits could be associated with the workload that needed them, allowing management decisions to follow service requirements instead of depending entirely on where a particular virtual disk happened to reside.
Latency Revealed Problems That Raw Speed Could Hide
A storage system can still transfer a large amount of data while individual requests are taking longer than expected. Looking only at total throughput can therefore hide a problem that users or applications experience as slowness.
Storage QoS monitoring included latency information alongside operation and bandwidth measurements. This helped distinguish between a workload that was simply busy and one whose requests were waiting too long for the storage system to respond.
Contention possible
When demand rises while response times deteriorate, the underlying storage may be approaching a performance boundary. Policy information can help identify whether one workload is consuming excessive resources or whether the infrastructure itself lacks sufficient capacity.
A Limit Could Improve Fairness Without Making Storage Faster
Quality of Service did not increase the physical performance of a drive array. A storage system capable of a certain amount of work remained constrained by its hardware and configuration.
What changed was how that performance could be distributed.
Without controls, the workload generating the most requests may obtain a large portion of the available resources. With appropriate policies, storage activity could be managed so one workload was less able to overwhelm others sharing the same infrastructure.
This distinction is important because performance management and performance expansion solve different problems. Faster hardware increases available capacity. Quality of Service determines how existing capacity can be monitored and allocated.
Storage Performance Became Part of Resource Management
Processors and memory had long been treated as resources that could be measured and allocated among workloads. Shared storage introduced the same fundamental problem, but the effects were often less obvious because the contention occurred beneath the applications using it.
Storage Quality of Service brought that competition into a manageable framework. Operations could be measured using normalized IOPS, bandwidth could be constrained, minimum performance objectives could be defined, and latency could reveal when the underlying system was struggling to keep up.
The larger change was not simply the ability to slow down an overly active workload. Storage performance could now be treated as a resource with expectations, boundaries, and observable behavior. That made it possible to manage shared storage according to the needs of the workloads using it rather than leaving every application to compete for whatever performance happened to be available.
