Server sizing in MetaFrame XP environments is quite a bit different than server sizing in traditional server environments. Since multiple users simultaneously access MetaFrame XP servers, the hardware tends to be much more robust than that of standard servers. Additionally, because the Windows operating system has been "tweaked" in Terminal Server environments to support multiple users, Terminal Servers deal with hardware differently than standard Windows servers.
In order to be able to adequately create your server sizing strategy, it's worth inspecting how server sizing works in MetaFrame XP environments. To do this, we'll focus on each of the major server hardware components and how they affect multi-user (Terminal Server) environments.
Before addressing hardware, however, there are a few things that you should keep in mind.
First of all, when you design your MetaFrame XP servers, you need to make sure that you have "real" server hardware. Desktop computers turned on their side do not constitute "real" hardware. Even though many of your users might have faster computers than your servers, they will not perform well. A 1.8GHz Walmart PC with 512MB of memory will not perform nearly as well as an HP Proliant 1.8GHz with 512MB server.
This is especially true in MetaFrame environments. MetaFrame servers are usually pushed to their limits due to the aggregate user processing taking place on them. Low-end PCs typically do not have the internal bus speed or internal bandwidth to support many users, even if they have fast processors and a great deal of memory. For testing purposes, low-end PCs are adequate "just to see if it works," but you will not be able to extrapolate any performance numbers from low-end test PCs to real servers.
The bottom line is that you should use common sense and build your MetaFrame XP server like a server. You're going to have a lot of users on this server, so it's not worth cutting corners to save a few dollars.
Now, let's get started with our exploration of server hardware in MetaFrame XP environments. We'll begin with memory utilization.
MetaFrame Server Memory Usage
Every user that runs an application on a MetaFrame XP server will use the memory for that application just as if they were running it on a normal workstation. For example, a quick check of the task manager shows that Microsoft Word requires about 10MB of memory to run. Each user of Word will need 10MB, meaning that 20 simultaneous users will require 200MB of memory. Of course, this is on top of the overhead required for each user to run a session, which is about 4MB, so that 20 users running Word require a collective 280MB of memory on the MetaFrame XP server.
To this you must add the memory required by the base operating system. Microsoft laughingly recommends 128MB. Also, you need to add the 64MB that Citrix recommends for the base installation of MetaFrame XP.
If you add all of these together, you'll find that 20 users will theoretically require that a MetaFrame XP server has 672MB of memory.
Before you run out and start checking the memory usage of your applications, you should know the two reasons that any calculations you make based on these parameters will be totally useless:
- Applications require varying amounts of memory. Even though task manager showed Microsoft Word to only consume 10MB of memory, you must remember that memory consumption will vary greatly depending on the documents that are open. Download and open a 300 page graphics-laden Windows 2000 white paper, and you'll see that Word can consume much more than 10MB. Another thing to watch out for is that the supporting files, such as DLLs, sometime consume the largest amount of memory.
- Terminal Services treats multiple instances of the same executable in a special way. If 20 users are all using Word at 10MB each, then you would assume that 200MB of memory is being consumed, right? In actuality, Terminal Services is a bit smarter than that. Because all 20 users are using the same copy of winword.exe, the system figures that it doesn't need to physically load the same binary executable image into memory 20 times. Instead, it loads the executable only once and "points" the other sessions to that first instance. This is done discreetly. In fact, the components controlling each user's session think that they have a full copy of the executable loaded locally in their own memory space, when in fact all they have is a pointer to another memory space. If one session should need to modify the copy of the executable in memory, the server seamlessly (and quickly) makes a unique copy of the executable for that session.
What is particularly tricky here is the fact that if you look at the task manager, each user's session will report the full amount of memory being used. Only in the total memory usage statistics will you see that the numbers don't add up.
When you're thinking about the amount of memory to put in your MetaFrame XP servers, you should also think about how the pagefile will be used. The official pagefile recommendation for Terminal Server environments is 1.5 times the amount of physical memory. However, this does not need to be strictly followed. When determining your pagefile size, look at the types and numbers of applications that users will be using. Also consider the amount of total system memory. If you have a server with 512MB, then 1.5x pagefile is adequate. However, if you have 8GB of memory, you can probably get away with a smaller pagefile. Try a 4GB pagefile first and then increase from there if necessary.
Some people point out that if your pagefile is smaller than the amount of physical memory, you won't be able to collect any memory dumps when the server crashes. However, very few people actually analyze data from dumps. If you need to take the time to research and analyze dump data, then it is because you have a recurring problem. In this case, you can always bump up the pagefile as needed on the specific servers exhibiting the problems.
Real-World Memory Recommendation
It is typically appropriate to estimate about 256MB for the base system. Then, for each user allow 13MB for the basic environment, plus the amount of memory each application requires. Realistically, there is almost never a reason to build a MetaFrame server with less then 512MB, and most servers now have at least 1GB.
MetaFrame Server Processor Usage
When it comes to sizing MetaFrame server processors, don't take the time to calculate how many megahertz or gigahertz you need to support your users. Processor speeds are dictated by Intel and the hardware vendors, and you're pretty much forced to take what they offer. The real decision when sizing processors is the number of processors. In most cases, you need to figure out whether your MetaFrame servers will be single, dual, or quad-processor boxes.
In deciding how many processors you want in your servers, keep in mind that in Terminal Services environments, the multi-user kernel is based on a cooperative multitasking algorithm. Each user's session sends requests to the processor only as needed. If one user does not need much processor time, then more processing power is available for other users. Terminal Services does not work the same as old timesharing servers, where each user was allocated his particular time whether he used it or not.
Due to cooperative multitasking and the fact that each user's session operates several threads, MetaFrame servers tend to scale very well when two or four processors are used. (Just remember that the more processors you have, the greater your risk of running into a bottleneck in another part of the server.)
In a perfect world, your processor utilization would constantly be 99%. This would indicate that you didn't waste money buying too many processors, but also that no users have to wait for processing bottlenecks.
Real-World Processor Recommendation
Processors are very fast and very cheap. When sizing servers, many people buy single processor servers that are dual processor capable. This allows them to test with a single processor and then add a second if the single processor does not give the results that they want.
Xeon processors will yield better performance in MetaFrame XP, as will those with more cache. The trick will be to determine whether they are worth the added cost. (See the sizing techniques section later in this chapter.)
MetaFrame Server Hard Drive Usage
In most environments, your MetaFrame servers need only to contain the Windows operating system, the pagefile, the MetaFrame XP software, and your software application files. User and application data is usually stored on non-MetaFrame servers or a storage area network (SAN).
Ideally, all your servers will be identical to each other, so that users can successfully load balance across them and you can easily replace individual servers without affecting the entire system. (See Chapter 17 for more details.)
Because of the way that hard drives are typically used in MetaFrame environments, you don't need very much storage space on individual servers. Most people buy two drives and mirror them for redundancy. It's hard to find drives smaller than 18GB anymore, and 18GB should be more than enough storage space for each server, especially if you follow the guidelines from the previous chapter to prevent users' roaming profiles from being permanently cached on your servers.
The large hardware vendors are pushing 15k RPM drives. You'll have to test to determine whether you can actually fit more users on a server with 15k RPM drives over 10k drives. The price difference is currently so steep that if you're building more than a few servers, you can go with 10k drives and use the money saved to buy an entire extra server or two.
Real-World Hard Drive Recommendation
Since MetaFrame XP servers don't store much data locally, you should be able to build your servers with two drives configured to mirror each other for redundancy. Today, most MetaFrame servers are the thin, 1U servers or blades with only two drives.
MetaFrame XP Server Hardware Redundancy
Most name-brand servers now have options for redundant and hot-swappable components, including power supplies, fans, network cards, and PCI slots. Many people think these types of redundant devices are needed because the MetaFrame environment is so important to the business. While this is true, these devices are not always needed in MetaFrame environments.
Quite often, redundancy in MetaFrame environments is built-in at the server level. Instead of spending extra money on fancy servers, many administrators spend money on an extra server that can be added into the load-balance group to support users if a server is lost.