阿尔萨斯

浏览: 4168994 次

最近访客更多访客>>

snower_tt

iams13

u012363178

wangyy

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

2014-10 ( 581)
2014-09 ( 572)
2014-08 ( 545)
更多存档...

会话目录及使用终端服务器的负载平衡

Session Directory Overview

In a load balanced environment terminal servers are grouped into farms, with each farm being represented to client machines as a single, computer name with one IP address. The device performing the load balancing redirects connections to each machine in the farm according to it's load balancing algorithm.

Note Terminal servers are required to be running Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, to participate in a Session Directory-enabled farm.

The Session Directory Database

The session directory is a database that can reside on a server that is separate from the terminal servers in the farm, although it is possible to have it on a member of the farm. The session directory database maintains a list of the user names associated with the session IDs connected to the servers in a load balanced Terminal Server farm.

Connecting to a Terminal Server Farm

When a user authenticates with a terminal server in the farm, the session directory is queried with the user name. If a session with the same user name exists on one of the farmed terminal servers, the session directory will redirect the client towards that terminal server. This allows a user to disconnect a session with applications running, whether intentionally or due to a network failure, then reconnect at a later time to the same session, with the same applications running. While this is a simple matter when the user connects to a single terminal server, scale out implementations, such as server farms, require the session directory to prevent the user from being connected to a different server in the farm and starting a new session.

Load Balanced Configurations

This section provides a basic overview of a terminal server farm, illustrates the most common load balanced configuration, and discusses how to enable remote desktop connections and install a terminal server.

Terminal Server Farm

Keep in mind that when implementing Terminal Services in a load balanced environment, all terminal servers in the farm must be running Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, to participate in a session directory-enabled farm.Because a farm is viewed by users as a single machine, all servers in a farm should be as identically provisioned and configured as possible. Additionally, configuring network storage for user data will prevent the orphaning or duplication of data across farmed servers.

The Most Common Configuration

The most common load balanced configuration is for network traffic to be split between two network adapters—one used for terminal services, and the other for access to other network resources and infrastructure, as shown in Figure 1 below.

Figure 1. Common load balanced configuration

For more information on load balancing, refer to your load balancing vendor information. Microsoft Network Load Balancing information can be found in the Windows Server 2003 Help and Support topics under Availability and Scalability. See Windows Clustering—Network Load Balancing Clusters. For additional information on clustering, visit Technical Overview for Windows Server 2003 Clustering Services.

Enabling Remote Desktop Connections

To make certain that servers are properly configured for a load balanced terminal server farm, an administrator should first enable terminal services (it is turned off by default during installation). This may be done using one of the following methods:

· Windows Management Instrumentation (WMI) script.

· WMIC command-line tool—TSToggle.

· Group Policy.

· System applet found in the Control Panel.

Windows Management Instrumentation (WMI) script can be used to enable terminal services. Use the method AllowTSConnections (in the Win32_TerminalServiceSetting class), which can be set to true or false. Below is a sample script. Note that this is named .txt, whereas a an actual script must be named .vbs.

It is also possible to use WMIC to execute WMI script one line at a time. For example:

wmic /node:"SERVERNAME" /user:DOMAIN/USERNAME path Win32_TerminalServiceSetting where servername="SERVERNAME" call setallowtsconnections 1

The WMIC command-line tool TSToggle is a simpler way to enable terminal services quickly by using the following script:

From cmd.exe:

Wmic /NODE:”SERVERNAME” /USER:”Domain/User” RDToggle where ServerName=”SERVERNAME” CALL SetAllowTSConnections 1

From WMIC:

/NODE:”SERVERNAME” /USER:”Domain/User” RDToggle where ServerName=”SERVERNAME” CALL SetAllowTSConnections 1

The Group Policy to turn on Terminal Services is “Allow Terminal Services Connections,” and is located in the Computer Configuration/Administrative Templates/Windows Components/Terminal Services folder.

Note It is strongly recommended that all farmed terminal servers be placed in an organizational unit (OU), with Group Policies applied to the OU.

To find the System applet in the Control Panel:

1. Right-click My Computer and select Properties.

2. On the System Properties page select the Remote tab and check Allow users to connect remotely to your computer box, as shown in Figure 2 below.

Figure 2. Enabling Remote Desktop

Installing the Operating System with Terminal Services Enabled

The TerminalServer switch in the unattend.txt file may be set to perform an unattended operating system installation with Terminal Services enabled:

TerminalServer

Value: On | Off

Default: Off

Specifies whether or not Terminal Server (Terminal Services for multiple users) is installed on the computer. If TerminalServer = On, Setup installs Terminal Server and configures the computer to run in multi-user mode. If TerminalServer = Off, Setup does not install Terminal Server. The value of this entry does not affect the ability to establish a remote connection to the computer using Terminal Services Remote Desktop.

In the Windows Server 2003 family, Terminal Server is applicable to Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; the 64-bit version of Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; and the 64-bit version of Windows Server 2003, Datacenter Edition.

To specify important security settings for a server with Terminal Server enabled, include the [TerminalServices] section and appropriate PermissionsSetting entry.

To specify the type of licensing you are using for Terminal Server, use the LicensingMode entry in the [TerminalServices] section.

Installing Terminal Server

Terminal Server is a Windows Component in the Add or Remove Programs applet, which is found in the Control Panel. Installing this component will ensure that your server is set up to handle multiple session requests from users.

Note This should be done before any applications are installed, because making this change will alter how installations are performed. Remember that terminal servers are required to be running Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, to participate in a Session Directory-enabled farm.

Session Directory

This section discusses the following: how to install and configure Session Directory server and client server configurations, Session Directory architecture, revectoring clients, and formatting routing tokens.

Installation and Configuration

When planning your Session Directory environment, it is vital to ensure that all terminal servers that will be included in the Session Directory are running at least Windows Server 2003, Enterprise Edition—Datacenter Edition can also be used.

Windows Server 2003, Standard Edition may be used to run the Session Directory service; however, only terminal servers that run Windows Server 2003, Enterprise Edition, or Datacenter Edition, may connect to and use the Session Directory service.

Session Directory Components

There are two Session Directory components to consider when installing and configuring Session Directory:

· Session Directory server

· Client servers

The Session Directory server is the server that is running the Session Directory service. It is not required to be a Terminal Server, or even to have Remote Desktop enabled.

The client servers are the Terminal Servers which will request data from the Session Directory server. Client servers need to be configured to point towards the Session Directory server for Session Directory requests. Architecturally, one Session Directory server may service multiple load balanced farms, although this may cause confusion if the administrator configures all farms to have the same logical cluster name value. (See the Client Server Configuration section below for more information regarding cluster name value).

The Session Directory is very simple to configure. Choose any Windows Server 2003-based computer to host the Session Directory, and start the Terminal Services Session Directory service. The Windows Server 2003-based computer may be within the terminal server network load balanced farm, but this is not necessary. The Session Directory service is installed by default on all editions of the Windows Server 2003 family.

While performance is dependant on the number of client servers, the Session Directory service generally has fairly small CPU, memory and hard drive requirements. A lower-end server (for example, a departmental print server) may be used to host the Session Directory service if the client server load is relatively light.

To start the Session Directory Service

Find the Session Directory Service in the Services section of the Computer Management tool, and open the Property page. To make certain that the service starts whenever the server starts up, it is recommended that this service be configured to start automatically, as shown in Figure 3 below.

Figure 3. Starting the Terminal Services Session Directory Service

Once the Terminal Services Session Directory service is started on a server, both the Session Directory server hosting the Session Directory service and each client server node in the load balanced cluster must be configured. The Session Directory server must be configured to accept connections from authorized computers, and each load balanced cluster node must be configured to use the Session Directory Service on the Session Directory server.

Host server configuration must be done using the Computer Management Microsoft Management Console (MMC) snap-in, while client server configuration may be done by using Group Policy, or the Terminal Services Configuration tool.

Session Directory Server Configuration

To configure the Session Directory server:

1. Turn on the Terminal Services Session Directory service.

This service is off by default, and set to Disabled. Starting this service and setting it to Automatic will ensure that the service starts when the Session Directory server is turned on.

2.When the Session Directory service is started, it will look for a local computer group named, “Session Directory Computers”—if this group does not exist, it will be created. It is possible to create this group prior to starting the Session Directory service.

Note If the Session Directory Service is started on a domain controller this group will be a domain local group and available on all domain controllers, therefore running the Session Directory Service on a domain controller is not recommended.

The Session Directory service will not accept any connections from servers that do not have their domain computer account included in this local group. By default, when the Session Directory Service creates the “Session Directory Computers” group, it is empty—therefore no computers will have access to the Session Directory unless they are explicitly granted access.

3.To grant access to the Session Directory Service, add the computer accounts of each client server node in the load balanced cluster to the group.

4. Adding computer accounts to a local group may be done by selecting the Object Types button shown in Figure 4 below.

Figure 4. Selecting users, computers, or groups

5.In the Object Types dialogue box the Computers object must be checked, as shown in Figure 5 below.

Figure 5. Selecting the Computers object

Client-Server Configuration

Client-server configuration can be done using the Terminal Services Configuration Tool, or with the Group Policy Editor.

Using the Terminal Services Configuration Tool

1.For each server in a load balanced cluster, open the Terminal Services Configuration tool (tscc.msc) and in the left pane click Server Settings..

2.In the right hand pane, from Session Directory, open Properties.

3.On Properties, check Join Session Directory. Add the cluster domain name to the “Cluster name” field, and the Session Directory server name or IP address to the “Session Directory server name” field.

Note that the “Cluster name” must be uniform across the cluster, although this name is arbitrary, and does not need to be related to individual server names or the organizational unit name. Because the Session Directory service may assist multiple Terminal Server farms, the cluster name is used to determine which Terminal Servers are in a single farm. This allows the Session Directory the ability to redirect the same user to different servers when that user connects to different server farms. To reduce confusion specify the name that clients will use to connect to the terminal server farm.

IP Address Redirection

The “IP address redirection (uncheck for routing token redirection)” check box should only be unchecked if:

1.Your load balancing solution does not allow direct connectivity from the client computer to the Terminal Server, (for example, your load balancer is also a router)

2.Your load balancing solution supports the use of Session Directory routing tokens.

Some third party load balancing solutions act as a router as well as a load balancer. When this is the case, the client computer cannot communicate with the Terminal Server directly. Normally, when redirection is performed, the Terminal Server gives the client an IP address to reconnect to. If the load balancing solution is also a router, the client will not be able to connect directly to the Terminal Server IP address.

Un-checking the IP address redirection box will change the way that the Session Directory performs redirection. Instead of sending the IP address of the server to the client, the terminal server will send a routing token with the server's IP address embedded in the token. When the client re-connects to the load balancer, the routing token will be presented to the load balancer. Some third party load balancers support the Session Directory redirection routing token, and will interpret it successfully, redirecting the client computer to the correct terminal server.

Note It’s recommended that you keep the default setting for this option (checked). See your load balancing solution documentation for further use of this setting

Determining the IP Address for Redirection

The “Network adapter and IP address Session Directory should redirect users to” setting determines which IP address the Session Directory will send to client computers for redirection. This setting is necessary because many servers have multiple network adapters and IP addresses—not all of which are visible to the client computer. Choose the network adapter and IP address that client computers should connect to from the drop down box.

Using Group Policy Editor

The most efficient way to manage the Session Directory configuration settings of multiple servers is to set Group Policies using the Group Policy Editor. Group Policies allow administrators to centrally configure Session Directory settings (and a great many other settings) on defined groups of machines. On an individual basis, it may be more efficient to use the Terminal Services Configuration Management tool (TSCC).

In environments where Active Directory® is not deployed (and hence no centralized Group Policy) these settings may still be managed via the Group Policy Editor, by running GPEdit.msc locally on each machine being managed.

Session Directory Group Policy Settings

The Session Directory Group Policy settings are located in Computer Configuration/Administrative Templates/Terminal Services/Session Directory. The settings at this location are: Join Session Directory, Session Directory Server, Session Directory Cluster Name, and Session Directory IP Address Redirection.

· Join Session Directory: Enables or disables participation of a machine in the Session Directory. When unconfigured or disabled, the Session Directory is not specified. When configured, the server(s) affected will also need to have the Session Directory Server name and the Session Directory Cluster Name specified.

· Session Directory Server identifies the computer on which the Session Directory service is running. All servers using the same Session Directory should point to the same server. When disabled or left unconfigured, the Session Directory server will not be specified. Enabling this setting requires that you enter the DNS name or IP address of the server, and that the Session Directory service is started on computer specified as the Session Directory server.

· Session Directory Cluster Name is the name of the cluster that load balances new incoming connection requests among Terminal Server machines in the site. Disabling or not configuring this setting will leave the cluster name unspecified to servers affected. Enabling this setting requires that you enter the DNS name of the cluster that servers affected will participate in. This also allows the Session Directory to distinguish between handling multiple load balanced clusters.

· IP Address Redirection (uncheck for routing token redirection) determines whether or not clients that connect to a load balanced terminal server farm are redirected to a server IP address, or use a routing token to mask the IP address of the destination server.

If the Session Directory is enabled, the Session Directory server field must have a computer name (or IP address) in order to close the dialog. If this field is not populated, or is populated with an invalid server name, the terminal server will generate an event log error stating that the location cannot be found. The possible event log errors relating to the Session Directory are:

· 1001 “The RPC call to join Session Directory to <sd server name> got Access Denied.”</sd>

· 1002 “Session Directory service on server <sd server name> is not available.”</sd>

· 1003 “Session Directory server name <sd server name> is invalid.”</sd>

Clustering the Session Directory Server

To provide high availability for the Terminal Services Session Directory Server on a server cluster, the following tasks need to be completed:

Note Information on creating a server cluster is available in the Help and <place w:st="on"><placename w:st="on">Support</placename><placetype w:st="on">Center</placetype></place>, under Availability and Scalability: Windows Clustering. See the Server Clusters topic.

1.On all Windows Server 2003, Enterprise Edition or Datacenter Edition systems that are nodes in the server cluster where you want to host the Terminal Services Session Directory server, these nodes must have the service set to automatic. This is done by going to Services.msc and changing the startup value from Disabled to Automatic.

Note If Step 1 is not done, when you attempt to bring the resource online on one of the server cluster nodes, you will receive the error 1069 in the event log from ClusSvc; and the following associated entry in the %windir%/cluster/cluster.log on that node: This is not replicated to all nodes “ERR Generic Service <generic service resouce name>svc: The service is DISABLED”</generic>

2. Review the Help and Support topics on Creating Server Cluster Resources, and specifically Generic Service Resources, which are available under the Availability and Scalability topic on the main Help and Support window when launched from the Start Menu.

3.Make sure you have the following resources available in the server cluster configuration, specifying to connect to the server cluster name created during the cluster configuration process; (as seen by running Cluster Administrator (Cluadmin.exe) while being logged on as a cluster administrator account remotely or locally):

· Physical Disk—This needs to be a resource that is not used to store the quorum information, and must be able to failover to all nodes in the cluster that you want to be able to host the Terminal Services Session Directory database. The physical disk must be configured in the cluster before being configured to provide failover of the Session Directory Service.

· IP Address—This needs to be a static IP address that is accessible from all the terminal servers that will be configured in the load balancing cluster so they can update the Session Directory database.

· Network Name—This needs to be a name that is accessible from all the terminal servers that will be configured in the load balancing cluster so they can update the Session Directory database. For security reasons, Kerberos is required for all communication between the terminal server and the Session Directory server, so “Enable Kerberos Authentication” and “DNS Registrations Must Succeed” need to be selected, as shown in Figure 6 below, before bringing the network name resource online.

Figure 6. Selecting Group Name Properties

Note The IP address and network name will be what the terminal servers will specify for the Session Directory server to ensure consistent network connectivity no matter what server cluster node is hosting the Session Directory database. Also, the Cluster Administrator has a wizard, Configure Application from the File Menu, that will configure the IP address and network name, as well as the Generic Service resource, to manage the Terminal Services Session Directory Service.

4.If a cluster group already exits with the IP address, network name and disk resources to be used for the Terminal Services Session Directory server, you can create the Generic Service resource by going to the File menu, and selecting New and then Resource.

5.On the first page of the wizard, as shown in Figure 7 below, fill-in the data fields and then click Next.

· In the “Name” field, specify the name of the Resource—this will be what is displayed in the Cluster Administrator user interface and can be anything you like.

· “Description” is not a required field, but will also be displayed in the Cluster Administrator user interface.

· “Resource Type” should be set to Generic Service, and ‘Group” should be set to the cluster group that contains the resources mentioned in step 3 above.

Figure 7. Specifying properties for a new resource

6.After clicking the Next button, you come to the Possible Owners Page, as shown in Figure 8 below. This is where you specify which nodes of the cluster you want the Terminal Services Session Directory to be hosted on. In most cases, you would leave this page with default settings.

Figure 8. Possible Owners Page

7.After clicking Next again, the Dependencies page, as shown in Figure 9 below, comes up. This is where you specify which resources need to be online before bringing the Session Directory service resource online. Specify the “Physical Disk” and “Network Name” resources.

Note The IP address is already a dependency of the Network Name resource automatically, and since this property is transitive, there is no need to set a direct dependency on the IP address resource.

Figure 9. Selecting dependent resources

8.After clicking Next, the Generic Service Parameters page comes up. On this page, you will specify the service name, “TSSDIS” in the “Service name” box, and check the box next to “Use Network Name for computer name” as shown in Figure 10 below.

Figure 10. Selecting generic service parameters

9.After clicking Next, the Registry Replication page comes up, as shown in Figure 11 below. The Terminal Services Session Directory Service needs the System/CurrentControlSet/Services/Tssdis/Parameters key to be replicated between the cluster nodes to keep the service configuration consistent on failover. To set this, select the Add button and type in the Registry key path leaving off the HKEY_LOCAL_MACHINE portion and click OK. The path typed will show up in the box exactly as typed.

Figure 11. Replicating registry keys between cluster nodes

10.After clicking Finish, the dialog box shown in Figure 12 appears.

Figure 12. Cluster resource created successfully

11.After clicking OK, the Cluster Administrator interface will look like Figure 13 below:

Figure 13. Cluster Administrator interface after creating a cluster resource

Now you can bring the new Generic Service resource online, by right-clicking the resource and selecting the “Bring Online” option. If there are any problems with bringing it online, check the System event log and the cluster.log found on the node specified as owner in the %windir%/cluster directory.

Potential Errors—System Event Log

If the generic service resource is not dependent on a physical disk resource the following two errors will be reported in the system event log:

Event Type: Error

Event Source: TermServSessDir

Event Category: None

Event ID: 1011

Date: <date w:st="on" year="2002" day="6" month="8">8/6/2002</date>

Time: <time w:st="on" minute="45" hour="13">1:45:17 PM</time>

User: N/A

Computer: BTSDELLNODEB

Description:

The Session Directory failed to start because of a problem during database initialization. The error code was 0x0.

Event Type: Error

Event Source: ClusSvc

Event Category: Failover Mgr

Event ID: 1069

Date: <date w:st="on" year="2002" day="6" month="8">8/6/2002</date>

Time: <time w:st="on" minute="38" hour="13">1:38:38 PM</time>

User: N/A

Computer: BTSDELLNODEB

Description:

Cluster resource '<generic service resouce name>' in Resource Group 'TS Session Directory Group' failed.</generic>

Potential Errors—Cluster.log File

If the generic service resource is not dependent on a physical disk resource the following four entries will appear in the cluster.log file:

· 00000fc8.00000ee8::2002/08/06-20:45:17.969 ERR Generic Service <generic service resource name>: Service failed during initialization. Error: 1067.</generic>

· 00000fc8.00000e2c::2002/08/06-20:40:58.981 INFO Generic Service <generic service resource name>: Terminate request.</generic>

· 00000fc8.00000e2c::2002/08/06-20:40:58.981 INFO Generic Service <generic service resource name>: GenSvcTerminate : calling SCM (didStop=0)</generic>

· 00000fc8.00000e2c::2002/08/06-20:40:58.981 INFO Generic Service <generic service resource name>: Service died; status = 1062.</generic>

12.Confirm that the cluster group containing this new resource can be hosted on all nodes in the cluster by right-clicking the group name containing the new resource. Select the “Move Group” option and make sure the resource comes online successfully.

13.Now configure the terminal servers to point to the network name specified on the network name resource’s Properties page as the Session Directory server.

14.Follow the procedure in the “Session Directory Server Configuration” section above—starting with Step 2—on each of the server cluster nodes that will host the Session Directory.

Note You already have the service started at this point. It is recommended that you create a global group and add the terminal server computer accounts to that group. Then add this global group to the local group on each of the server cluster nodes to make it easier to keep the membership of the local groups consistent on all server cluster nodes.

15. Follow the procedure in the above section “Clustering the Session Directory Server,” and specify the “Name” on the Parameters tab for the Network Name resource that the Generic Service resource configured for the Terminal Server Session Directory service. See Figure 6 above.

Session Directory Architecture

The Terminal Server Session Directory provides functionality that allows a group of terminal servers to coordinate the re-connection of disconnected sessions. The Session Directory is a database of interactive user sessions that logically “connects” back-end servers (generally behind a load-balancing solution).

All sessions on servers in the cluster are stored as records in a central database. This database is updated and queried by the terminal servers whenever users log on, log off, or disconnect their session, while leaving their applications active.

Note A disconnect may be planned or unplanned. Therefore, users redirected to a random server behind the load balancer can be re-vectored to the server that already hosts their session.

One Session Directory can handle multiple terminal server clusters (this is one of the reasons for the cluster name setting). Simply specify the same Session Directory server for multiple clusters, and the Session Directory server will manage each cluster separately.

Session Directory Database

The Session Directory stores session state information, including a disconnected session descriptor. The fields in this database store are shown in the table below:

Session Directory Database Fields and Descriptions

Session Directory DB Field

Description

source-server-ID

Name of the server that the session resides on.

session-ID

The session ID—determined by the server that the session originated on.

username

Username logged into the session.

domain

Domain the username resides on.

TS-protocol

Protocol used to connect the session on the server (RDP, <place w:st="on"><city w:st="on">ICA</city></place>, and others)

session-creation-date-and-time

Time and date session was first created.

disconnection-date-and-time

Time and date session was disconnected.

application-type

A protocol-dependent identifier that differentiates between a desktop session or a single-app session.

resolution-width

Resolution width—This can be set at either the server or client level.

resolution-height

Resolution height—This can be set at either the server or client level.

color-depth

Color depth of session—This can be set at either the server or client level.

This set of session records forms a global Session Directory, which can be queried using the Terminal Services WMI provider. More information on this WMI provider may be found at: Http://www.microsoft.com/terminalservices/WMIOrSomething.htm

Most centralized logon scenarios have the requirement that the user have only one session at a time across all pool servers. This simplifies the problem of having to find all disconnected sessions in a server pool— there are either one or no servers in the resulting list of servers with disconnected sessions.

Future versions of the Session Directory may have tighter integration with Active Directory, however, the version covered in this white paper is not Active Directory-aware.

Once the destination server has been determined by querying the Session Directory, the user must be directed to the user session on that machine.

Revectoring Clients

Some load balancing configurations require that all traffic between the server and the client be routed through the load balancer. In this case, client computers may not connect directly to a server's IP address, as it is not visible to the client. Clients can be revectored using routing token redirection when terminal server IP addresses are not visible to clients.

When Terminal Server IP Address is Visible to the Client

In load balanced clusters where the terminal server IP address is visible to the client, the client data stream is redirected from a shared cluster IP address to a specific server within the cluster. The process flows as follows:

1.A client connects to a load balanced cluster IP/DNS name—CLUSTER01.

2.The load balancing solution redirects the client connection to a specific terminal server within the cluster—TSSERVER01.

3.The client receives the logon screen and the user enters a username and password.

4.The TSSERVER01 validates the username and password, then queries the Session Directory server—SDSERVER01—with the username.

5.SDSERVER01 identifies that the username is associated with a session on TSSERVER99, and passes this information to TSSERVER01.

6.TSSERVER01 passes the encrypted authentication information to the client. Because the “Client can see server IP” checkbox is selected, the load balance packet contains the IP address of TSSERVER99 that client will use to connect to TSSERVER99 directly.

7.TSSERVER99 performs a look-up on the username against the disconnected sessions running on the server. TSSERVER99 then reconnects the user to the disconnected session associated with the username.

When Terminal Server IP addresses Are Not Visible to Clients

When terminal server IP addresses are not visible to clients the following occurs:

· The Session Directory will pass to the client a routing token with logon information, and the correct server IP address embedded and encrypted.

· The client presents this routing token to the load balancer, which deciphers the token and sends the client to the correct terminal server with logon credentials.

Example: The user has an existing session on TSSERVER33.

1. When the client connects, the client is balanced to TSSERVER01 by the load balancer.

2. TSSERVER01 then queries the Session Directory, and receives information that the user has a session on TSSERVER33.

3.The server tells the client computer to reconnect to the same cluster IP address as it did initially, but it also tells the client to send a “routing token” at a certain offset in its first packet sent to the server. TSSERVER01 then drops the connection with the client.

4.The client connects to the same virtual IP, and this time it provides the routing token.

5.The load balancer looks at this routing token, which contains information on the IP address and port number to which to redirect the client (which are the correct IP and port number for TSSERVER33), sets up the proper internal mapping, and the user successfully logs on to his or her existing session on TSSERVER33.

Note Microsoft Network Load Balancing requires that Terminal Server IP addresses be visible to clients.

Routing Token Format

The dynamic routing token will go in the initial packet of the second (redirected) connection. It is possible there will be no routing token, in which case the load balancer should use its fallback algorithm for balancing load. This algorithm was designed in conjunction with load balancing manufacturers.

If present, the routing token will begin at TCP payload decimal byte offset 11 (0-based) of the first packet the client sends to the server. The format is ASCII text, as follows:

Routing token: msts=3640205228.15629.0000 + CR + LF

The numbers are the IP address and port number, in network byte order. For example, the numbers given above are for the IP of 172.31.249.216, port number 3389.

172 31 249 216

AC 1F F9 D8

Reverse to D8 F9 1F AC, and you get 3640205228. Similarly,

3389 = 0x0D3D

Reverse the bytes, 0x3D0D = 15629.

The final four zeros are optional and they are reserved. The final decimal point is required, as are the trailing carriage return and linefeed.

Port 3389 is the standard terminal server connection port, but do not assume this will be the destination port. It is configurable, and other protocols may use other ports. Obviously, you will have to provide configuration for the port on which the load balancer expects terminal server traffic.

Example: This is an example TCP payload for the initial packet after a redirect (with the address and port used above). In this case the TCP payload begins at offset 0x36 (decimal 54), and the routing token begins at offset 0x41 (65). The beginning of the packet is omitted for simplicity. The initial 11 bytes are Terminal Server RDP traffic and can be anything, so they are grayed out.

00000030 03 00 00 2F 2A E0 00 00 00 00 .../*.....

00000040 00 43 6F 6F 6B 69 65 3A 20 6D 73 74 73 3D 33 36 .Cookie:.msts=36

00000050 34 30 32 30 35 32 32 38 2E 31 35 36 32 39 2E 30 40205228.15629.0

00000060 30 30 30 0D 0A 000..

Terminal Server Load Metrics

Terminal servers provide a limited amount of load information via the Windows Management Instrumentation (WMI) provider. The total number of sessions and the number of disconnected sessions are available. See the sample script below for an example of how to query for this information.

Active sessions may be computed as being the number of total sessions minus the number of disconnected sessions.

Summary

Terminal Services is a technology that lets users run Windows-based applications on a remote Windows Server 2003–based computer. Session Directory is a load balancing feature that enables users to easily reconnect to a disconnected session on a server farm running Terminal Services. Session Directory keeps a list of sessions indexed by user name, and allows a user to re-connect to the terminal server where the user's disconnected session resides and resume that session. Session Directory is compatible with the Windows Server 2003 load balancing service and is supported by third-party external load balancer products.

This paper discusses how to plan and deploy a load balanced terminal server farm using Session Directory, and how the Session Directory operates in a load balanced environment.

Appendix: Third-Party Load Balancing Support

F5 Networks BIG-IP

The F5 Networks BIG-IP traffic management device includes support for load balancing Windows Terminal Server (WTS). Support for WTS Persistence is included in versions of BIG-IP starting with version 4.2. WTS Persistence provides an efficient way of load balancing traffic and maintaining persistent connections between Windows clients and servers that are running Microsoft's® Terminal Services service. If there is an existing session, the BIG-IP device directs the connection to the server with the existing session and, if there is no existing session, BIG-IP will direct the connection to the best server based on sophisticated load balancing algorithms. The recommended scenario for enabling the BIG-IP WTS persistence feature is to create a load balancing pool that consists of terminal servers running Windows Server 2003, Enterprise Edition, where all members belong to a Windows cluster and participate in a Windows session directory. These servers will be referred to simply as terminal servers for the remainder of this documentation.

Not only does the BIG-IP efficiently load balance and maintain persistent connections between Windows clients and servers, the BIG-IP also performs health monitoring for Windows servers that are running various services. For example, the BIG-IP health monitoring feature provides useful data on CPU, memory, and disk utilization of Windows Management Interface (WMI) servers, to ensure the most efficient load balancing of traffic to those servers.

Please note that the latest information on configuring BIG-IP to support Windows Terminal Server is available in the Configuring Windows Terminal Server Persistence chapter of the BIG-IP Solutions Guide for the most recent version of BIG-IP.

<personname w:st="on">Benefits</personname> of WTS persistence

Without WTS persistence, terminal servers, when participating in a session directory, map clients to their appropriate servers, using redirection when necessary. If a client connects to the wrong server in the cluster, the targeted server checks its client-server mapping and performs a redirection to the correct server. When BIG-IP WTS persistence is enabled, however, a terminal server participating in a session directory always redirects the connection to the same BIG-IP virtual server, instead of to another server directly. The BIG-IP then sends the connection to the correct terminal server. Also, when WTS persistence is enabled on a BIG-IP and the servers in the pool participate in a session directory, the BIG-IP load balances a Terminal Services connection according to the way that the user has configured the BIG-IP for load balancing. Thus, the use of Terminal Servers and Session Directory, combined with the BIG-IP WTS persistence feature, provides more sophisticated load balancing and more reliable reconnection when servers become disconnected.

Platform issues

By default, the BIG-IP with WTS persistence enabled load balances connections according to the way that the user has configured the BIG-IP for load balancing, as long as Session Directory is configured on each server in the pool. Because Session Directory is a new feature that is available on Windows Server 2003, Enterprise Edition (and higher) servers only, each server in the pool must therefore be a Windows Server 2003, Enterprise Edition server if you want to use WTS persistence in default mode. Also, each client system must be running the remote desktop client software that is included with any Windows Server 2003 or Windows XP system.

If, however, you want to enable WTS persistence but your server platforms are running older versions of Windows (on which Session Directory is not available), you can enable WTS persistence in non-default mode. This causes the BIG-IP to connect a client to the same Windows server by way of the user name that the client provides. You can enable WTS persistence in this way by setting a global variable on the BIG-IP, called msrdp no_session_dir, which disables Session Directory on any pool created with the msrdp attribute. Note that enabling WTS persistence in non-default mode (that is, with no Session Directory available on the servers) is less preferable than the default mode, because it provides limited load-balancing and redirection capabilities.

The following sections describe how to enable WTS persistence with and without Windows Session Directory.

Configuring WTS persistence with Session Directory

To enable WTS persistence in the default mode, you must configure Session Directory on each Terminal Server that is listed in your load balancing pool. In addition to configuring Session Directory, you must perform other Windows configuration tasks on those servers. However, before you configure your Terminal Servers, you must configure your BIG-IP system, by performing tasks such as creating a load-balancing pool and designating your Terminal Servers as members of that pool.

The following two sections describe the BIG-IP and Terminal Server configuration tasks that are required to enable WTS persistence in default mode for a Windows client-sever configuration running Windows Terminal Services.

Configuring WTS persistence on the BIG-IP

To configure WTS persistence on the BIG-IP, you must perform the following three tasks.

Enable TCP service 3389.

To enable TCP service 3389, use the following command:

b service 3389 tcp enable

Optionally, you can map the this port from 3389 to 443 in order to allow traffic to pass more easily through a firewall.

Create a pool of Terminal Servers, with the WTS persistence attribute (msrdp) enabled.

To create a pool that is configured for WTS persistence, use the bigpipe pool command, as in the following example. Remember that the pool members must already be members of a Windows cluster.

b pool my_cluster_pool { persist_mode msrdp member 11.12.1.101:3389 member 11.12.1.100:3389 }

Create a virtual server.

To create a virtual server that uses the pool my_cluster_pool, use the bigpipe virtual command, as in the following example:

b virtual 192.200.100.25:3389 use pool my_cluster_pool

To simplify routing requirements, it is also recommended that BIG-IP be configured so that the terminal servers are on the same IP network as the domain controller and other servers, such as the DNS server. This can be accomplished by following the instructions in the chapter titled “Installing a BIG-IP without Changing the IP Network”, which is located in the BIG-IP Solutions Guide.

Verifying prerequisite Windows configuration tasks

Before enabling BIG-IP WTS persistence, you must verify that the following conditions exist:

Each Terminal Server system is a member of the same domain. To add server members to a domain, configure the Windows Active Directory service.
Each Terminal Server system is a member of the same Windows cluster. To intially create a cluster, configure the Windows Server Cluster Node service. To add additional server members to a cluster, use the Windows administrative tool Cluster Administrator.
The Windows Terminal Services software is installed on each Terminal Server system. To install Terminal Services software, configure the Windows Terminal Service service.

To configure the above services, you must first log in to each terminal server as Administrator, which causes the Configure your server wizard to start automatically. From this wizard, you can select each of the three services listed above.

Configuring your Windows Server 2003 servers

To configure your Terminal Server servers, you must perform the following tasks: Verify that certain prerequisite services are running on your Terminal Server servers.

Configure the Terminal Services service.
Join the Terminal Server servers to Session Directory.
Create a Windows local group and add members to it.
Start the Session Directory service.

Step-by-step instructions are provided earlier in this document.

Configuring the Terminal Services service

The next step is to configure Windows Terminal Services for use with BIG-IP. This allows BIG-IP to maintain persistent connections by offloading the redirection function from the servers to the BIG-IP. When a client connection goes to the wrong server, proper configuration of the Terminal Services service ensures that the server always rewrites the connection to the BIG-IP, which then sends the connection to the correct server. Follow the instruction earlier in this document titled “Client-Server Configuration.” While the Session Directory screen is still displayed, locate the check box labeled IP Address Redirection, and verify that the check box is cleared. (If the check box is checked, clear the check box.) If you do not clear the check box, the servers will redirect connections directly to other servers in the cluster, rather than to the BIG-IP.

Configuring WTS persistence without Session Directory

When a server has no Session Directory, the server cannot share sessions with other servers, and therefore cannot perform any redirections when a connection to a server becomes disconnected. In lieu of session sharing, Windows clients provide data, in the form of a user name, to the BIG-IP to allow the BIG-IP to consistently connect that client to the same server. Enabling WTS persistence to behave in this way is the non-default mode.

To configure WTS persistence when the servers do not have Session Directory, you must first perform the BIG-IP configuration tasks that are described in the section Configuring WTS Persistence on the BIG-IP above.

Next, you must set a BIG-IP global variable, msrdp no_session_dir. Setting this global variable disables Session Directory on all pools on which the msrdp attribute is set. To set the msrdp no_session_dir global variable, use the following command-line syntax:

b global msrdp no_session_dir enable

Finally, you must verify that the Terminal Services service is running on each Windows server in your load-balancing pool.

Radware Web Server Director

WSD/WTS Quick Setup Guide

The following diagram depicts a sample implementation of a Web Server Director (WSD) configured to load balance a farm of Microsoft Windows Server 2003 WTS Servers. Please note that this implementation utilizes two physical ports on the WSD, and that the servers are deployed on a privately addressed network “behind” the WSD.

Sample WSD / WTS Implementation

For this solution, the default gateways of the servers will have to be configured as WSD interface 1 (192.168.1.1).

Step-by-Step Configuration

Connect to the WSD using a straight through serial cable and a terminal program (i.e. Hyper Terminal). The default connection settings are: 19200, 8, None, 1 and No Flow Control. Turn on WSD.

Upon first boot, you will be presented with a “Start-Up Configuration” menu. This menu allows you to specify an IP Address/Subnet Mask for a specific physical port of the device for management, as well as enable different management methods.

0. Exit

1. IP address

2. IP subnet mask

3. Port number

4. Default router IP address

5. RIP version

6. OSPF enable

7. OSPF area ID

8. NMS IP address

9. Community name

10. Configuration file name

11. Username

12. Password

13. Web access

14. Telnet access

15. SSH access

This example utilizes a basic network environment, and only requires a few options to be configured: (1) IP Address, (2) Subnet Mask, (3) Physical Port Number, (4) Default Router, (13) Enable Web Access. Once configured, input “0” and accept default settings for the rest of the options. Note: If no configuration options are selected, the device will automatically reboot within 30 seconds with an IP address of 192.168.1.1/24 on interface 1 with Web Access Enabled.

Once the device is rebooted and the appropriate physical port connected to the network, a web browser can be used to connect to the WSD. In the address field, simply input: http://<ip address></ip>

Add additional IP interface for public network. From the menu bar on the left, click Router à IP Router à Interface Parameters. Click Create to add a new IP interface. Configure the IP address, subnet mask, and physical interface to use, most likely interface 2. When completed click Set.

Create Server Farm. From the menu bar, click WSD à Farms à Farm Table. Next, click Create. Within this menu, you should configure at least the following variables:

IP Address – this is the Farm or Virtual IP address.
Farm Name
Dispatch Method – method of load balancing
Session Mode – Choose “Entry per Session”

Next, click Set to send the farm configuration to the WSD.

Add Servers to Farm. From the menu bar, click WSD à Servers à Application Servers. Click Create to add servers. Select the correct farm (created in the previous step) and input the IP address and Name of the server in the table and click Set. Repeat step for each server. Remember to verify that the default gateway of each server is set to the physical interface of the WSD, not the farm address.

Setup additional support for WTS. From the menu bar, click WSD à Farms à Additional Parameters. Select the farm created in Step 6. Set the “<place w:st="on"><placename w:st="on">Terminal</placename><placename w:st="on">Server</placename><placetype w:st="on">Port</placetype></place>” field to the correct TCP port for your implementation. By default, Microsoft uses 3389 unless otherwise noted or reconfigured. Specify the correct port and click Set to finalize configuration.

Additional Load Balancing Configuration

Each server farm can be configured to distribute traffic based on the specific solution requirements. For example, selectable Dispatch Methods (Load Balancing Algorithms) include: Cyclic (round robin), Weighted Cyclic, Least Users, Least Traffic (Packets per second), and a customized algorithm in which the WSD can be configured to poll specific SNMP variables on each load balanced WTS. The customized algorithm allows a user to specify two specific SNMP reportable variables to be used when load balancing traffic to each server, for instance, the WSD could poll each server for CPU and memory utilization and use this real time performance data when redirecting new sessions among WTS servers in the farm.

Additionally, priorities or “metrics” can be set per server to allow for a heterogeneous server farm of many types of servers. For instance, a server farm may consist of servers of varying levels of performance. Because of this, each server can be configured with a predefined “weight” that the WSD will take into account when load balancing traffic.

最近访客 更多访客>>