Terminal Server Session Directory
| Windows Server 2003 provides enhancements to terminal services to scale it for the enterprise. A new feature available in Enterprise Server and Datacenter Server is called Terminal Server Session Directory, and it provides the capabilities to use network load balancing or other third-party load balancing services. This enables the creation of terminal server clusters, or farms . The network load balancing service provides a virtual network interface card (NIC) that is shared among up to 32 cluster members . This provides TCP/IP load balancing across all machines in the cluster. When a request comes in to the virtual NIC (the cluster NIC), it is directed to any of the servers in the cluster (presumably the least busy).
The Problem with Clustering Terminal ServersThe problem with load balancing terminal servers is how to handle disconnected sessions. If a user drops a terminal server connection (either voluntarily or involuntarily) without logging off, the session remains active on the terminal server as a disconnected session. The disconnected session is still active, and any applications continue to run. When the user attempts to connect to the terminal server again, she is reconnected to her disconnected session. It essentially is as if the user simply walked away from the console for a while and came back. She is still logged on, and any applications she was running are still running. This is particularly useful for kicking off long-running applications or reports . The user logs on, kicks it off, and then comes back a couple hours later to obtain the results. In a load-balanced cluster, if a user disconnects from one terminal server, that session is still active on the server. When she attempts to reconnect to the cluster, her request is load-balanced among all available servers again. Thus there is no guarantee that she will be routed back to the server with her disconnected session. Depending on the number of servers in the cluster, the probability could be as low as 1 in 32. The net result is that she would connect to a different server, establish a new session, log on to the new server, and get a fresh console as if she were logging on for the first time. This can be disconcerting for the user, especially if she had been running an application in the previously disconnected session. Not only would it probably cause her to panic, but she might take action (such as rerunning the application or report) that could interfere with what's going on in the other session (remember it is still running). At the very least, it wastes resources because now two sessions are runningone on the original server and one on the new server. If the user disconnects and then reconnects, she could start a session on another cluster member, and another, and so on. The Terminal Servers Session Directory is designed to prevent this problem. The SolutionTerminal Server Session Directory is simply a database that resides on a server. It could be any server, not necessarily a member of the cluster. In fact, it is recommended that the session directory be located on a highly available server outside the load-balanced cluster, so all members of the cluster can easily access it. The Session Directory server does not need to be a Windows Server 2003 Enterprise or Datacenter Editionit can be a Standard server, although the cluster members (terminal servers) that will be querying the Session Directory database do need to be Enterprise or Datacenter servers. Figure 11.7 shows a typical terminal server cluster configuration with multiple clusters accessing a single Session Directory server. The Session Directory server itself could be a Microsoft Cluster Server (MSCS) cluster, in which case you would need Enterprise Edition or Datacenter Edition. Figure 11.7. The Terminal Server Session Directory architecture. The database on the Session Directory server maintains a list of disconnected user sessions and the terminal servers to which they are connected. When a client attempts to connect to a terminal server that is a member of a load-balanced Session Directory-enabled cluster, the Terminal Services Connection Manager queries the Session Directory the cluster is configured to use to determine whether any disconnected sessions exist for the user. If so, it routes the logon to the terminal server with the disconnected session and updates the Session Directory database; if not, the logon request is load balanced as usual. Installing the Session Directory server itself is fairly straightforward. Simply start the Session Directory service on the Windows Server 2003 that you want to maintain the database. You should also set the service startup to automatic (the default is disabled), so it will restart whenever the computer is rebooted. When the Session Directory service starts, it looks for a local group called Session Directory Computers. If the group doesn't exist, it creates it. This group is used to grant access to the session directory, so you should add the computer accounts of all the terminal servers that will use this computer for their session directory to the Session Directory Computers group . The terminal servers themselves also need to be configured to use Session Directory to tell them to use the Session Directory and provide cluster naming information. The terminal servers are configured to use Session Directory by any of the management methods mentioned earlier in this chapter (group policy, WMI [either script or WMIC command line], or the Terminal Services Configuration console). As shown previously, configuration with group policy provides more centralized control and is the recommended method. Several settings must be configured; in group policy, they are found by selecting Computer Configuration Settings, Windows Components, Terminal Services, Session Directory . They are as follows :
Terminal Server IP Address RedirectionThe purpose of Terminal Server IP Address Redirection needs further explanation. When a client attempts to connect to a terminal server cluster, the normal process is as follows:
Note that throughout this process, the client was logging on directly to the terminal server in question ( TS1 or TS3 ). The load balancing was simply providing the IP address with which he should connect. In certain load-balance solutions or scenarios, the client might not be able to directly connect to the terminal server IP address. In this case, the client must connect to the terminal servers using the virtual NIC of the cluster. The way this is accomplished is through the use of tokens: When the terminal server queries the Session Directory and a disconnected session exists, that information is passed to the client via a token . The client then presents the token to the virtual NIC of the cluster and gets routed to the appropriate server (through the virtual NIC). To use this method, the terminal servers and the load-balancing technology need to support the passing of tokens (Windows Server 2003 and the Remote Desktop for Connection client, of course, do), and you need to disable the Terminal Server IP Address Redirection setting. Terminal Server Session Directory makes operating terminal servers in a clustered configuration more viable . This improvement, combined with the capability to centralize administration with group policy and the enhancements to the underlying communications protocol (RDP), make the new terminal services in Windows Server 2003 more attractive for enterprise deployments. These are just some of the many improvements in Windows Server 2003 for scaling Windows for larger organizations. As you'll see in the next chapter, Microsoft has further enhanced its clustering offerings. Figure 11.8. An example of Terminal Server IP address redirection.  |
EAN: 2147483647
Pages: 136