How to Reduce the Problem of Noisy Neighbor VMs in the Datacenter
This blog addresses how to reduce the problem of noisy neighbor VMs in your datacenter. What do we mean by a noisy Virtual Machine (VM) in the datacenter? How does the operational performance of a noisy VM negatively impact neighboring VMs and what can you do about the noise? If you’re in DevOps, these are performance questions you probably need to answer.
A high percentage – more than 75% – of workloads run in shared resource datacenters. By shared resource or virtualized, we mean that the work is done on a VM running an OS under a Hypervisor or Supervisor to dynamically share compute resources and storage.
Noisy VMs are resource hogs. They consume a disproportionate amount of datacenter resources. The compute resources managed by DevOps fall into four broad categories:
- Network bandwidth
- storage I/O
- CPU or processor
- other peripherals on the network, such as backup storage, printers, scanners or optical storage
When a VM sucks up all the resources, for example available bandwidth or I/O, the performance of neighboring VMs suffer because they can’t get a fair share of the resources needed to do their work. So, neighboring VM experience poor performance, network latency, or both.
Noisy neighbors kill the performance of nearby VMs running in the same processing window, whether you are running on shared datacenter servers or in the cloud. Once you’ve opted for a shared service with multiple VMs, you have opened the door for the noxious performance impacts of noisy VMs.
A range of technical innovations have been developed to deal with the noxious impacts of noise. For example, the disk I/O impacts of noisy neighbors can be reduced by doing in-memory processing. Also, VM aware storage helps minimize performance impacts, as do dynamic provisioning and load balancing techniques. Nonetheless, the main way that DevOps deals with high noise levels is to over provision datacenter resources. Simply put, instead of provisioning the datacenter to average VM load, the datacenter is designed to deal with the peak resource loading of noisy VMs and all their neighbors. Overprovisioning is an expensive strategy.
What if we could redesign the average resource requirements of a VM in advance? While some VMs may be noisier, it’s possible to design shared VMs to have a tighter normal distribution of resource requirements. VMs can be configured to have similar noise levels, so the datacenter resources can be provisioned closely to the average load rather than peak load, thus minimizing the noxious impacts of noisy neighbors. This is called average resource loading.
How do we redesign VM resource requirements?
You can reduce the problem of noisy neighbor VMs via average resource loading. This can be designed during a development cycle if the workload that runs in a VM is new and designed for a virtualized environment or multi-tenant cloud infrastructure.
But what about legacy workloads that are moved to a VM? How legacy workloads are virtualized can significantly reduce the efficiency and performance of today’s datacenter. It turns out that VMs cloned from legacy servers are inefficient and often noisy.
Proliferating noisy legacy VM sprawl
The workload running in a datacenter is often a cloned image of a legacy server. After some reconfiguration effort, the clone replicates the OS and applications on the original physical hardware. VMs are cloned without giving thought about the unit of work that should be virtualized. The unit of work becomes the entire cloned machine.
Virtualizing entire legacy servers can cause the following problems:
- Proliferation of differing legacy OS instances and patch levels
- Replication of cluttered log files, broken and unnecessary applications, drivers, and utilities
- Increased management costs and increased VM noise
- Difficulty balancing workloads and reducing VM noise in the datacenter
If you’re loading storage clutter and not pre-sizing VMs, you’ll end up slowing down performance and over spending in your datacenter.
To reduce the average noise level, legacy VMs should be built on a standard greenfield OS image and run only core application stacks. Deviate from this and it becomes difficult to use modern DevOps tools for OS management, which reduces datacenter efficiency. Cloning VMs means that the storage needs to be identical on the original machine and the VM clone. More than 50 percent of VM storage is often unnecessary sprawl and slows the loading and performance of VMs.
How do I reduce the average noise of legacy VMs in my datacenter?
Start by monitoring legacy servers or current VMs. Before you move legacy workloads to new VMs, figure out what apps you need, then be smart about how you move workloads. Monitoring helps you think ahead, prioritize, and size VMs to an average resource load.
1 Virtualize and run only what you need
Instead of cloning entire machine images, use smart, automated application monitoring to dynamically discover application usage, server and workload capacity requirements, application dependencies, and migration readiness. Intelligent monitoring discovers which applications are still used, establishes priorities, reveals application and storage clutter, and helps you plan and size target VM resource requirements.
Virtualizing only business-critical applications saves significant time and money on bandwidth, processing, ongoing storage, and management. No need to move an OS or apps no one uses, and no need to pay for clutter on virtual servers.
2 Consolidate or split workloads
Intelligently moving legacy applications (not entire machines) allows you to consolidate multiple workloads to a single VM or split application stacks across multiple VMs. Both these approaches will make your datacenter easier to manage and scale, and lets you manage the noise level (resource requirements) of VMs.
3 Up-level your apps
Instead of copying an outdated OS version and its patches to VMs, use virtual application migration to up-level OS versions. Reduce VM noise by moving applications from legacy OS environments like WS2003 or WS2008 to modern, easier to manage greenfield OS versions on WS2012 and WS2016. Uplifting applications to a modern, hosted OS instance can be done for less than one-quarter of the network bandwidth, storage, and processing required for full legacy VM cloning. Up-leveling also closes security exposures inherent in legacy OS instances.
4 Use advanced cloud tools
A modern greenfield OS with a standard release level lets you use advanced datacenter and cloud tools to monitor and manage application usage and reduce VM noise levels. You avoid the ongoing nightmare of patching and maintaining diverse legacy OS instances. Better OS management and fresh legacy application installs means less noisy operations with:
- Optimized storage
- Improved performance
- Paying for business-critical resources only
5 Reduce reconfiguration costs
Smart application migration significantly reduces your reconfiguration burden. You can reconfigure applications on-the-fly and remap IP addresses and other critical application setups. Plus, greenfield OS instances come preconfigured with the drivers and other custom configurations they need. Reducing your reliance on reconfiguration in turn reduces setup problems, saves time, and reduces system cut-over delays, letting you move and scale to meet business demands faster.
If you’d like to learn more about how to reduce legacy VM noise in your datacenter and improve QoS, give us a call, register for a free demo, or send us an e-mail. We’re always delighted to show you what we can do.