What do you do when a virtual machine becomes a noisy neighbor?
The #1 pain point in the data center is poor performance. That’s what we found from our study of 1,000 data center professionals, who every day watch virtual machines (VM) conflict with databases, slow each other down, and eat up hours spent fine-tuning storage and tackling trouble tickets.
A huge contributor to this performance pain is what’s called “the noisy neighbor problem” — a VM consuming too many resources at the expense of others.
The problem stems from LUNs, the conventional storage groups made up of dozens or even hundreds of VMs. When one of them gets noisy, demanding more than its share of performance reserves, it slows down its neighbors and throws the entire LUN into chaos.
Because they’re built on that LUN architecture, most storage environments running VMs face this challenge. Stopping these rogue VMs is difficult because they’re nearly invisible to scrutiny and correction.
Here’s how you put the issue to rest and guarantee every VM’s performance: isolation. By eliminating the LUN and giving every VM its own neighborhood through VM-aware storage, you can more precisely control the resources apps can demand.
Give the noisy neighbor plenty of space
Highways have several lanes that all cars use. When the road is clear, each car has the space to maintain speed and get where it’s going on time. But cars can get stuck behind vehicles moving too slowly, and the entire road slows down at certain times of day due to volume. If there’s an accident, all traffic halts, sometimes because of just one other car. In an ideal world, every car would have its own lane, meaning any problem cars would only affect themselves.
That’s essentially what you can accomplish through isolation in a VM-aware storage environment. You gain more control over how much performance each VM reserves, including a guaranteed minimum amount or maximum ceiling. By guaranteeing performance or introducing artificial latency, data center managers can set quality of service (QoS) for IOPS.
Minimizing noisy neighbors, maximizing performance
Imagine you have an isolated VM that has gone rogue. It’s not disrupting neighbors, but it is using more resources than it deserves. With QoS for IOPS, you can set a hard ceiling to limit the maximum IOPS available to that individual VM. It’s rogue no more (Figure 1).
Figure 1 – lowering the “max” QoS for IOPS ceiling can keep a rogue VM in check
The opposite is possible, too. If there’s a mission-critical VM in your environment that cannot suffer from limited resources, you want it to receive a minimum baseline of performance resources. Isolating the VM and setting a minimum QoS for IOPS ensures it’s never impeded by noisy neighbors (Figure 2).
Figure 2 – raising the “min” QoS for IOPS guarantees performance for a mission-critical VM
Notice that the lower portion of both figures visualizes latency. It shows you the impact of your changes to QoS in real time, so you can make further adjustments as necessary with simple, visual feedback.
Better resource allocation through proper VM management
This is all possible, but not with traditional storage infrastructures. Classic LUN architecture prevents true visibility. Data center managers know what VMs are assigned to each LUN, but it’s unclear which VM is affecting performance and it takes time to determine the root cause of the slowdown.
To maintain top performance of all virtualized applications, you need VM-aware storage. That’s the only way to isolate each VM, gain full visibility into its behavior, and assign it a QoS. A VM-aware architecture allows data center analysts to see what’s using resources, making it much easier to troubleshoot and identify the noisy neighbors.
Even more powerful is grouping related VMs and setting QoS for IOPS at the service group level. This allows you to share a policy across similar VMs. Better yet, if you need to re-shuffle service groups, the QoS policies attached to each VM follow it to its new service group.
That’s the kind of visibility and control that enables consistent performance for all your virtualized applications.
Is performance your top pain point, too? What questions do you have about VM-aware storage and isolating VMs? Leave a comment below or contact your SHI representative today.
About the author
Brandon Salmon has been working in systems and storage for over 12 years. He has a Ph.D. in computer engineering from Carnegie Mellon University and a bachelor’s in computer science from Stanford. He has worked at Microsoft, VMware, and Intel in the past. As the sixth engineer at Tintri, he designed and built significant portions of both the core Tintri filesystem and integrations with private cloud environments. He now works in the Office of the CTO investigating market changes and new technologies.