Whether you're walking a physical tightrope or maintaining a virtual infrastructure, you need one key element for success: Balance.
Learning to balance virtual workloads in a virtual infrastructure isn’t easy in the midst of supporting that infrastructure, keeping users happy, and contiually answering the call to allocate or reallocate resources (bandwidth, space, access, memory, CPU, and time). Do you rely on your vendor’s resource scheduling algorithms or do you take the balance pole into your own hands and walk the tightrope yourself?
Like it or not, managing resources is what you do in a physical, virtual, or mixed environment and well how you manage those resources directly affects your user’s experience.
When allocating memory to a virtual machine, you should follow the recommended guidelines for the operating system and for the application that it hosts. Never use the minimum suggested RAM for production operation. Some virtualization software allows you to specify a starting amount of RAM. This amount is for booting the operating system only and not meant for supporting users and applications. This ability to specify an amount of RAM, and dynamically change it when the need arises, is one of the most valuable aspects of virtualization — to increase and decrease resources at will. How many people do you know who’ve taken RAM out of a physical machine because it has too much? With virtual machines, it is common practice to “right size” your resources once you’ve gotten a handle on their consumption.
How many CPUs should a virtual machine have?There is some debate about this aspect of virtualization but most vendor experts will tell you that one is usually sufficient for most situations. If you need more than one, use it but be aware that your host machine has to have sufficient CPU horsepower to power it and all the other VMs adequately.
A resource pool is a collective of donated host system memory, CPU, networking, and space available for virtual machines to use. These resource pools allow you to dynamically allocate resources based on usage and the needs of your virtual machines. When a new VM is added to a pool, it’s added to the system that can best handle the new load.
Using resource pools allows you to limit resources for particular jobs, environments, or groups. For example, if you have test, development, and production environments in your data center, you certainly don’t want the test or development groups to grab or use resources from production. It is not only wise to segment your resources into pools but it may avert disaster in the future. Placing an upper limit on CPU and memory in your resource pools will also help deter virtual machine sprawl by limiting the available resources from which to pull.
Both VMware and Xen include automated resource scheduling. Using pooled resources, your hypervisor balances workloads based on complex algorithms that move workloads off of overworked systems and place them on less-utilized ones. This load balancing is tricky work but generally works well for most applications, however there are times when even the best algorithm can’t replace the human touch for appropriately balancing workloads.
When human intervention in workload management is necessary, both major virtualization vendors step up nicely with their own mobility tools: VMotion for VMware and XenMotion for Xen. These tools are invaluable to administrators for those “hot” migrations that often have to be performed to relieve a bottleneck or to avoid one completely. Using them, you can move an active system from one host to another without service interruption. You can move the workload of a VM or the actual VM itself with no preparation, shutdown, or other service hiccup. As you might expect, there is a slight performance hit when migrating a workload but it’s hardly noticeable compared the performance boost that follows. Migrating the physical disk structure of a VM from one host to another results in a more significant performance hit but the machine stays online, connected, and performing its required functions during the entire move. A performance drag for a few minutes is much more desirable as compared to an actual outage that you’d take to shutdown, move, and then restart the VM for a manual move.
Next week, in Walking the Workload Tightrope Part 2, I’ll give you some practical advice on examining workloads and assessing performance so that you can make informed workload balancing decisions.