Designing High Availability Solutions - Terminal Services for Windows Server 2003

This chapter describes the options you have, the steps you must take, and the money you must spend to ensure that your Terminal Servers are highly available for your end users.

This chapter describes the options you have, the steps you must take, and the money you must spend to ensure that your Terminal Servers are highly available for your end users.

In most environments, the use of Terminal Services starts out small. A single server usually provides a few applications to a few users. Over time, those environments reach the point of users depending on the applications hosted on Terminal Server. Then it becomes necessary to administrators to think about building multiple servers and systems that can automatically carry users through a failure of one system.

By thinking about how Terminal Server and its supporting systems work and how your users will use them, you can create a strategy to guarantee that the system has the redundancy needed to absorb small "hiccups" and is properly backed up to survive major disasters.

The redundancy of many Terminal Services components is discussed throughout this book. This chapter pulls those components together creating a holistic strategy that you can apply to your entire Terminal Server environment.

Terminal Server Availability in Today's World

In environments where availability is of utmost importance, administrators usually implement clustering technologies. Clustering technologies are usually applied to database, email, or web servers. If a server fails, another "node" is able to pick up where the first left off, and in many cases users are completely unaware that a failure occurred.

Unfortunately, seamless clustering failover technology is not available with Terminal Server, and is unlikely to be for some time. In fact, no Terminal Server-based technology can do this—not Microsoft, not Citrix, and not Linux. Now, before you slam this book down and tell everyone that this technology is completely bunk, think about what this means.

If a user is using a remote application on a Terminal Server and that server fails, the user's application will not magically appear on another Terminal Server right where she left off. That would require mirrored disks, shared memory stacks, dynamic program executables, and all sorts of other tools that haven't been invented yet.

What is possible with today's technology is load-balanced redundant environments. You can build your Terminal Server environment so that if a server fails (obviously ending the sessions of any users connected to it), the user can immediately reconnect to a new server and launch her application again. (This is much better than in traditional environments where applications run on users' desktops.)

It is also possible to configure redundant hardware on your servers and manage them in a way to minimize the chance that they'll go down.

Microsoft Terminal Server "Clustering"

Now that we just made such a big deal about how you can't create "real" clustering with Terminal Servers, we should point out that Microsoft has started using the terms "load-balancing" and "clustering" interchangeably when discussing multi-server Terminal Server environments. This duplicity tends to cause confusion, so keep in mind that for the next few years, when you hear the word "cluster" in the context of Terminal Services, it really means "a load-balanced group of Terminal Servers." It has nothing to do with Windows 2003's Cluster Service.


Start the conversation

Send me notifications when other members comment.

Please create a username to comment.