Load Balancing 101
Interestingly there has been a rash of postingsabout Load Balancing in SBC environments, possibly resulting from Microsoft’s announcement about the new Session Broker – with session-based load balancing capabilities – and it’s subsequent release as part of Windows Server 2008 (Longhorn), Beta 3. With all this information coming our way I thought it would be worthwhile to discuss Load Balancing in general, and how it applies specifically to SBC. This is because Load Balancing is one of those subjects that seems to be very straightforward, yet turns out to contain many subtle complexities.
Wikipedia defines Load Balancing as “a technique (usually performed by load balancers), to spread work between many computers, processes, hard disks or other resources in order to get optimal resource utilization and decrease computing time.” In the context of SBC “work” generally (though not necessarily), translates to user sessions, which are spread among multiple Terminal Servers. We can immediately spot the inherent problem with Load Balancing in this short definition: what does “optimal resource utilization” mean, and how to determine which type of load distribution best realizes it? Also, is decreasing computing time meaningful in the context of SBC, and if not what should be used instead?
Another important purpose of Load Balancing, certainly for SBC, which is not addressed by this definition is insuring the ability of users to connect (establish sessions), as long as there are relevant servers available in the cluster/farm with a sufficient number of free resources. For example, if there were just one server with sufficient free resources to host a new session in the entire farm/cluster, a new user would be directed to that server and no other. The flip side of this requirement is that users will not be directed to servers lacking a sufficient amount of free resources to host them. This is in order to avoid overloading and potentially crashing those servers. The problem here is that there is no easy or foolproof method to determine how many resources a session will require throughout its lifetime, and thus whether or not a server has sufficient available resources to support it.
Most Load Balancers calculate load value for all the servers, and direct new sessions to the least loaded servers – the ones with the lowest load value. Usually this load value is derived from an average of various performance counters over a period of time. Since, as I mentioned above, it is not clear what constitutes an optimal distribution, it is also unclear which performance counters to use in any given scenario. Vendors often respond to this dilemma by enabling their software to access multiple performance counters, and providing the system’s administrator with the option to select which counters to use. I think this approach is just “passing the buck”. Most administrators are ill-equipped to figure out which combination of counters to use, and cannot readily measure the effects of various configuration changes on the performance of their system. As a result, administrators either retain the default settings or select options based on uncorroborated, preconceived notions. In any event, they do not change these settings as the cluster grows and mutates.
Fortunately in most cases what is required is not an optimal configuration but simply a configuration that works and provides acceptable performance. Often it is more cost effective to add additional servers to the cluster than to try to achieve optimal load distribution (whatever that means),. Still the difference between reasonable and unreasonable load distribution might be the difference between a system that provides a positive ROI and one that doesn’t. Moreover improperly designed or configured load balancing solutions can cause significant damage. In upcoming posts I will elaborate on various aspects of load balancing and how they are implemented in our product – PowerTerm WebConnect.