Now that you've figured out which applications to install on which servers, you must next address the issue of server size. At first, it may seem like this issue was already addressed in the last section. In fact, it's a very different question.
You might have determined from the last section that you want to make a load-balanced silo that hosts Microsoft Office and Adobe Acrobat Reader. What if you have 1,200 users who need access to these applications? Although you've determined which applications you'll install on which servers, you still must decide whether to build 12 servers that will each host 100 users or 3 servers that will each host 400 users. Terminal Server sizing involves:
Understanding how server sizing works in Terminal Server environments.
Creating your server sizing strategy.
Testing your server sizing strategy.
The objective is simple: to build your servers large enough to support your users, yet small enough accommodate your budget. There's plenty to think about when you get ready to size your servers.
Server sizing is not about buying the fastest processors and the most memory. When it comes to server sizing, the maximum number of users a server can support is less important than the maximum number of users you know it can support. If you build a server planning for fifty but only get ten users you will run into problems.
A proper server sizing strategy involves creating a balance between too many small servers and too few large servers. It's possible to build a sixteen processor server with 48 gigabytes of memory. But just because you can build one gigantic server for all of your Terminal Server users—should you? There are plenty of deployed servers out there that have terrible session performance with only 50% of their processors and 30% of their memory utilized.
By building several smaller Terminal Servers, you're able to increase the redundancy of your environment. If you build one gigantic $60,000 server and something happens to it, all of your users are down. However, if you build three $20,000 servers and you lose one, only one-third of your users are not able to access their applications. It really comes down to how many users your're willing to drop at any one time.
Your server environment will ideally balance between the two extreme options:
Build fewer "large" servers.
Build more "small" servers.
Build fewer "large" servers that host more "small" servers via virtual server technology.
A similar topic was discussed previously with regard to the number of applications installed on a server. The difference here is that now we're thinking about the actual number of servers. For example, you might have decided to put only one application on each server. However, if you have 1,000 users accessing that application, you have a choice when it comes to server sizing. You can build a few gigantic servers (two servers supporting 500 users each) or many small servers (ten servers supporting 100 users each).
Drive space, processors, and memory are so inexpensive these days that many people are transfixed by the idea of creating a few massive servers that can each support hundreds of Terminal Server users. (See Figure 5.2.) They like the concept of only having a few servers to manage and the fact that they can spend money on mission-critical redundant drives, processors, NICs, and power supplies.
Figure 5.2: A few gigantic servers
However, every server is going to have limits, and quite often user load does not scale linearly. Two dual-processor servers will commonly scale better than a single quad-processor server in Terminal Server environments.
More economies of scale.
Fewer licenses required.
Fewer servers to manage.
The scalability of Windows 2003 makes this a reality. (Even more so than Windows 2000.)
Single point (or fewer points) of failure.
If you support multiple applications, many of them will need to be installed (and therefore tested) together on the same server.
Instead of building a few large servers, you might choose to build several smaller servers (as shown in Figure 5.3 on the facing page). This option lessens the risk that one system's failure could debilitate a significant user population.
Figure 5.3: Many smaller servers
When considering building multiple smaller servers, two advantages become apparent, most notably redundancy and scalability. Because you have multiple servers, you could lose one without the entire user population going down. (And therefore you might not get paged if this happens, allowing for a full night's sleep.) Also, you can schedule servers to be taken down for maintenance or to be rebooted without affecting everything.
Furthermore, you might be able to support more users with the same amount of money. (Or, you could look at this as being able to save money.) Many Terminal Server administrators also like the fact that building multiple smaller servers gives them more flexibility to dynamically deploy and re-deploy applications as users' needs change.
Another benefit of multiple, smaller servers is the ease with which servers are managed and provisioned today. Many companies are leveraging 1U "pizza box" servers or blade servers to build large farms of redundant servers. (Think of it as "RAIS"—Redundant Array of Inexpensive Servers.) They view Terminal Servers in much the same way as they view thin clients. If one breaks, they can replace it quickly and cheaply and get back to business.
In reality, it becomes easy to replace or increase capacity with the addition of a blade or 1U server, while additional four- or eight-way servers are an expensive way to increase overall user capacity.
Flexibility. Redeploy applications and servers and move them around as needs shift.
Some utilization might be wasted.
You will need to purchase additional licenses for applications licensed on a "per server" basis (such as the Microsoft Windows operating system).
A higher server count might not work in organizations that are pushing for "server consolidation."
A third popular server sizing option involves building fairly large "host" servers that host multiple virtual server sessions. This is done with products such as VMWare or Microsoft's Virtual Server (which they purchased in 2003 from Connectix).
Both of these products work in the same basic way, as, they allow you to run multiple virtual instances of Windows on the same physical server. Each instance has its own IP address, server name, and virtual drives, and you can reboot a virtual server without affecting the others. In a sense, your host server becomes your "rack," and each virtual server acts as its own server.
Since virtual server technology applied in Terminal Server environments is so new, there are not many definitive best practices as of yet. Refer to the resources listed in the appendix for the most up-to-date information.
Allows you to host more users per physical server than would otherwise be possible.
Efficient use of server resources (since any resources not used by one virtual server can be used by another).
Works in environments with "server consolidation" mandates.
Partitioning a single-server into multiple virtual servers allows you to install applications in separate servers, lessening the risk of application interference.
This concept is new, and some people have reservations about using virtual server technology in production environments.
Server software is usually licensing per virtual server, not per physical server.