Two of the most common questions I receive from people interested in implementing Terminal Server are
How many users can I expect to run on a single server?
What are the server requirements in order to support x number of users (where x might be 20, 50, 100, 400, or more)?
Unfortunately, there’s no easy answer to either question—for a number of reasons. Some of those reasons are the following:
Your server requirements will be influenced heavily by the applications you plan to implement—. Server requirements for running Microsoft Word by itself are very different from those required for concurrently running Word, Excel, SAPGui, and a custom-developed client/server application. Different applications stress a server in different ways. One application may have high memory requirements, for example, while another has high processor requirements.
Users with different skill levels and job functions utilize server resources in different ways—. For example, data entry workers typically introduce a smaller load on a server than a power user who’s performing advanced Excel calculations.
Even users within the same job classification work within the Terminal Server environment in different ways—. One user may open all his or her applications immediately after logging on and then switch between them as necessary throughout the day. Another user may open and close the applications only as required.
So how do you go about sizing a Terminal Server environment? To properly size the hardware requirements for your implementation, you must take the time to work iteratively through a process of estimating and then fine-tuning to meet the expectations of the project. Don’t expect to come up with a sizing solution simply by estimating user and memory requirements, performing some calculations, and then extrapolating the results. To properly size your environment, you need to develop a proposed sizing, perform some real-user testing with the applications against the estimated size, and from the results, determine what should be a reasonable expectation for the number of servers and users per server.
Figure 6.1 shows the process I typically follow when sizing requirements for an implementation. While the steps seem trivial, the actual work performed during each step varies, depending largely on the implementation requirements determined in Step 1.
The remainder of this chapter focuses on working through the steps involved in the process illustrated in Figure 6.1.
To properly size your Terminal Server environment, you first need to understand exactly what will be required and expected by both the users and the business. These requirements must be taken into consideration when making your sizing decisions. In general, there are four areas to consider when determining environmental requirements:
User-capacity requirements
Application requirements
System availability
Risk tolerance
The following sections describe in detail the considerations for each of these areas.
There are two things to consider when looking at user-capacity requirements. The first is the maximum number of concurrent user sessions in the environment, as well as the total user base that will be receiving the ICA or RDP client. Accurate assessments of these numbers are important not only for sizing the necessary hardware but also for knowing how many user licenses will be required. Remember that Microsoft requires licensing for the total size of the user base, while Citrix requires licensing equal to only the total concurrent user count.
Once I have the total number of expected concurrent users, I typically add 10–15 percent to this estimate as a buffer. For example, say I’m sizing an environment that will need to support 400 concurrent user sessions in a desktop-replacement scenario, with a total client deployment of 600. So, even though I have 400 concurrent connections, theoretically there could be 600 if all users decide to connect at the same time. To the 400 concurrent user sessions, I add my 15 percent buffer to get a total of 460. The idea will be to size the environment to support 460 concurrent users.
TIP:
Remember, at this point we’re simply trying to determine the total user capacity; we’re not interested quite yet in how many servers we will need to support the configuration.
If you will be publishing individual applications, you may need to calculate the total concurrent user distribution in your environment differently than you would when publishing a full desktop. Say, for example, you are planning to publish two applications (AppA and AppB) instead of a full desktop. Examining the applications individually, you then determine that the current sessions for each application are
AppA—. 150 concurrent users
AppB—. 450 concurrent users
Totaling both together you end up with 600 concurrent users, but this value can be deceiving. There are two factors that will directly influence the actual number of concurrent users in the environment:
If, for some reason, the two applications will be completely segregated from one another on two different machines, you will have to size the two applications independently.
AppA will need to be sized to support 150 concurrent users, while AppB will have to support 450 concurrent users. Each application should be treated as a separate deployment and the hardware sized independently by following the steps in Figure 6.1. Even if the same user will be accessing both applications, because the user will require a distinct session on each server, they will need to be treated separately.
If the two applications will be deployed on the same server, you will want to size the environment based on a true concurrent load of between 450 and 600 users.
If the users that run AppA are also all users that access AppB, your load will be 450 users. If, on the other hand, the user base is completely distinct for the two applications, you will have 600 concurrent users. More likely, you will have a mixture of some users who run both applications and some who run only one or the other.
TIP:
When publishing multiple applications on multiple MetaFrame servers, the method by which a user is assigned to a server is not strictly based on the server with the lowest load level.
For example, say you deploy three servers in a Citrix server farm (ServerA, ServerB, ServerC), and all three servers are publishing both applications (AppA, AppB). Now, if a user is already connected to a server (ServerA) running AppA and attempts to launch the other published application (AppB), MetaFrame automatically directs the user to the same server (ServerA) on which the first application is already running. Because the user already has an active session that can run the desired application, MetaFrame does not waste resources establishing a session on another server to run this other application.
In addition to sizing the number of concurrent user sessions, you need to categorize the computing requirements of each user. Table 6.1 lists how users are typically divided, depending on whether it’s an application-replacement or desktop-replacement scenario.
Table 6.1. Common Terminal Server User Types
User Type | Desktop Replacement | Application Replacement |
|---|---|---|
Light user | Usually runs two or three applications—a line of business app plus host access or e-mail. Processing is typically light, and server downtime has little impact on the user’s productivity. The published application is not usually directly related to the user’s main job function. | Typically performs consistent and repetitive operations such as data entry or item lookup. |
Medium user | Runs between three and six applications, consisting of two or more client/server apps in addition to office or business productivity tools such as Microsoft Word or Microsoft Project. | Usually performs a specific task or job function as part of a business work flow. Overall processing requirements are higher than those of a light user, plus they’re typically more dependent on availability of the environment. If the Terminal Server is down, users’ jobs are affected. A call center or order desk employee typically fits into this category. |
Heavy user | Runs more than six applications and utilizes advanced functionality such as charting, graphics, or numerical calculations. | When the published application is extremely process-intensive and/or memory-intensive, users are grouped into this category. Job productivity is severely affected if the Terminal Server is down. |
Ideally you’d like to be able to determine the number of user sessions in each category that will make up the total concurrent user load, but rarely is this calculation easily achievable.
When publishing individual applications, I group all users into the medium-user category unless one or more of the applications in question is memory- and/or processor-intensive. If the implementation involves desktop replacement, I usually group it as 80 percent medium users and 20 percent heavy users.
Sometimes this approach yields an overestimate in the hardware requirements (although, surprisingly, not often), but any additional capacity resulting in such an overestimation is always available to provide failover support or room for short-term growth.
If you prefer to perform a more detailed breakdown of the user sessions, I suggest you look at the total user base instead of concurrent connections and establish a percentage of the users who fall into each category.
For example, I might have the following breakdown of my 600 total users for the desktop-replacement example:
25 light users (4 percent)
250 medium users (42 percent)
325 heavy users (54 percent)
Using these percentages, I can divide my 460 concurrent desktop-replacement users as follows:
18 light users (460 × 4 percent)
194 medium users (460 × 42 percent)
248 heavy users (460 × 54 percent)
We use these numbers when discussing the server sizing and users-per-server estimates in the next few sections of this chapter.
Now that you have an estimate as to the number and types of users who will access your environment, the next step is to categorize the types of applications you’ll be serving and whether they’re 32-bit, 16-bit, or legacy DOS. It’s particularly important to flag any 16-bit or DOS applications, because they introduce additional resource requirements (sometimes substantial). Chapter 7, “Server and Application Software Planning,” talks in more detail about application considerations.
In general, all applications of the same type can be grouped together when you perform the sizing calculations, so calculations based on an application-by-application basis are usually unnecessary. What this means is that you can classify Word, PowerPoint, and Internet Explorer as 32-bit applications instead of looking at them individually.
Based on the information you gather, you should create a listing similar to the one shown in Table 6.2. Here I list each of the user categories and estimate how many instances of each application type would be running for a given user type. For example, a light user in my environment will typically run two 32-bit applications and one 16-bit application.
So at any given time, I could expect the following application distribution in my Terminal Server environment for all 18 of my “light users.”
36 instances of a 32-bit application (18 × 2; 32-bit apps)
18 instances of a 16-bit application (18 × 1; 16-bit app)
Remember that these numbers represent my entire Terminal Server environment, not necessarily just a single server.
It’s usually easier to simply base your estimates on medium or heavy users instead of dividing the applications into individual user categories. When doing this, you can usually base your calculations on the applications that would be run by the majority of the users or the applications run by your heavy users, whichever is greater. In my desktop-replacement example, I could assume that all 460 concurrent users were heavy users running six 32-bit applications and one 16-bit application. Multiplying 460 × 6 would give a total of 2,760 instances of a 32-bit application and 460 × 1 instances of a 16-bit application running in my Terminal Server environment.
Another area of consideration very often completely overlooked during Terminal Server sizing is the business requirement for system availability. Does your environment need to be accessible 24×7 or only during local business hours? Expected time of availability for your Terminal Server environment will have a large bearing on your final sizing considerations. Be sure to provide sufficient capacity so you can take servers offline for maintenance or upgrade while minimizing impacts on system availability.
For my sizing example, I assume that my environment needs to be available 24×7, with a peak concurrent user load occurring between 8 a.m. and 6 p.m. Then from 6 p.m. to 8.a.m., the concurrent user load drops from 400 to 150. Using my 15 percent rule, I size this off-peak load at approximately 175. Table 6.3 summarizes this information.
I take this information into consideration during my system sizing and plan an environment in such a way that I can take certain servers offline after 6 p.m., while keeping others online to support the 175 concurrent-user load for the second shift.
The final area of consideration is the level of risk tolerance your business has for downtime. While you would ideally never have a Terminal Server go down, the reality is you’ll have an unexpected server failure at some point. Your goal in designing and implementing your environment is to minimize these outages and their impact on users.
Your company’s level of risk tolerance will have the most significant bearing on your final decision as to the number of users you’ll have per server. The reason is actually quite simple: The more users you have running on a single Terminal Server, the more users affected if the server goes down. The amount of risk tolerance is often dependent on the types of applications that will run in the Terminal Server environment and how critical they are to the business. A mission-critical application will likely have a much lower tolerance level than office productivity tools such as word processing or mail readers.
NOTE:
Of course, some organizations consider office productivity applications such as e-mail to be mission critical, so be certain you have a clear understanding of what the business must have available in order to continue working, even if productivity is somewhat impaired by an outage.
Given the choice, most organizations would like to minimize risk as much as possible, but realistically the costs of doing this can make it impractical. A compromise must be reached between risk and cost when determining the user-per-server ratio.
The easiest way to do this is to provide a simple table containing different percentages of the total concurrent user count (not including the 10–15 percent overhead) and solicit feedback from the business (whenever possible) as to how many users can acceptably be affected by a server outage. Ideally you (or your supervisor) will discuss this with a representative from the different departments to be affected by the implementation.
Table 6.4 gives an example based on my sample environment of 400 concurrent users. The table contains calculations ranging from 5 percent to 60 percent, representing the percentage of concurrent users on each server. I omit 0 simply because it’s impossible to have an outage without affecting at least some users. I also do not go higher than 55 percent (220) in this example due to a limitation in the page pool size in Windows 2000, which limits maximum size of the registry, which in turn limits the number of concurrent users on a server. In practice, the upper limit on concurrent connections per Terminal Server (Windows 2000 Server only) is around 200. This limit does not exist with a Windows 2003 Terminal Server.
NOTE:
Details on this registry limitation are discussed in Chapter 11, “Terminal Services Configuration and Tuning.”
From the table select two numbers representing the business’s acceptable and maximum risk-tolerance factors. For example, say that out of the 400 concurrent users, your business would be most comfortable having only 60 users affected by a server outage but could tolerate an impact of up to 100 users before it would have a significant affect on the business. Taking these values and adding the 10–15 percent overhead, you have the target range for determining the number of users per server. This is not necessarily the maximum capacity the servers will support, but it is the range you’ll initially size for.
In my example, adding the 15 percent overhead would get a user count between 70 and 115. I record these numbers as UL (for lower users per server) and UH (higher users per server). This range is used along with the other information gathered during the requirements phase to develop a plan for the hardware requirements of the Terminal Server environment.
Now that you have an estimate of the number of concurrent users per server, the next step is to determine the hardware requirements that will support this environment. It’s important to remember that this information should be used as a guideline in developing your hardware configuration but shouldn’t be treated as the final word on the subject. The only way to ensure that the calculated estimates meet your requirements is to perform some load testing once you have Terminal Server installed on the proposed hardware.
Having said that, I want to make it clear that it is certainly to your benefit to try and determine as accurately as possible a server configuration that meets your expectations since in most cases, once the hardware has arrived, it is rarely returned for something different.
NOTE:
I highly recommend that you consult the Microsoft Windows Server Catalog, formally known as the Hardware Compatibility List (HCL), prior to selecting any type of hardware if you are unsure as to its support of the target operating system (Windows Server 2003 or Windows 2000 Server). You don’t want to have to worry about the server hardware causing unexpected stability or performance issues. You can find this information on the Microsoft Web site at http://www.microsoft.com/whdc/hcl/default.mspx.
One of the most important factors when looking at your Terminal Server’s processor configuration is deciding on the number of processors that each server will have, not their maximum clock speed. While Microsoft describes a single-processor server as the minimum configuration for a Terminal Server, I recommend that you never plan to implement a single-processor server in a production environment, except possibly in the smallest of environments.
Using the data from Table 6.5, which summarizes the average number of users supported per processor, you can estimate the average processor requirements for each of your servers based on your user types. The Pentium 4 has been included in this table as a reference only. Intel does not provide support for a multiprocessor Pentium 4 configuration. Instead, the equivalent Pentium 4 multiprocessor support is delivered through the Intel Xeon processor family.
NOTE:
The benchmark for processor performance is always being raised as manufacturers continue to deliver faster and more powerful processors. Coupled with this fact are additional processor options such as increased cache size, bus speed, and other performance-enhancing features; for example, hyper-threading technology. The users-per-processor estimates in Table 6.5 should be treated as nothing more than a starting point for estimating the size of your servers. During the load-testing phase, you can establish a more realistic users-per-processor ratio specific to your environment. I usually don’t take the clock speed of the processor into consideration unless it’s a change of at least 25 percent. When this is the case, I usually adjust the users-per-processor estimate by about half the percentage change in processors. So a 25 percent increase in clock speed would translate into a 10–15 percent increase in concurrent user support.
Realistically, when recommending what type of processor to use, I typically say the current low- or mid-level processor. For example, a hardware manufacture may offer four processor types, as follows:
Intel Xeon 2.8GHz with 1MB cache and 800MHz front-side bus
Intel Xeon 3.06GHz with 1MB cache and 800MHz front-side bus
Intel Xeon 3.2GHz with 1MB cache and 800MHz front-side bus
Intel Xeon 3.4GHz with 1MB cache and 800MHz front-side bus
The performance increase from the lowest process to the highest is only about 20 percent, but the additional cost can be upwards of $800 or more. In this situation, I would go with the low-end process and use the cost savings toward additional memory for the server. Memory requirements are discussed in the “Memory” section of this Chapter.
Now let’s look at a couple of examples of how you could use the data from Table 6.5 to estimate the processor requirements for your server. Returning to our earlier example of 460 concurrent users, we have the proposed lower and upper estimates for the number of users per server at 70 and 115, respectively. Using the data from Table 6.5 and assuming that all users are classified as heavy users, we could calculate the number of processors per server as shown in Table 6.6.
Table 6.6. Estimated Number of Required Processors Required to Support the Concurrent User Load per Server
Calculation | Notes | |
|---|---|---|
Pentium III | 70 divided by 29 heavy users | When the result is not a factor of 2, I round the number to the nearest power of 2 unless it’s a single processor, in which case I round it to 2. |
= 2.414 | ||
= 2 CPUs | ||
115 divided by 29 heavy users | ||
= 3.966 | ||
= 4 CPUs | ||
Xeon | 70 divided by 59 heavy users | This is rounded to 2 because I will not run single-processor Terminal Servers. |
= 1.19 | ||
= 2 CPUs | ||
115 divided by 59 heavy users | ||
= 1.95 | ||
= 2 CPUs |
Based on these processor calculations, the adjusted users-per-server estimate would now be as shown in Table 6.7.
There are a couple of things to note in Table 6.7. First, I assumed that if one processor will support 29 users, two processors will support twice as many (58 users). This assumption is not strictly true, as increasing the number of CPUs in a server does not equate to a truly linear increase in performance. One reason that I assume a linear increase to be valid is that my estimates are based on the assumption that these users are continuously working, which in most environments is not strictly true. A fair percentage of users are either idle or introducing only minimal load on the server at any one time, so based on how my calculations average out, I’ve found that these estimates remain fairly close to the acceptable sizing values for a server.
Secondly, don’t be alarmed by the fact that the users-per-server estimate for the Pentium III has dropped off from 70 to 58 to accommodate the new processor estimate. Remember, these numbers will be used only to size the server you’ll use to perform load testing. It’s not necessarily the final configuration that you’re going to implement. Only after completing testing can you determine the final users-per-server total and from there decide on the actual number of servers to make up the environment.
The third thing you will notice is that the actual supported number of users on a dual Xeon 3GHz is well above the original estimate of 70 users. In this configuration a dual processor configuration supports either setup, so there is no reason to even consider a quad-processor system.
We return to these numbers in the “Determining the Number of Required Servers” section of this chapter, where the number of servers required to meet our implementation needs will be discussed.
NOTE:
In most situations I don’t believe there should ever be a need to deploy quad-processor Terminal Servers. While the configuration is certainly impressive from a technical standpoint, a pair of dual-processor servers will accommodate the load just as well and provide the server redundancy that a single-quad processor machine will not.
While arguments against the additional licensing costs for a second server have merit purely from a budgeting standpoint, I believe these additional licensing costs can easily be offset by the reduced cost of dual-processor hardware and the load distribution provided by a multiple-server configuration.
No matter how many processors you have or how fast they are, without sufficient memory your server cannot adequately service the needs of multiple simultaneous Terminal Server users. The most common cause of a Terminal Server failure is inadequate memory to support the number of concurrent users on the system.
There are three areas to consider when calculating the amount of physical RAM required on the server:
Operating system requirements—. The operating system requires a certain amount of memory in order to function. I recommend the following based on the Terminal Server version:
Windows 2000 Terminal Services
150MB
Windows Server 2003 Terminal Services
200MB
Per-user requirements—. A certain amount of RAM is required to support each user’s session on a Terminal Server. In general, there are two ways to approach estimating the RAM requirements for each server. The first method is to look at the individual requirements based on the type of users running in the environment. Usually you can allocate memory as follows:
Light user
15MB
Medium user
20MB
Heavy user
30MB
These requirements may seem high in comparison to some recommendations from other sources, but I’ve always found that providing a slightly higher estimate on memory requirements helps to ensure that the server functions as robustly as possible. Using these numbers, you can then calculate the user RAM requirements for your implementation. As with the processor calculations, you can either calculate memory requirements based on the percentage breakdown of the different user types that will be accessing the server or simply base the calculations on the assumption that all users are either medium or heavy users. You then multiply the number of users per server by the allocated memory requirements: 20MB for medium users and 30MB for heavy users. This can result in an overestimate of the memory requirements for the server, but typically this results in a slightly higher users-per-server ratio than you originally anticipated.
Additional application memory requirements—. I’ve found that if users will be running three to four or fewer applications, memory sizing based on the per-user requirements listed in the preceding point of this list is sufficient without augmenting the memory totals. If users will run more than three or four applications, you’ll need to perform additional calculations to take into consideration the memory requirements of those applications beyond three or four. Memory calculations for the different application types are summarized as follows:
DOS apps—. 2MB RAM per DOS application.
16-bit apps—. 4MB RAM per Windows on Win32 (WOW32) session plus 2MB for each additional 16-bit application running within the same WOW32 subsystem session.
32-bit apps—. 4MB–10MB RAM per application on average is usually fair for most Windows applications, although special care must be taken when estimating the size of database-driven client/server applications. These types of applications are notorious for consuming large amounts of RAM, particularly if they are left running for an extended period of time. Don’t be surprised if you encounter such an application consuming 50MB or more of RAM. A more realistic estimate of the memory requirements of an application can be gained by examining the application’s behavior when running in a test Terminal Server environment or even when running on a regular Windows 2000 or Windows XP workstation computer. Figure 6.2 shows an example of Windows Task Manager running on a Windows 2000 Terminal Server, listing all running processes by memory used. The highest memory-consuming server in this example is a SQL Server–based client/server application.
Using my adjusted users-per-server estimate from the “Processors” section, I would calculate my environment’s memory requirements as follows:
First I get the amount of RAM required for my operating system. I’ll be implementing Windows Server 2003 Terminal Services, so I need approximately 200MB of RAM for the server.
Next I calculate the per-user memory requirements. For completeness, I calculate for both the processor types described previously. First I assume that all users are heavy users, so on a server with 58 user sessions, I would calculate this total RAM requirement:
And for my 70 user sessions I would have this amount:
Now, if I break down the user totals into the percentage of user types (4 percent light, 42 percent medium, and 54 percent heavy), my calculations for the 58 users per server would be as follows:
So using the more detailed calculation, you can see that I am still within a couple of hundred MB of the RAM estimate based on all heavy users on the system.
Now I calculate the additional RAM required to support the additional applications in the environment. If I assume that all users are heavy users, I calculate the requirements for all of them to run two additional 32-bit applications. Remember, I’m assuming that three to four 32-bit applications are already included in the base-size estimate for the per-user memory requirement. There is also the memory requirement of the one additional 16-bit application. I’ll assume 8MB as the estimate for memory requirements in this situation for 32-bit applications.
The application memory requirements for 58 users per server would be as follows:
And for 70 users per server:
Now all that’s left is to total the memory requirements for each Terminal Server. For my 58 users-per-server example, I get the following total:
From this I can estimate that I would need around 3GB of memory per server in order to support 58 heavy users concurrently accessing six 32-bit applications and one 16-bit application.
For my 70 users-per-server example, I would have this total:
Therefore, I can estimate that I need approximately 3.5 to 4GB of memory per server in order to support 70 concurrent heavy users accessing the same six 32-bit and one 16-bit applications.
Your decision on which disk subsystem to use for your servers is based on a standard recommendation instead of a calculated per-user value. In a properly sized environment, you should encounter no bottlenecks (beyond the standard disk limitations) as a result of high disk utilization. It’s much more likely that you’ll first become memory- or CPU-bound.
The following issues should be considered when deciding on your disk configuration:
Always use SCSI disk drives in conjunction with SCSI or RAID controllers.
Divide your disk requirements into three areas: operating system, pagefile, and application files. When possible, configure your environment to service the operating system and pagefile with one controller and the application files with the other. If you want to provide disk redundancy in your environment, place the OS and pagefile onto a set of mirrored (RAID 1) drives and not within a RAID 5 configuration. The application files can be run from a RAID 5 configuration, although RAID 1 is usually sufficient, particularly if a hot spare configuration is supported.
NOTE:
My preference is not to introduce RAID 5 unless the environment is configured in such a way that a server cannot be offline for an extended period of time (server uptime must be maximized). Because there’s no permanent user data being stored on the Terminal Server, a high level of redundancy isn’t necessarily required on the server. If a server happened to lose both disks in a mirror configuration, the server could be recoverable fairly quickly based on a standard server cloning and build process (see Chapter 22, “Server Operations and Support,” for a discussion of server imaging). In most situations, having a small stock of spare drives on hand or configured as hot spares provides the necessary redundancy at the disk level for your server.
Chapter 4, “Network Planning,” talks about the requirements for planning a network configuration that supports your Terminal Server implementation, and the overall importance of network performance and availability in your Terminal Server environment. If network connectivity is unavailable, all the processing power in the world won’t help your users. When deciding on the network interface card to use in your server, take the following into consideration:
Select a card from a well-known and supported manufacturer. The de facto standard in many Terminal Server implementations is the Intel 8255x family of Fast Ethernet or 8254x family of Gigabit Ethernet controllers, or an equivalent from the server hardware vendor (such as the Broadcom NetXtreme Gigabit Ethernet controller supplied with many Dell PowerEdge servers).
Choose an adapter that has current drivers for your OS and supports advanced features such as adapter fault tolerance (AFT) or hot swapping to increase server uptime and network availability.
NOTE:
Because of the relatively low cost of network adapters, I usually recommend that dual NIC cards be implemented with some form of teaming or fault tolerance to improve availability. When you want to implement card teaming, always use well-known and supported hardware such as Intel or HP’s Compaq. Poor hardware or outdated driver support can cause stability issues with NIC teaming.
Today, with the availability of high-performance and multiple processors in workstation computers, the performance gap between them and the server in many cases is practically nonexistent. The only difference between many high-end workstations and low-end servers is usually disk drive capacity (workstations may support only dual internal SCSI drives), onboard RAID support, hot-swappable components (power supplies or disk drives), and rack-mount support.
In many Terminal Server configurations, the workstation computer fits the role of a small to medium server, with a lower cost per user than true server hardware. The main limitations that exist in many workstations are their limited support for multiple processors (usually two) and RAM (2–4GB).
The workstation hardware is a viable option because, in most Terminal Server implementations, the servers contain no user data. Couple this with a plan for redundancy at the server level, and there’s no longer the requirement for system redundancy such as RAID arrays or swappable power supplies. Of course, some features such as dual NIC cards are still available, although the fault tolerance in the environment is handled by the presence of multiple redundant Terminal Servers. If you lose a Terminal Server, no problem—there are still x number of other Terminal Servers in the environment that users can log on to.
After gathering and analyzing your requirements and developing a sizing estimate for your server hardware, the next step is to perform some baseline testing on this configuration with your applications to determine what adjustments need to be made in order to best satisfy the requirements of your implementation. For example, you may determine that one of the applications you plan to deploy is very processor-intensive, forcing you to decrease the anticipated user load per server or increase the processing power of each server. This is the type of thing you want to know before you buy all the hardware for your implementation.
NOTE:
Depending on whether you’re introducing new applications or migrating them from the local desktop, you may already have a good idea as to the behavior of the applications and their typical memory and CPU resource requirements. You should still test these in a Terminal Server environment before committing to one hardware configuration or another.
Many big-name hardware vendors will be happy to provide you with an evaluation machine configured to your specifications for a limited demo or trial period, particularly if you make it clear that you also will be trying a competitor’s configuration.
Plan to test your proposed hardware configuration as early in the project as possible and have this configuration finalized prior to the beginning of the proper server build and user testing. If you leave this testing until after you’ve started the user testing and piloting, the chances of your actually being able to switch to an alternate server configuration are pretty slim. What will likely happen is that you will be forced to deploy the hardware configuration you wanted to test, leaving you to hope it is sized close enough to the needs of the business that changes will not be necessary.
Typically, two types of server load testing are available. The first involves testing with a small set of test users. The second involves performing some automated testing to develop results based on high user-connectivity scenarios.
The first phase occurs after you have installed the base operating system (Terminal Server and MetaFrame) and a core set of applications that represent the majority of the usage in your environment. Don’t spend too much time tweaking and tuning the system, since you’re looking for only a reasonable expectation of how the hardware and software will perform. Get a few users (possibly only the members of your project, at this point) to log on to the system in a controlled fashion while monitoring some standard performance counters (see Table 6.8 for a list of some standard counters to monitor). During this testing, you will be monitoring the servers looking for unexpected changes in such things as memory or processor utilization.
Table 6.8. Sample Performance Monitor Counters to Capture During Load Testing
Plan to monitor the system with one user, then two, then four, and try to estimate how you think the system should react to the increase in users. What you’re looking for is some indication that the user sessions and their application usage will scale in a reasonably linear fashion. For example, moving from two users to four users should double (or less than double) the resources currently in use in the environment. This will help to validate that you’ve sized your servers correctly. A drastic change in resource consumption with a small change in user load could indicate a poorly behaved application or some other issue that may force you to adjust your server requirements or dedicate more time to adjusting and tuning the offending application.
NOTE:
You may have noticed that I’ve omitted any network counters from Table 6.8. While issues with your network may severely hamper your users’ computing experience on the Terminal Server, there’s little in the way of server configuration you can do to correct this problem. As I mentioned in the “Network Interface Card” section, I recommend going with a network card–teaming strategy to introduce redundancy in the network cards and also provide a small performance improvement. If there are issues with your network, they need to be addressed separately. See Chapter 4 for a discussion of this topic. I have yet to see a server sized in such a way that it encounters a network utilization bottleneck prior to developing a system bottleneck in another area such as memory.
Figure 6.3 shows an example of Performance Monitor running with the listed counters on a test Windows 2000 Terminal Server.
After performing initial testing with a small set of users, you may also want to develop some rough estimates on how you should expect the server to behave in a situation with an increased user load. One way to do this is to perform some automated server load testing, using a load-testing tool.
Two tools are available to help you do this. The first is the Capacity Planning Tool provided as part of the Windows 2000 Server Resource Kit, or as a link from within the Microsoft document “Windows 2000 Terminal Services Capacity and Scaling.” This document includes some detailed information on capacity and scaling tests performed using this tool.
Citrix also provides a tool called the Citrix Server Test Kit (CSTK), free from the Citrix Developer’s Network (CDN). The CDN can be accessed from the Developers link on the main Citrix Web site or directly at http://apps.citrix.com/cdn. Citrix includes documentation on how to configure and use this tool, along with sample scripts for use with Microsoft Office products.
Automated testing is usually done simply to validate that the server sizing is in the ballpark with regard to the system requirements and to get an idea as to how the server will behave under heavy user loads. Of course, automated testing can never fully replicate the behavior of real users.
NOTE:
Unless you have concerns about the results of your configuration after the initial user testing, or you want some additional validation based on very large user loads, I rarely see a reason to perform automated user testing.
Automated testing can require a large amount of configuration in order to generate truly accurate results, so be prepared to invest a significant amount of time in order to acquire the results you’re interested in.
Besides the Citrix Server Test Kit, there are third-party load- and application-testing tools designed specifically for Terminal Server and MetaFrame. In the past, such tools were ill suited for automating user load testing, either because they ran poorly in the multiuser environment or because they didn’t run at all.
This situation has certainly changed. Now load-testing tools exist that have been designed specifically for operating in a Terminal Server environment. For example, Mercury Interactive (http://www.mercury.com) now has a product called LoadRunner for Citrix, and Scapa Technologies (http://www.scapatech.com) has its Scapa StressTester for Citrix MetaFrame. Downloadable evaluation software is available from both companies.
Once all the sizing and load testing are finally complete, you should be able to comfortably predict the number of users a server in your environment will be able to support and, hence, determine the number of servers required in your environment.
To perform the calculations, you’ll need the total number of concurrent user sessions including the 10–15 percent overhead, in addition to your estimated number of users per server.
If S is the number of servers, UC is the number of concurrent users, and US is the number of users per server, the calculation is simply this:
We now take one last look at my example and the estimated number of users per server. Let’s assume I’m interested in deploying only dual-processor servers and, after performing my load testing, I determine that the dual-processor configurations for the two types of servers actually can support more users than I originally anticipated. The actual supported loads are as follows:
Dual Intel Pentium III Xeon: 78 concurrent users supported instead of the expected 58.
Intel Xeon 3 GHz: 129 current users supported instead of the expected 118.
Based on these values, the number of servers I would need to support this number of users per server with a total of 460 concurrent users would be the following for a P3 processor:
This value I would round up to 6 (six) for the Pentium III configuration.
On a Xeon processor, the number of servers needed would be calculated as follows:
This value would be rounded up to 4 (four) servers for the Xeon configuration.
So it would seem that I would need six Pentium III or four Xeon-based servers in order to support the totally concurrent load of 460 users. But we’re not quite finished. These calculations represent the number of servers required when all are operating at 100 percent and don’t take into consideration the requirements for system availability in my environment. If for some reason there’s a server failure, the environment won’t have sufficient capacity to allow those users who were kicked off the failed server to log back on to the environment. To ensure environment availability, I should augment the calculated number of servers by approximately 25 percent.
So increasing my server count of six by 25 percent, I would end up increasing the number of servers to 8 in total, resulting in a reduced average number of users per server from 78 to around 57 but having sufficient capacity to be able to lose 2 servers and still support the entire concurrent user load.
Increasing the Xeon server count by 25 percent would increase it from 4 to 5 and reduce the average number of users from 129 per server to around 92.
NOTE:
Don’t be fooled by the assumption that fewer servers will directly result in reduced administration requirements. In a properly configured environment, the additional overhead required to support 10 servers versus 5 is very small, particularly when also implementing MetaFrame and leveraging the centralized management tools it provides. The increased availability of the 10-server configuration usually results in greater administrative flexibility, allowing you more time to troubleshoot or perform maintenance on a server without affecting the user community.
One final thing to note is how many servers are available for maintenance during peak and off-peak hours (refer to the “System Availability” section). In my example, even during peak hours, one to two servers could be offline without affecting the environment. During off-peak hours, when my concurrent user load drops to only 175 users, I can take more than half the available production servers offline.
In addition to assessing and planning for the Terminal Server hardware in your environment, there are a number of other servers that will be required in order to deliver the full set of services necessary for your Terminal Server implementation. I finish this chapter by taking a brief look at these servers, the services they provide, and what category of hardware would typically be required.
The licensing requirements for Microsoft Terminal Server were discussed briefly in Chapter 1, “Microsoft Windows Terminal Services.” When deploying Terminal Servers with or without Citrix MetaFrame, you will need a server upon which to run the Terminal Services Licensing service. Where exactly this service runs will depend on a couple of factors, which are summarized in Table 6.9.
Table 6.9. Terminal Services Licensing Service Location
Windows Version | Without MetaFrame | With MetaFrame |
|---|---|---|
Windows 2000 | On a domain controller in a Windows 2000 Active Directory domain. | On a domain controller in a Windows 2000 Active Directory domain. |
On any member server in a work group or NT4 domain. | On the same member server as the MetaFrame Access Suite Licensing server in a workgroup or NT4 domain. | |
Windows 2003 | On a domain controller in a Windows 2003 Active Directory domain. | On a member server in a workgroup or NT4 domain. |
On a member server in a Windows 2000 Active Directory domain. On the same member server as the MetaFrame Access Suite Licensing server in a workgroup or NT4 domain. | On the same member server as the MetaFrame Access Suite Licensing server in a Windows 2003 or 2000 Active Directory domain. |
The Windows Terminal Services Licensing service requires only minimal server resources and introduces no noticeable load increase on the server on which it is installed. The disk space requirements are only about 1KB for each assigned Terminal Services client access license (TSCAL).
One location where I don’t recommend installing the Terminal Services Licensing service is on a Terminal Server. This is not so much because of the additional load it can introduce on the Terminal Server as it is because this would then create a dependency on that Terminal Server being available. When deploying Terminal Server, I always recommend trying to keep all data off the Terminal Server so scheduled backups of the server are not required. If the server is lost due to a failure, you do not want to have to worry about restoring data that may have existed on the server.
NOTE:
From Table 6.9 you can see that when deploying MetaFrame I prefer to group the Windows Terminal Services Licensing service on the same server as MetaFrame Access Suite Licensing (MASL). My only exception to this is when Terminal Server licensing is running on a domain controller. I personally don’t recommend running MASL on a domain controller, mainly due to the need to run IIS on the server in order to use the Web-based management tools. I discuss the MASL hardware requirements in the next section of this chapter.
MetaFrame Access Suite Licensing (MASL), discussed in Chapter 2, “Citrix MetaFrame Presentation Server,” has completely different requirements from licensing for earlier versions of MetaFrame. MASL requires the following minimum software and hardware requirements:
Windows 2000 Server—. Regular server as well as Advanced or Datacenter server. All require Service Pack 3 or higher.
OR
Windows 2003 Server—. Standard, Enterprise, or Datacenter Edition.
IIS 5.0 or higher—. This must be installed on the server before installing MASL and is required in order to run the License Management Console, an optional Web interface that allows access to some reporting features not available through a command line interface.
Intel Pentium III, 1GHz with 512MB RAM—. This is Citrix’s recommendation and is more than adequate in most situations to support both the Citrix and the Microsoft licensing components.
Requirements for the licensing server are straightforward, and a standard configuration for a Microsoft file server will be more than sufficient to support both the Microsoft TSCAL service and Citrix’s MetaFrame license server.
My recommendation when implementing Citrix MetaFrame Presentation Server is to install MASL onto either a dedicated server used solely to run Terminal Server and MetaFrame licensing or an existing file and print server running IIS. MASL will not impose a significant load unless you are implementing a large environment, in which case you will want to almost always use a dedicated licensing server. Microsoft Terminal Services Licensing and MASL should reside on the same server unless you are operating in a Windows 2000 domain and so Terminal Services Licensing must reside on a domain controller. In this case MASL should go onto a member server in the domain and reside separately from Terminal Services Licensing. I do not recommend running IIS on a domain controller.
An important part of a Terminal Server implementation is the file server upon which the user profiles and home folders will be stored. Whether these tasks will be managed by the same server or divided between multiple servers, the file server should have sufficient capacity to accommodate simultaneous connections equal to the total concurrent user load in your Terminal Server environment. Each Terminal Server user will connect to this server to retrieve their user profile and access their home folder. For example, if your environment has 450 concurrent users, the file server should be able to accommodate this without degraded performance. The main resources required for this are memory and disk access. A file server caches frequently accessed files in memory, so having sufficient physical memory in the server will ensure the system cache size is maximized. Both Windows 2000 Server and Windows Server 2003 have a maximum virtual cache size of 960MB on an Intel 32-bit processor server. This limitation is due to the 32-bit addressing space and not a coded limit imposed by Microsoft. The Microsoft support article “About Cache Manager in Windows Server 2003” (http://support.microsoft.com/default.aspx?scid=kb;en-us;837331) provides a summary of the cache manager and applies to both Windows 2000 Server and Windows Server 2003. A fast disk subsystem will also help speed up disk read and write operations, the relatively most expensive operation performed by the file server.
Specific details on sizing and deploying a file server are outside the scope of this book, but more information on this can be found on the Microsoft Web site. Information on tuning a Windows 2003 Server, including tuning for the file server role, can be found at the following URL: http://www.microsoft.com/windowsserver2003/evaluation/performance/tuning.mspx