Share And Share Alike - Session Sharing For Published Applications
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:
- Increased server capacity – sessions consume a certain amount of resources independently of the applications they hosts. Enabling multiple applications to share the same session reduces that total number of sessions required. This frees up more resources for the applications themselves, and enables each server to support more application instances.
- Improved server performance – creating a new session is a resource intensive operation that can significantly impact the server’s performance. Session sharing reduces the number of session creation operations thus improving overall server performance and responsiveness.
- Greater responsiveness – a Terminal Server is limited in the number of sessions it can create within a given period of time (even with Windows Server 2008 new parallel session creation feature),. Session sharing enables a server to launch more published applications within a given duration.
- Fewer profile problems – a single user with multiple sessions can be a recipe for profile problems. This is because each session reads and writes the same profile while ignoring the others. While there are means to mitigate this problem, it is preferable that each user will only have a single session at any given time.
- Extended application interoperability – applications can interact with each other to a greater extent and more efficiently when they are hosted by the same session.
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:
- Incompatible resource requirements – if the published application requires resources that the existing session is not able to provide then it cannot be hosted by it. For example, if the application requires access to local drives but the session has local drive access disabled then the application cannot share that session.
- The application is not installed on the server hosting the session – in some farm configuration not every application is installed on every server.
- Not the same user – in some (rare), situations different credentials are used when launching various applications. Two published application can share the same session only if they are accessed using the exact same credentials.
- Published desktops – session sharing is only applicable to published applications, not published desktops.
- Server overload – if the server hosting the existing session is already overloaded then launching yet another application on it is a bad idea. In such an event, a new session will be created for the application on a different, less loaded server.
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.