WS2008: Session Broker Load Balancing

First published on TECHNET on Feb 25, 2008

Day Twenty-Five.  It's Monday morning - hopefully those of you returning from your weekends got some time to rest and relax.  Only two days to go until the launch of Windows Server 2008.  Today we're going to continue on from yesterday's post on Terminal Server Session Broker and look specifically at Session Broker Load Balancing.  So sit back, grab your coffee or tea (or if you're like me, your bottle of water) and let's begin ...

Windows Server 2008 Session Broker provides the same cross-server session reconnection capability as Windows Server 2003 Session Directory.  Windows Server 2008 Session Broker provides some additional features such as a load-balancing capability as well as the ability to gracefully "drain" servers prior to scheduled maintenance.  Windows Server 2008 Session Broker can be run with Session Broker Load Balancing disabled - which would then function in a similar mode to Windows Server 2003 Session Directory.

The Session Broker Load Balancing (SBLB) in Windows Server 2008 is managed based on the number of sessions.  However, SBLB does more than just count the user sessions.  It also has built-in black hole protection (logon throttling) and a max-session count.  SBLB has two ways to protect a server against the Black Hole effect.  The first is to artificially make the server load higher during a logon to prevent a Terminal Server from being inundated by new logins.  Once the logon process has finished, the server load returns to normal.  The Session Broker itself can guard against the Black Hole effect by limiting the outstanding connections to the same Terminal Server.  For example let us assume that the terminal servers are configured to host no more than ten concurrent user logons per server.  The max-session count means that ever server in the farm has determined a maximum amount of sessions that it can host.  This prevents a degraded user experience for the users already connected to a Terminal Server should other servers in the TS farm not be available.  Yes, there is a trade-off here.  By protecting the currently connected users' experience, other users may not be able to establish a Terminal Server session at all.  However, if the administrator knows his system(s) well, then this should not be a long-term issue.  The unavailability of servers in the farm should be a short-term phenomenon (hardware replacement, troubleshooting etc).  The max-session limit is something that needs to be manually configured - it is not automatically calculated by Terminal Server.  In fact, the max-session limit is disabled by default.  This setting is not configurable via the GUI - you will need to create and set the UserSessionLimit value in the registry to the maximum number of sessions you want to allow on the server.  This value would be set in the HKLM\System\CurrentControlsSet\Control\Terminal Server key.

OK, let's take a look at the Load Balancing aspect now.  SBLB is generally deployed using one of two technologies - TS Load Balancing, or Network Load Balancing (NLB).  In order to use the SBLB feature to load balance sessions, you must configure DNS entries - something that you do not have to do with NLB.  Within the TS Farm, the IP Address for each Terminal Server must be registered to a single DNS entry for the farm.  This creates the DNS Round Robin configuration.  All incoming TS clients will try to connect to the first IP address for the DNS entry.  If that fails, then the client tries the next address in the list and so on.  This provides a measure of fault tolerance in the event that a server is unavailable.  It is important to note that even though clients may connect to the first IP address initially, they are redirected to an appropriate server in the farm according to the load balancing configuration.  If a server in the farm is not available or is congested, the session redirects to a server that can accept the connection.  There are four basic steps that must be performed to configure a system for Load Balancing:

1. Install the TS Session Broker Role Service
2. Populate the Session Broker Computers Local Group
3. Join the Terminal Servers to the Session Broker and configure them to participate in the load balancing
4. Add the DNS entries for the Terminal Servers

Let's briefly talk about Network Load Balancing (NLB).  NLB is not aware of what application it is load balancing, whereas SBLB is an application level load balancing solution - it is smarter, but must be deployed with a network level load balancing solution to distribute the initial connections to the farm.The easiest network level solution to deploy is DNS Round Robin as shown above.  This solution complements SBLB well - however, DNS Round Robin does not provide any sort of detection mechanism for offline servers.  There can be a delay of 30 seconds if a server that is offline is picked from the DNS Round Robin list.  Using some sort of NLB provides better detection of offline servers.

To recap, there are some different deployment possibilities when dealing with Load Balancing:

• NLB Only: (this is the only out-of-box scenario for Windows Server 2003 TS machines).  This is harder to deploy, and has some scalability limits
• DNS Round Robin and SBLB: This requires Windows Server 2008 Terminal Services and Windows Server 2008 Session Broker.  This may be the easiest to deploy and provides decent load balancing, however there is no capability to detect offline servers for initial connectivity
• NLB and SBLB:  This requires Windows Server 2008 Terminal Services and Windows Server 2008 Session Broker.  Due to the existence of the NLB heartbeat, there is better detection of offline servers.
• Hardware Load Balancer in place of NLB in any of the above:  This would provide the best features for NLB scenarios, however a hardware load balancer may cost significantly more.

The last thing to briefly cover before wrapping up our two day overview of Session Broker is how to enable Session Broker Logging for troubleshooting.  To enable trace logging of Session Broker, you will need to add a TraceOutputMode DWORD value to the following registry key on the Session Broker server: HKLM\System\CurrentControlSet\Services\Tssdis\Parameters .  There are four different values that can be set to define the logging options:

• 0: No Output
• 1: Output to Debugger
• 2: Output to command window.  This option only applies when starting TSSDIS.EXE using the -debug switch for debugging
• 3: Output to log file.  When the value is set to 3, the Session Broker log file, tssdis.log is created

Entries related to the following Session Broker events are added to the log file:

• Service Start
• Service Stop
• Machine joins Session Broker
• Machine leaves Session Broker
• User logs in
• User disconnects
• User reconnects
• User logs out

Also, any errors that result in event log entries are included in the log file.  Unless there is a specific issue that you are troubleshooting, I highly recommend not configuring debug logging.  Once the troubleshooting is completed you should set the TraceOutputMode value to 0 and restart the service.

And with that, our penultimate post in the launch series comes to an end.  Tomorrow we'll wrap up our series of posts with an overview of Windows Server 2008 Terminal Services Gateway.  Until next time ...

- CC Hameed