In my post about session termination logic I mentioned both load balancing and session sharing. One reason that both these features came up in the same post is that they are closely related to each other. Together they determine which Terminal Server in the farm will host a new application instance. Yet their interaction is not always obvious or easy to understand. For that reason I’ll dedicate this post to analyzing how these features interact with each other.
Session Sharing Overview
Since I’ve already discussed load balancing in previous posts, I’ll begin by providing a short overview of session sharing. The concept of session sharing is very straightforward – say you already have an active session hosting one or more published applications. If you then launch another published application, session sharing enables that application to utilize the existing session instead of requiring the creation of a new one. The main advantage of session sharing, from the end-user’s perspective, is that the new application starts-up much more quickly because it avoids the extra overhead of creating and connecting to a new session. As a result, the start-up time will be measured in a few seconds instead of dozens. There are several additional advantages to session sharing:
Because session sharing has so many advantages, PowerTerm WebConnect prioritizes it above load balancing. What this means is that if a user already has an active session when launching a new published application, PowerTerm WebConnect will prefer reusing that session even when the server hosting it is not the least loaded server in the farm.
And yet, despite all these benefits, there are various situations where session sharing does not take place. Reasons for not sharing sessions include:
As you can see, whether sessions get shared or not is very much dependant on the configuration of the published applications and the farm. Because session sharing is so beneficial it’s well worth the effort to insure that the configuration promotes session sharing rather than prohibits it. For example, if the same users access a specific set of applications in tandem, making sure all these applications are installed on the same servers increases the likelihood of session sharing. Likewise, ensuring all the applications have the same resource requirements also improves the chances that sessions will be shared.
Session Sharing and Load Balancing
Not sharing a session because of server load is an example of where the interdependency between session sharing and load balancing comes into play. Since it is the load balancer that calculates server load, it has the information whether a particular server is overloaded. As a result, performing this type of exclusion requires interaction between these two functionalities. Another example of interaction between session sharing and load balancing is when the client has several active sessions to choose from. In such a scenario the session hosted by the least loaded server is the one that should be shared.
This way these two functionalities cooperate in PowerTerm WebConnect is very straightforward: when the user selects a published application to launch, the client enumerates all the active sessions. It then filters this list to include only sessions that match the application’s resource requirements. This list is then transmitted over to the load balancer. The load balancer also filters this list, removing sessions hosted by servers marked as being overloaded. If the resulting list is not empty then the session host by the least loaded server is selected and this selection is transmitted back to the client. If this list is empty, either because there were no appropriate sessions on the client to begin with or because all the sessions were filtered out, then standard load balancing takes place.
Can this interoperability be extended even further? Certainly. For example, a project we are working on involves the load balancer learning each user’s usage patterns. One benefits of this feature is that it can increase the probability of session sharing by preferring servers on which all the commonly used applications are installed.