Title Page Previous Next Contents | Scaling the environment

Scaling the environment


What happens next, based on my personal experience deploying TS all over the world is simple: users realize they can access pretty much any application using the TS thing, no matter where they are, and still with almost ‘Office like’ performance. So they start asking for more applications and more users start using the solution. Your one server TS solution must grow. So how do we do this?
Assuming all your applications coexist peacefully on the same TS all you need is to have more TSs exactly like your first one. Just get new servers and install them following the same steps you did for your first server. Of course this will work well if you have a two or three server TS environment; if you are dealing with ten, twenty or more servers your best alternative is to use an automated deployment tool like Altiris or visionapp (some tools are available at no cost when you purchase certain server brands and models – i.e. HP Blades). Regardless of the size of your environment, make sure you have up-to-date documentation of everything you do!
In case your applications conflict for some reason and cannot be installed on the same TS, you will need to have separate server groups, often called ‘silos’, each group with a different set of application.

Regardless of having a single or multiple silos, as you can see, it is just a matter of having multiple servers, all configured exactly like the other ones within the same silo. This leads us to the next topic. If you have multiple servers, how do you point your users to the servers? What if one server is not available? That is our next topic.

Load Balancing

With multiple servers available to your users, how do they know which server they should connect to? Ideally you want to make this process as transparent as possible to them. Something along the lines of “just connect to ts.ourcompany.com, no matter if you are here in the office or at home”. For this to work you must implement something we call ‘Load Balancing’.

‘Load Balancing’ is the process used to spread the ‘load’ (your users’ connections) on your ‘resource pool’ (the TSs). There are several ways to do this and we will not be covering them here in detail for one simple reason: I wrote a two part article for MSTerminalServices.org called ‘Load Balancing Terminal Services: all you wanted to know but were afraid to ask”; all you need to know is there, explained and with all the PROs and CONs for each alternative. Here you have the links:

http://www.msterminalservices.org/articles/Load-Balancing-Terminal-Services-Part1.html
http://www.msterminalservices.org/articles/Load-Balancing-Terminal-Services-Part2.html

But as I do like my readers let’s take a quick look at what you should look for when trying to find a solution to load balance your TSs and the problems you may experience.

First of all, when users try to connect to your TSs, the best option would be to have some intelligent mechanism that would determine the best TS available at the moment based on how busy all your TSs are. This mechanism would also determine if a TS is actually responding. This is what we call a ‘Resource Based Load Balancing’ and we can easily see the benefits associated with it: users always get the best performing TS (as they are never directed to a TS that is at 100% CPU for example) and if a TS is not available, they do not even know it. So keep this term in mind when looking for a load balancing solution: ‘Resource Based’.

The second thing you must address was taken care of at the beginning of this guide. When users logon to a TS to run their applications, certain settings may be initialized and saved for that particular user (i.e. his Microsoft Outlook mailbox settings and preferences) on the TS he is connected to. But when the user logs off and connects back later, he may now be on a different TS (assuming you have a load balanced environment). In this case you want his/her settings to ‘follow’ him/her; regardless of the TS he/she is connected to. This is done by using roaming profiles that we set at the beginning. So now you understand why roaming profiles (or a profile solution that ‘follows’ the user) is required!

The final issue you must be aware is called ‘reconnection’. Let’s say a user is connected to a TS when all of a sudden his/her connection drops (i.e. his ISP was down for a couple minutes). When he tries to reconnect, he expects to be reconnected back to his existing session that was running on that particular TS and not to get a new session running on a less busy TS. So your load balancing mechanism must be intelligent enough to know at any time where each user has his session so it can reconnect them in case the connection drops.

I must emphasize that each environment is different meaning that needs and requirements are different as well. For some the old Microsoft Network Load Balancing will suffice, even though it is not resource based and does not know how to reconnect users; for others resource based load balancing and reconnection capabilities are mandatory requirements. Determine what your needs are, read the articles I mentioned and then find the best solution.

As of today, one of the most impressive and well-proven load balancing solutions out there is 2X LoadBalancer. It is not only resource based, but it also knows how to deal with reconnections, in case a user session gets dropped. This level of functionality is usually found on hardware load balancers or other software solutions costing thousands and thousands of dollars more. With many customers running the 2X LoadBalancer worldwide, it is the most reliable and accessible solution you will find.

Scalability

By scalability I mean how to determine the number of users a server can handle so in case you are adding more users to your TSs, you know before hand how many TSs you may need to add.

There are several ways to determine this. Some will be cheap (meaning free) while others may cost something (usually meaning extremely expensive). Again, it is all about what you need and how much you are willing to spend.
The cheapest way is to use our old and well known Performance Monitor (perfmon), installed out-of-the-box with any Windows Server out there. By simply monitoring a server (and collecting all this data for further analysis) you will be able to determine at which user load performance may become unacceptable (yes, I know this is very subjective – some users, no matter what you give to them, will always say everything is slow). For example, if you determine this number to be 70 users, plan your environment to have a maximum of 80% of this user number per server (in this example, 56 users) so in case one server goes down for some reason (maintenance, network issue, etc) there is still room on the remaining servers to handle the extra load required for the users that were using the server that is not available anymore.

In case you prefer to simulate this load on your TSs to determine the ideal number of users per box, you can use tools like ‘AutoIT’ (freeware) or fancier ones (i.e. LoadRunner, Citratest VU, EdgeSight for Load Testing, etc).

Bandwidth Considerations

I know I mentioned before the most asked question on the Internet related to Terminal Services is printing.Right after printing, the second one on the list is about bandwidth. Everyone wants to know how much bandwidth will be needed if they have an X amount of users connected to a TS.

Honestly, there is no way to give you an answer for this question. It all depends on the applications your users will be using, if they print like crazy, if they will be listening to internet radio through your TSs and so on!

Although I cannot give you a number, I can tell you how to find out the number you are looking for and also give you some ideas on what can be done to improve the overall perceived performance your users will have when using your TSs.
The first step is to determine how much bandwidth a typical user will need. To do that you can use the same Performance Monitor mentioned above or some sniffer (a tool that will capture all packets going through a network port and/or device) like Wireshark (free!) while a typical user uses a separate TS for a day. This will show you the total bandwidth for the time he was connected and its highs and lows.

To preserve the experience your users need when on the TS you should consider a couple things: RDP, as any other protocol, needs bandwidth and the less bandwidth you have, the slower things will move. Therefore, if you want to guarantee a certain performance level for your users, you must have a way to guarantee that RDP bandwidth will never go lower than a certain threshold. This number could be the average bandwidth needed by a typical user that you determined using perfmon or a sniffer as mentioned above. To achieve this you will need network devices that can control how much bandwidth a protocol may use. With such devices you can for example set the maximum amount web browsing will use (HTTP/HTTPS) so it does not affect how much bandwidth RDP has available. These devices can also guarantee a minimum number for each protocol (and a maximum). If your TSs are sharing the same network link with your mail servers, internet browsing, etc, it is clear to see why this becomes important!

I am not saying that you will necessarily need to have traffic prioritization and/or bandwidth controls in place.

Check your connections and how they are being used (wireshark for example can show you the total amount of data used per protocol) before you blame Terminal Services.