|
|
After introducing the server component in the previous chapter and the network protocols and client components in this chapter, all we need to complete our description of the terminal server environment is a basic estimate of the required bandwidth and network structure options.
So how can terminal servers, RDP clients, and the RDP protocol be used in different network environments? To answer this question, let us look at some basic configurations in detail. We can use these configurations to derive benchmark data to plan, dimension, and configure the network environment. This fundamentally qualitative data will be refined in later chapters to develop precise quantitative estimates.
The simplest scenario for a networked terminal server is to connect it to a number of thin clients or terminals. Windows Server 2003 with Terminal Services in application mode must be installed on suitable hardware. On the same platform, applications must be installed, user accounts set up, and basic user directories created. (See also Chapter 4 and Chapter 5.) For this reason, all application data, user data, user accounts, and user profiles are found on the terminal server. A local printer connected to the server provides the frequently needed print function.
You can link the terminal server to the clients over a relatively simple TCP/IP network structure. This configuration allows the terminal server to handle several dozen users and clients simultaneously.
The network bandwidth required between the terminal server and clients is relatively low. It usually ranges from 20 Kbps to 50 Kbps for each client. The exact bandwidth depends on the applications used and the users’ working style. A more exact basis to calculate the required network resources is described in Chapter 5. Certain graphics applications and intense printer use increase the bandwidth demand, whereas reduced user activity can virtually silence data traffic.
If you want to deploy Windows-based terminals or other relatively simple clients, you might want to assign IP addresses automatically via DHCP. This significantly reduces the installation and administration effort for the clients’ individual configuration. The necessary DHCP service needs to be installed on the terminal server (if required, in combination with a DNS service).
Within a corporate environment, there are often clients with their own peripheral devices connected to a terminal server. Physically, all applications can run on the server in this configuration. From the user’s point of view, it looks as if the applications are running on the client. This is because monitor output and interaction look exactly like local applications. Therefore, it seems natural to use the client peripherals for remote applications, too.
Of course, this contradicts the pure terminal server model in which clients must be as simple as possible. The RDP protocol, however, transfers and maps client interfaces to the server environment (port remapping). This way, many of the local peripheral devices and resources connected to the client are available for terminal server sessions. This particularly includes local drives and printers connected to the client’s serial or parallel interface and devices that are connected to the serial interface. Please note that only USB printers are supported for USB ports.
There are two ways to configure local devices for use with client devices. Certain types of local devices can be made available to all terminal server users or only to individual users who logged on interactively over a suitably configured client. In the first case, the client device is displayed on a specific interface of the entire terminal server. In the latter case, the device appears in the user session only.
Both methods seem logical because the client device can be contacted using the IP address or the logical name and its local interface name (for example, local drive C:). If redirected to a logical terminal server interface (for example, \\TSCLIENT\C), the device becomes available to all affected users through a corresponding driver. The resulting behavior is similar to a peripheral device that is contacted over a network connection. However, the many different client device drivers could pose a problem because they must seamlessly appear in the user sessions on the terminal server.
Client interface redirection can also be used for other peripheral devices that are very important to the corporation. For instance, it is possible to integrate fingerprint scanners into the existing interfaces of an RDP client so that the scanners can be used by the applications running on the terminal server. You might need special drivers to support the virtual channels that allow expanded communication between terminal servers and clients.
What is the minimal configuration of one stand-alone terminal server and a few clients good for? Unfortunately, the answer is rather sobering. A terminal server with this configuration should be used only in testing environments or environments with a very low availability requirement. You could, of course, connect several dozens of clients over an older 10-megabit network without running into problems. But if the terminal server fails, no one will be able to work with the central applications. Because user data and profiles are also located on the terminal server, they could be lost if the system fails.
The terminal server configurations examined thus far are based on a simple, two- layer model. The model consists of a number of clients that access the network over one terminal server. This type of environment is rather limited with respect to the number of potential users and system availability. In the following section, we will introduce models that overcome these limitations and that therefore work especially well in corporate environments.
It is not enough to simply add another terminal server to a single-server environment to accommodate more users. The formula for incrementing terminal servers is actually “one, four, many.”
The reason is as follows: when users log on to the only existing terminal server and use those applications, a profile for each user is created. If a second terminal server were added, users would be able to log on to both servers, creating a different user profile on each server. Users would definitely complain. The only concept that makes sense in this environment is the principle of Microsoft server-based profiles. Because this concept is closely tied to domain concepts, the solution is to install a domain and the corresponding domain controller, or to use an existing domain.
There should always be a second domain controller to prevent any potential errors that, for instance, keep users from logging on. The second domain controller can offset the failure of the first. You can also use one of the domain controllers to save user profiles centrally. If you frequently replicate user profiles on the second domain controller using the appropriate recovery procedures, you increase system availability in case of failure. Therefore, the minimum number of servers needed to implement a fail-safe and load-balanced solution is four.
Due to the problem described earlier, the domain controller should not be put on a terminal server if it can be avoided. It is possible to do so without reinstalling the entire system; however, domain administration and multiple-user processes affect each other so much that the performance of the entire system significantly declines. For this reason, an expanded multi-user system consists of two terminal servers and two domain controllers. Because of redundant components, the four servers and a properly dimensioned network build a relatively secure and capable environment. If you install load-sharing mechanisms on the terminal servers, you will improve availability.
| Note |
By comparison, you can use lower-performing PCs for domain administration. The only requirement is a good network connection between the four servers. Another option is to integrate terminal servers into an existing Windows 2000 or Windows Server 2003 domain with a powerful domain controller. |
Conceptually, it is just as easy to integrate additional servers into this environment. This applies to both additional terminal servers and domain controllers, and to file, print, and database servers (back-end servers). Everything can be tied to a three- or four-layer model that takes into account all servers involved. From a technical point of view, however, it takes a good deal of experience working with complex network structures to realize this type of multiple-layer environment.
Nevertheless, a global network-bandwidth rule does exist for multi-layer models: The bandwidth needed between terminal servers and each Terminal Services client is relatively low, whereas the network between terminal servers and the supporting servers (for file, print, and directory services, or databases) should be as powerful as possible.
The reason for this is clear. The RDP protocol is optimized to use low-bandwidth connections to transport the graphics contents of a user session from a terminal server to the client, and user actions (keyboard and mouse) from the client to the terminal server. Typically, this requires data throughput of 20 to 50 Kbps. Therefore, one terminal server with a 10-megabit network card can theoretically supply data to more than 200 clients of one user session each. Of course, you cannot use a TCP/IP network at 100 percent capacity, nor can a typical terminal server manage 200 simultaneous sessions. Furthermore, the same network connection is used to exchange even more data with other computers on the network. These figures demonstrate that the throughput to individual clients is rarely the bottleneck. The highest likelihood for a problem in this case might stem from pooling many client connections in routers or switches before they reach the terminal server. Pooling can cause problems in selecting optimum routes for data packages, which in turn results in transmission delays (latency). Faulty resolution of computer names to IP addresses can also cause significant slowdowns that are unrelated to the nominal network transfer rate between terminal server and clients. Networks with the fewest intermediate stations ensure optimum communication between terminal servers and Terminal Services clients and guarantee a continuous rate per client within the 50 Kbps range.
The communication between a terminal server and other servers follows a completely different model. The throughput rate must be as high as possible to quickly respond to user-specific requests for file services or databases of the applications on the terminal server. For this reason, terminal servers should be placed on an internal high-speed network and, if possible, logically close to the back-end servers whose services they need. This can be accomplished by arranging all servers, including terminal servers, in a computer center, or at least on the same network segment. This type of setup is known as server consolidation.
So how does a terminal server behave in a consolidated environment? For example, a user starts Microsoft Word on the terminal server, but the application is mapped only to the client. Only when the window for Word is created does the 50 Kbps data stream flow from the terminal server to the client. If the user opens a large document in his or her base directory on the file server, the corresponding data is transferred to the terminal server. Only changes to the graphical user interface, that is, the graphical elements on the currently displayed page in Word, are transferred from the terminal server to Terminal Services client. The document itself does not leave the terminal server to travel to the client! Therefore, the faster the connection between the terminal server and file server with the document, the faster the document is displayed in the user session on the client computer.
Time and again this book refers to the term server farm in connection with terminal servers. A server farm is a group of terminal servers bundled into one logical unit. This unit provides a common set of applications that corporate users can access via Terminal Services clients. This is why the servers in a server farm are usually identical.
To hide the number and identities of a server farm’s members, the servers are often consolidated on a load-balancing system. To users, load balancing is accomplished by a logical device that uses predefined criteria to decide at user logon which physical server will support the user’s session.
| Important |
A load-balanced server farm is not a cluster that transfers processes from a failed server to another server in that cluster. If a server that is part of a server farm fails, the processes on that server are lost. This also applies to the unsaved data being processed when the failure occurred. Users of the server lose their sessions and application data. However, users can immediately log on again to the server farm and continue their work on another load-balanced server. They can use the data file that was created the last time they saved their user-specific application files. The precondition, of course, is that the corresponding file server be completely independent from the server farm. |
A load-balanced server farm optimally fulfills the scalability requirements of terminal servers in corporate environments. Users no longer use the name or IP address of individual servers, but connect to the terminal servers through load balancing. Either a hardware component or several software solutions can be used for load balancing. When administrators discover that servers no longer meet user requirements, they can either upgrade individual servers (scale up) or add servers to the server farm (scale out). Both procedures go unnoticed by users because they normally do not know what physical components comprise a server farm. Regardless of whether a company decides to scale up or scale out, all a user sees is that more resources are available, which benefits overall system performance and the user experience.
A server farm can be operated with dozens or even hundreds of terminal servers if the load is distributed evenly. This is accomplished using completely separate servers for file and print services, directory services, databases, or e-mail services.
| Note |
You will find a more detailed description of the mechanisms and solutions behind the load-balancing concept in Chapter 11. |
At first, a company usually sets up a server farm to provide certain groups of applications to predefined groups of users under strict security standards. Separate server farms should be used only if the company has two clearly delimited environments, such as two divisions with individual cost centers and separate infrastructures.
The integration of back-end servers is critical to the server farm because all user and machine-specific data must be managed independently of the terminal servers to achieve optimum scalability and failure protection. This applies especially to the following data categories, which can be allocated to specialized back-end servers:
User Data User name, password, and other user-specific parameters that are managed on domain controllers. For availability reasons, this data is usually saved on several domain controllers.
Group Policies Binding guidelines for computers and user groups. Also managed by domain controllers.
User Files User profiles and user-specific application files are usually saved on file servers. If a file server is highly available, it can be combined with another physical server to form a cluster. If a server within a cluster fails, the other server assumes its tasks. The data itself is saved on a redundant hard drive system that can be accessed by all servers of the cluster. Other platforms that you can use with file servers are network- attached storage systems or storage area network systems.
The file server setup has a significant influence on overall system performance. If the file server is optimally adjusted for file access over a fast network, the terminal servers are faster. It also allows you to establish a plausible access control and security strategy. Print, database, and e-mail servers play key roles in realizing certain functions on the terminal servers as well.
For Terminal Services clients to operate well in corporate environments, a certain infrastructure is needed. In addition to a stable network, you need a properly functioning name resolution mechanism (DNS server) and an instance for dynamic client ID assignment (DHCP server).
Everything thus far is a clear indication that terminal servers and Terminal Services clients depend heavily on back-end servers. A perfectly functioning server farm is worthless if one of the relevant back-end servers causes problems. For this reason, the consolidation of back-end servers is a prerequisite for successful terminal server projects.
How can we transfer the concepts and models described to a real network? Figure 3-28 shows a typical corporate Local Area Network consisting of a server farm with several terminal servers. The server farm is located in the computer center and is integrated into the same network segment as the company’s back-end servers. If the infrastructure is decentralized, the back-end servers must first be centralized to achieve the necessary environment.
The departmental clients now access the central terminal servers via the RDP protocol. The bandwidth required is relatively low (around 50 Kbps). It is very important that the network be available and the bandwidth constant. One should definitely avoid clients that occasionally transfer large volumes of data independently of the RDP protocol or a large number of simultaneous massive print jobs.
The administration department should use only Windows-based terminals, which excludes the use of local applications. This reduces the client tasks to presentation and interaction and shifts all application logic and data maintenance to the computer center. By consistently implementing the server-centered model, you achieve the best savings in terms of client administration costs.
There are, of course, negative aspects to this type of environment: an environment that is based on terminal servers certainly does not optimally support mapping high-resolution video sequences, intense use of animation, or work on sophisticated CAD documents. This also goes for scenarios that require local real-time use of large amounts of data, such as scanning documents or generating multi-media content. These tasks should therefore be processed using local applications on clients with adequate resources. However, subsequent transfer of the resulting data to central servers can also become an issue in large corporate networks.
The next question is how to transfer the model of terminal servers on a local network to the integration of remote offices over wide area networks (WANs). The difference between a structured local network and a WAN is not very great. Several routers connect the individual company sites via dedicated or leased lines. The resulting network is highly suitable for terminal servers. The bandwidth required for communication between the sites is usually significantly lower than in a conventional environment.
One critical parameter for the successful deployment of terminal servers is latency during the transmission of data packages between sites. Latency determines the delay in displaying graphics elements on the user interface in response to user input. If this time is too long due to gaps in router configuration or the WAN, users are quick to reject terminal server technology.
Figure 3-29 illustrates a corporate network with two remote offices connected to the company headquarters via routers. The headquarters computer center hosts a server farm with several terminal servers. They provide applications to the users who can either be at the headquarters or at their remote offices.
For technical or policy reasons, it is possible that not all corporate server resources will reside at one site. Therefore, terminal servers might need to be operated at several sites. This setup is practicable only if the terminal servers primarily access resources (for example, databases or file servers) located at the same site.
Figure 3-30 depicts a setup in which terminal servers in remote office 1 provide applications that use the data from a database server at the same site. The clients can access both terminal servers in the company headquarters and remote office 1. However, the terminal servers do not have the same configurations and therefore provide different applications. A domain controller is recommended in the remote office so that user profile data does not have to be downloaded from headquarters upon logon.
In the extreme case, the same server infrastructure is available for both remote office 1 and company headquarters. This is often true for large companies that set up a backup computer center at a secondary site for security reasons. A lack of available bandwidth between continents can cause a global company to work with several computer-center and terminal-server sites. However, planning infrastructure and user access paths is extremely difficult under these circumstances.
What typical mistake should be avoided at all costs in a corporate environment with terminal servers? Never put terminal servers where the clients are if there are no back-end servers, which are the most important resource. Communication between terminal servers and their clients usually consumes far less bandwidth than accessing resources such as documents or data in databases. For this reason, a setup as shown in Figure 3-31 does not make full use of the advantages that terminal servers offer. On the contrary, in this instance investments in terminal server infrastructure could actually lead to negative effects.
It is relatively easy to integrate Terminal Services clients in companies as described earlier if the employees work in buildings connected via a common network infrastructure. The situation is quite different if you want to establish a configuration for home offices or very small sales offices. Users access the terminal servers in the company headquarters through modems (analog, ISDN, or DSL) or small telecommunication routers. They can direct their documents to a printer that is locally connected to the server inside the company. It is, of course, possible to use printers that are locally connected to the client, as described earlier.
To integrate home or small remote offices, the company needs a high-performance router. This router translates communication over telephone lines to the local corporate network standard. The bandwidth required is between 56 Kbps and 64 Kbps per client, or possibly less.
You need to note some peculiarities for using terminal servers on telecommunication networks. For one thing, the telecommunication infrastructure must be designed so that the terminal server sees it as the local network. This is not really a problem with the current telephone systems and dial-up routers. Another condition is that the connections between terminal server and clients must always be reliable, stable, and maintained. If the connection is interrupted for only a few seconds, the user session is terminated. It is highly possible that user data will be lost in this case—despite the terminal server option to reconnect a user session.
| Note |
If you establish a configuration for home offices, you definitely need to think about security. Should company documents be printed on the client side? Should data be exchanged between client hard drives and the terminal server? Should logon information be saved on the client? Does the data exchanged need to be encrypted? |
A well-placed note here about modem and ISDN configuration can dismiss false expectations: an existing ISDN connection will not be terminated if the user of a terminal server session is no longer working interactively, that is, if the user is no longer generating direct network traffic with the Terminal Server. The Terminal Server connection will be maintained until the user logs off, disconnects, or reaches a time limit. Special administration packages are sent automatically over the network to ensure that the connection is kept open to prevent possible data loss in application programs that are open in the user session.
|
|
