Several Virtual Machines Could Depend on the Same Storage System
Virtualization allowed many computers to exist on the same physical infrastructure, but sharing hardware also meant sharing its limitations.
Several virtual machines could store their virtual hard disks on the same storage system. Each machine might appear independent to its users, yet their requests ultimately had to travel through common physical disks, controllers, network connections, and storage servers.
When one workload became unusually demanding, the effects could therefore extend beyond that single virtual machine.
Virtual Machines Shared More Than a Server
Separating workloads into virtual computers did not create separate physical storage for each one. Behind the virtualization layer, many machines could still compete for the same underlying resources.
Heavy Disk Activity Could Affect Machines That Had Done Nothing Wrong
Imagine several virtual machines using the same storage infrastructure. Most are performing ordinary work, but one suddenly begins generating a very large number of storage operations.
Perhaps it is processing a database workload, creating files, running an intensive application, or performing another task that continuously requests data from storage.
If that workload consumes a disproportionate amount of available storage performance, the other virtual machines may begin waiting longer for their own requests to complete.
The Busy Machine Did Not Need to Fail
A virtual machine could operate exactly as instructed and still create a performance problem simply because its workload demanded far more shared storage resources than its neighbors.
Performance Had to Be Managed Instead of Merely Observed
Monitoring storage activity could reveal that one workload was unusually demanding, but seeing the problem was only part of the solution.
Administrators also needed a mechanism for deciding how much storage performance different virtual workloads should receive.
Windows Server 2016 expanded Storage Quality of Service into a centralized system for monitoring and managing storage performance across virtualized environments.
Quality of Service Was About Predictability
The objective was not simply to make storage faster. It was to control how shared storage performance was distributed so that individual workloads behaved within defined expectations.
Storage Activity Could Be Measured as Operations Per Second
Storage performance can be described in several ways, and one important measurement is the number of input and output operations performed each second.
This measurement is commonly expressed as IOPS.
By using normalized IOPS as part of Storage Quality of Service, Windows Server could measure storage activity in a consistent way and apply performance policies to virtual hard disks and workloads.
A Storage Request Was a Resource Consumption Event
Reading or writing data required the storage infrastructure to perform work. When those operations multiplied across many virtual machines, controlling their distribution became increasingly important.
One Virtual Machine Did Not Need Unlimited Access to Shared Performance
A Storage QoS policy could establish an upper performance limit for a workload.
That meant a virtual machine generating enormous storage demand did not necessarily have to be allowed to consume everything the shared system could provide.
Limiting its storage activity could preserve resources for other machines using the same infrastructure.
Maximum Performance Was Not Always the Goal
In shared infrastructure, allowing every workload to run without limits could produce excellent performance for one machine while creating unpredictable performance for many others.
Important Workloads Could Have a Performance Reservation
Storage Quality of Service could also define a minimum IOPS value.
This represented a performance goal for a workload rather than simply a ceiling. An important virtual machine could therefore have a defined storage expectation that administrators could monitor.
If the storage system could not satisfy the policy, administrators could be alerted that the workload was operating outside its intended performance level.
A Policy Made Performance Expectations Visible
Instead of discovering a storage problem only after users complained about a slow application, administrators could compare actual behavior with defined performance goals.
Policies Did Not Have to Be Managed as Isolated Disk Settings
The important development in Windows Server 2016 was the ability to manage Storage QoS centrally across supported virtualized storage environments.
A policy manager could observe storage flows and coordinate performance policies rather than treating every virtual hard disk as an unrelated object.
This made storage performance management more practical when an environment contained numerous virtual machines and many virtual disks.
Scale Changed the Value of Central Management
Adjusting one virtual disk manually may be manageable. Maintaining predictable behavior across dozens or hundreds of virtual workloads requires a broader view of the storage system.
Administrators Could See End-to-End Storage Performance
A performance problem experienced inside a virtual machine does not necessarily originate inside that machine.
The request may pass through the virtualization host, network, file server, and physical storage before the operation is completed.
Storage QoS provided centralized monitoring that helped administrators examine how virtual machine storage workloads were behaving across that shared path.
Slow Storage Had Context
Knowing that a virtual machine was waiting on disk activity became more useful when administrators could also see how its storage workload related to the other machines using the same infrastructure.
Different Workloads Did Not Need Identical Storage Rules
Not every virtual machine served the same purpose.
A critical application server, a lightly used utility machine, and a demanding development workload could all have very different performance requirements even while using the same storage system.
Storage QoS policies provided a way to organize those requirements instead of assuming that every workload deserved an unrestricted and identical claim on the available resources.
Fair Did Not Always Mean Equal
Resource management could reflect the needs of the workload. Some machines might require stronger guarantees while others could operate comfortably with stricter limits.
Windows Server 2016 Could Limit More Than the Number of Operations
The amount of data transferred and the number of storage operations are related but are not identical measurements.
A workload might perform many small operations, while another might move large amounts of data using fewer operations.
Windows Server 2016 added the ability for Storage QoS policies to specify maximum bandwidth, giving administrators another way to control how aggressively a workload could consume shared storage resources.
Two Workloads Could Stress Storage Differently
Counting operations helped describe one dimension of storage demand, while bandwidth helped describe how much data those operations were moving.
Not Every Storage Operation Represented the Same Amount of Work
A tiny storage request and a much larger request should not necessarily be treated as equivalent when measuring workload demand.
Storage QoS therefore used normalized IOPS, where larger operations could count as multiple normalized operations rather than always being counted as one.
Windows Server 2016 also allowed the normalization size used by the storage cluster to be configured, providing additional control over how storage activity was measured.
Measurement Had to Match the Resource Being Managed
A useful performance policy depended on meaningful measurements. Normalization helped prevent dramatically different I/O sizes from appearing identical simply because each arrived as a single request.
More Virtual Machines Meant More Opportunities for Resource Contention
As physical servers became capable of hosting increasing numbers of virtual machines, the efficiency of virtualization created a new management challenge.
Consolidating workloads saved hardware, space, and administration effort, but those workloads still depended on finite processors, memory, networking, and storage.
The denser the environment became, the more important it was to prevent one workload from unexpectedly dominating a shared resource.
Consolidation Needed Resource Governance
Virtualization made it possible to place many independent systems on shared infrastructure. Quality-of-service controls helped keep that sharing from turning into uncontrolled competition.
Disk Access Was No Longer Simply First Come First Served
Storage had traditionally been discussed in terms of capacity and raw speed: how many gigabytes were available and how quickly the disks could transfer information.
Virtualized infrastructure added another question. How should that performance be distributed among all the machines depending on it?
Storage Quality of Service helped answer that question by turning storage performance into something administrators could monitor, allocate, limit, and evaluate through policies.
Performance Became Part of Infrastructure Policy
The storage system was not merely a pool of capacity beneath the virtual machines. Its performance could be governed as deliberately as other shared computing resources.
Windows Server 2016 Made Shared Storage More Predictable
A single demanding virtual machine could once create a problem that appeared mysteriously inside several unrelated machines.
The underlying cause was not necessarily a fault in those other systems. They could simply be waiting behind a workload consuming too much of the shared storage resource.
Centralized Storage Quality of Service gave administrators a way to recognize that relationship and establish rules for how storage performance should be distributed.
Virtual machines could be isolated from one another logically while still competing for the same physical resources underneath them.
Windows Server 2016 Put Rules Around Shared Storage Performance
Storage Quality of Service helped transform storage performance from an uncontrolled shared resource into something that could be monitored and governed across virtual machines.
Minimum performance goals could identify workloads that were not receiving the storage service expected of them, while maximum limits could restrain workloads consuming more than their intended share. Centralized policies made those controls practical across larger virtualized environments.
The result was not simply faster storage. It was more predictable storage. When many virtual machines depended on the same infrastructure, Windows Server 2016 provided a way to keep one exceptionally demanding neighbor from deciding how well everyone else could perform.
