Petya Petrova - Fotolia
Virtualization administrators who successfully allocate resources to their VMs often have better system performance due to reduced resource contention. But right-sizing VMs can introduce challenges such as software-based limits and pushback from application owners. Admins must consider their systems' CPU, memory, I/O and networking capabilities before they right-size VMs to ensure suitable resource allocation.
Virtual system expansion and software-defined technologies can be a lot of work for admins to keep up with and ensure everything keeps moving along. But has anyone ever stopped to take a look at the workloads once they put them in their virtual systems?
It's a simple question, but its effect is huge. Admins often spend a lot of time estimating what they must allocate when they move workloads into a virtual system. For example, admins might set up monitoring software to ensure their systems continue to function.
But how often do admins right-size system components, such as VMs, to fit the workload after installation? If admins underestimate on what resources a VM requires, they can easily add additional resources without even turning off the VMs themselves. But do admins ever reduce what resources a VM has even if there is an overage? In short, the answer is generally no.
Resource allocation challenges
To reduce allocated resources, admins have to shut down the VM, which limits remote access and can lead to long startup times. Too often admins use resource pools and other software-based limits to control what resources a VM might use. This is a short-term fix that builds on over-allocation issues and software restrictions that can lead to resource contention.
This is where right-sizing VMs becomes critical. Admins' workloads change based on usage, and ensuring correct VM resource allocation is crucial to overall system health.
Right-sizing VMs for suitable resource allocation
As admins look to right-size their VMs, they should start with the four main system metrics: CPU, memory, I/O and networking. But they should realize that they generally only can control two of these system metrics.
Though admins can put restrictions on both I/O and networking, they can't easily increase these resources to VMs without some type of hardware investment. This doesn't mean admins should ignore I/O and networking, but they should understand the limits of what they can easily control. This places more emphasis on CPU and memory, which are the two key metrics that admins often over-allocate.
Admins' monitoring software and the trends it displays over time are a critical gauge of where to make adjustments. The key is to balance this with the reasons admins allocated their resources in the first place. Admins don't want to simply reduce the resources based on current system metrics.
If admins plan for a VM to grow quickly, or it has yet to reach its full user base, admins must balance this with current system metrics and make a decision based on both sets of inputs. What admins should avoid is scheduling a downtime to reduce resources, only to have to add those resource back in because of unaccounted VM growth or change.
This also brings up the topic of actual resource reduction. Admins who attempt to remove a vCPU or reduce memory will often receive pushback from application owners. To avoid any issues, admins must take a slightly different approach. In truth, admins generally don't have to overshare the details of planned resource reduction. If a VM is moving from an older cluster to a newer one with better hardware, admins are simply optimizing the VM for the new system.
Admins don't need to go into detail of what exactly they did. Rather, admins should communicate to the application owner about optimization efforts within the system. It won't be easy to get people out of the numbers mindset when it comes to resources. Many might assume that more resources mean better performance, but with steady effort it is possible and worth the effort.
Optimization efforts are easiest when admins can schedule them with changes to their systems, such as software updates or patches. It makes it easier to schedule the downtimes, but admins shouldn't let system changes be the only driver.
Every three to six months, admins should check resource allocation versus what is in use. This provides admins with enough data to have a historical view of resource trends to better make decisions. This also gives admins the opportunity to review consumption of system resources for an accurate picture of their allocations. This helps admins plan when they must add additional hardware and what VM resource consumption looks like in the future.