Now that you know how server hardware components work in MetaFrame environments, you need to think about your strategy for sizing your servers.
The objective is simple: you want to build your servers to be big enough to support your users, yet small enough so that you don't spend too much money on them.
At first, this statement may seem extremely obvious. Nevertheless, there's plenty to think about when you get ready to size your servers.
Why Should You Care About Server Sizing?
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. For example, 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 MetaFrame XP users-should you? There are plenty of servers out there that have terrible session performance with only 50% of their processors and 30% of their memory utilized.
Server Sizing Options
By building several smaller MetaFrame XP servers, you're able to increase the redundancy of your MetaFrame XP 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.
Your server environment will ideally balance between the two extreme options:
- Build a few gigantic servers.
- Build many small servers.
A similar topic was discussed in Chapter 4 with regard to the number of applications installed on a server. (Remember? All applications on all servers verses just a few applications on each server.) The difference here is that now we're thinking about the actual number of servers. For example, in Chapter 4 you might have decided to only put 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).
Option 1. Build a Few Gigantic Servers
Drive space, processors, and memory are so incredibly inexpensive these days that many people are transfixed by the idea of creating a few massive servers that can each support hundreds of MetaFrame XP users. (See Figure 6.1) 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 6.1: A few gigantic servers
However, every server is going to have limits, and quite often, user load does not scale linearly. For example, there are situations in which one server with quad 1GHz processors and 4GB of memory will show 75 users only utilizing about one half of the system. Task manager shows that aggregate processor utilization is about 60% and memory utilization is 1.7GB. Unfortunately, environments like these often generate problems when adding additional users. Adding two additional users to such a scenario might cause the system to slow to a crawl, even though the task manager still shows that the system is only about one-half utilized. Further investigation reveals that the system has run out of page table entries (a known problem with 32-bit Windows servers running 6 or 8 processors), and that adding just two additional users caused the system to begin to get backed up.
In this case, two dual-processor servers with 2GB of memory each might have scaled better than the one large server.
Advantages of Building a Few Gigantic Servers
- More economies of scale.
- Fewer licenses required.
Disadvantages of Building a Few Gigantic Servers
- Single point (or fewer points) of failure.
- If you support multiple applications, many of them will need to installed (and therefore tested) together on the same server.
- The page table entry limit may prevent you from ever hosting more than 200-230 users on a single server, no matter how large that server is.
Option 2. Build Many Small Servers
Instead of building a few gigantic servers, you might choose to build several smaller servers (as shown in Figure 6.2). This option lessens the risk that one system's failure could take out a significant user population.
Figure 6.2: Many smaller servers
When thinking about 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. (This may mean that 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 MetaFrame 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 in favor 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.)
Advantages of Building Many Small Servers
- Easier scalability.
- Flexibility. Redeploy applications and move them around as needs shift.
Disadvantages of Building Many Small Servers
- Some utilization might be wasted.
- You will need to purchase additional licenses for applications that are licensed on a "per server" basis (such as the Microsoft Windows operating system).