How much of virtualization management is art, and how much is science?
If you could see the entire environment and understand every variable involved in optimizing performance in your virtual data center, you’d probably say that it’s all science. Allocating this much memory, that much CPU, these gigabytes of storage and those Mbps of network throughput adds up scientifically to a balanced virtual environment.
But you don’t always see all the variables right from the start. For example, it takes a while to gauge the cumulative effects of multiple VMs on a host, and the work being done in each VM (database, virtual desktop infrastructure, security) affects the resources it needs. So until you have all those variables lined up as a science, you have to rely on art.
In my last post I described the variables of VM density and VM sprawl. This time I’ll cover more of the variables in the art of optimizing your virtualization management.
Image credit: seriykotik1970 | Licensed under: CC BY 2.0
Squeezed connections to storage
You rarely think about bandwidth on a physical server. It has a 100Mbps or GigE adapter that it never comes close to maxing out in everyday use.
But when you have ten or twenty VMs running on that physical server, you can also have a lot of competition for the attention of that adapter, especially if it’s pushing results from SQL queries and hosting remote desktop sessions.
The right storage configuration can make or break your virtualization performance and availability. So the art that will get you to optimization science is to un-squeeze storage connections by adding networking, physical disks and processing until you’ve reduced competition on your adapter.
vSphere introduces another variable. It’s a good idea to apply resource reservations, limits and shares to individual VMs and resource pools. But when you apply them in multiple locations at once, you’re likely to complicate your resource calculations and the effectiveness of vSphere Distributed Resource Scheduler (DRS) load balancing.
Resources in constrained pools are divided at the resource pool first, and constraints are enabled only once there’s contention. Suppose you have 3,000 shares across two pools: a test resource pool with four VMs and 1,000 shares and a production resource pool with 50 VMs and 2,000 shares. Your test pool won’t be a problem until there’s contention in the production pool. But when there is contention, one-third of your vSphere cluster’s resources will be distributed among the four test VMs, while the 50 production VMs must share the other two-thirds. That’s lopsided resource management.
The art to optimizing virtualization management here lies in exercising a far lighter touch than vSphere’s hard constraints. You’re better off avoiding reservations, limits and shares until you understand completely—and can continuously monitor—their effects on the entire environment.
That’s why there’s as much art as there is science in optimizing virtualization management. I’ll cover more virtualization variables in my next and final blog post of this series.
For more concepts and strategies, download our new guidebook, An Expert's Guide to Optimizing Virtualization Management. We wrote it to help you identify areas in your virtualization environment where you can find and recover lost ROI.