Load balancing is an important process that can redistribute VMs to prevent resource contention and cut power consumption,...
but if done incorrectly, load balancing could actually lead to performance problems.
When it comes to VM load balancing, there are a number of considerations that must be taken into account. While it's true that you have to consider nuances specific to the hypervisor you're using, there are also more generalized considerations that must be taken into account.
Are your load-balancing requirements dynamic?
One of the first issues you need to consider is whether your VM load-balancing requirements are static or dynamic. In other words, should VM workloads be load balanced in the same way all the time, or are there periods of time that require a different approach to load balancing? Some organizations, for instance, use automated policies to power VM hosts on and off based on the current workload. Such an organization might set a policy to power down a certain number of hosts on the weekend as a way of reducing power consumption. Similarly, an organization might bring a few extra hosts online during periods of anticipated heavy activity. In either case, hosts are powered on and off automatically based on policy settings. Load balancers then distribute VM workloads based on the number of hosts that are currently online.
How aggressive do you want load balancing to be?
Another thing you need to consider is how aggressively workloads should be load balanced. Each hypervisor vendor has its own way of doing things, but VM load balancing commonly involves moving running VMs from one host to another so that each host ends up running a comparable workload. Although this technique sounds simple enough, there are two factors that tend to complicate things.
First, VMs can be very dynamic. A VM might suddenly consume more CPU or memory in response to a demand spike.
Second, moving VMs between hosts can be a resource-intensive process. The migration process consumes CPU, memory and network resources. Depending on how the hosts are configured, the migration process might also generate significant storage I/O.
The reason why these two points are important is because overly aggressive VM load balancing can be counterproductive. Imagine for a moment that a VM suddenly consumes more resources due to a demand spike. If the load balancer decides to move that VM, then the load balancer will be consuming additional resources on a host server that's already under an increased resource demand.
Some load balancers are designed to redistribute workloads on a scheduled basis, rather than in direct response to a demand spike. If the schedule is too aggressive, then the load-balancing process might not have time to complete before the next load-balancing operation begins.
Will you be using a dedicated load balancer?
Yet another issue that should be considered is whether it's better to use a hardware or software load balancer. At one time, hardware load balancers were the obvious choice, but today software load balancing works just as well.
If you're thinking about using a hardware load balancer, then there are two main things you should consider. The first is compatibility. Not every hypervisor works with every load balancer. Therefore, you will need to make sure your hypervisor vendor supports the load balancer you plan to use.
A second thing to consider is the load balancer's throughput. In the case of a hardware load balancer, the load balancer should provide enough ports and sufficient throughput to be able to efficiently handle your needs. If software load balancing is being used, then the server hardware will need to have sufficient resources available to handle the VM load-balancing requirements. Furthermore, those organizations opting to use software load balancing will have to consider the load balancer's OS or hypervisor dependencies and how the patch management process or future software upgrades might affect the load balancer.
Are there significant hypervisor-level limitations?
Some hypervisors have limitations that have a direct impact on the way VM load balancing must be implemented. For example, organizations that use Microsoft Hyper-V and System Center Virtual Machine Manager have the option of using Microsoft Network Load Balancing (NLB). However, NLB can't be used in service tiers where Linux VMs are running, nor can it be used on VM networks configured with network virtualization. In either situation, hardware load balancing must be used instead.
As you can see, there are a number of issues that must be considered prior to implementing VM load balancing. As you weigh these considerations, you should also think about the complexity that will be involved in implementing your chosen product. This is especially true of hardware load balancers, which might require special configuration providers or service templates.
Learn about AWS Elastic Load Balancing upgrades