In a recent post I wrote about this blog that “I strive to keep the content both technical and as accurate as I possibly can”. This post is a technical discussion of Application Load Balancing, and is intended to validate that statement.
Application Load Balancing is a special case of Load Balancing, which differentiates between the various published applications. Application Load Balancing primarily enables the administrator to specify distinct Terminal Server groups for different applications. In addition, some implementations allow the administrator to assign different load evaluators to different applications. The goal of these capabilities is twofold: to achieve optimal utilization of the server farm for the various published applications, and to provide the end-users with the best possible experience while using these applications.
The motivation for the ability to assign different load evaluators to different applications is that different applications utilize a different mix of system resources. For example, some applications are more memory intensive while others make more significant use of the CPU. Therefore, it appears to make sense to assign different load evaluators to such applications: a memory-biased evaluator for memory intensive applications and a CPU-biased evaluator for CPU intensive applications.
While this reasoning appears to make sense, we decided not to implement this functionality in PowerTerm WebConnect. There were several reasons for this decision:
To summarize, we drew the conclusion that this feature complicates the product, but doesn’t offer sufficient value. Indeed, it can easily cause more harm than good. Therefore we excluded it from PowerTerm WebConnect.
As I stated above, the defining aspect of Application Load Balancing is the ability to specify different groups of target Terminal Servers for various published applications. To understand the “raison d’etre” for this feature, you first need to differentiate between the two server farm configurations I refer to as symmetric and asymmetric. In symmetric farm configurations all the servers are essentially identical, at least as far as software. This means that they have the same applications installed, down to the exact version number, at the same locations and using the same setup. Ideally such servers should also be running the exact same version of Windows as well (tools such as RTO Discover are ideal for verifying that the servers are indeed identical). Symmetric farm configurations are much easier to administrate simply because you don’t have to contend with numerous unique server configurations.
In asymmetric server farms, various servers do have different software configurations. For example, a particular application might be installed on some servers yet not on others. Such configurations are more difficult to administrate yet are sometimes required due to:
My rule of thumb is: use symmetric configurations when you can, asymmetric configurations when you must.
If you must, indeed, use an asymmetric server farm configuration; then the ability to assigned distinct groups of servers to particular published applications is absolutely required. In other words, if your SBC solution does not provide Application Load Balancing then you cannot use asymmetric farm configurations at all. Since the new Windows Server 2008 Session Broker does not provide this feature it is limited to symmetric server farms (which makes since because Microsoft’s design goal for Windows Server 2008 Terminal Services is to support “low complexity scenarios”).
The PowerTerm WebConnect Load Balancer does provide this important functionality. Moreover, PowerTerm WebConnect lets you filter the server list so that only those servers on which the specific application is installed are displayed. Without this capability you might accidentally assign a published application to Terminal Servers on which it isn’t even installed.