How Many Users Will Exchange Server Support?

Real-world concerns put benchmarking results into perspective

Because of the complexity of Microsoft Exchange Server management and administration, many companies want to consolidate thousands of Exchange users on one server. As a deployment grows, its increasing number of servers can make administrative tasks such as adding, moving, and deleting users extremely time-consuming for Exchange administrators. Administrators must use a combination of applications to administer and manage the Exchange environment, which makes administration of large implementations more difficult. (Table 1 lists common tools that administrators routinely employ when administering an Exchange environment.) Future versions of Exchange Server will simplify some of these management and administrative tasks and will enable administrators to perform all Exchange administrative tasks through one application. However, for now, Exchange Server’s diversity of tasks and tools leads many companies to want to consolidate as many users as possible on each Exchange Server machine.

For this reason, performance and scalability have long been systems administrators’ two key considerations when deploying client and server messaging applications. Microsoft raised its performance and scalability standards in Exchange Server 5.5. The product scales to four processors and supports up to 3GB of RAM on Windows NT Server 4.0, Enterprise Edition. In addition, Exchange Server 5.5 supports Information Stores (ISs) of unlimited size. (Microsoft uses 16TB as a theoretical limit, but a practical IS size limit is the amount of disk space you can connect to one NT volume.) This increased scalability has dramatically increased the number of users one Exchange Server system can support. Despite these improvements, most Exchange deployments maintain about 2000 users per server—a number that previous versions of Exchange Server supported. Why hasn’t Exchange Server 5.5 led administrators to support many more users with each server?

When corporations deploy messaging and collaboration applications as integral parts of their business infrastructures, administrators discover deployment concerns that they didn’t expect before the implementation. Messaging deployments offer more functionality than email, and many companies consider collaboration functionality to be mission critical. Performance and scalability are still important, but today’s administrators must also think about backups and disaster recovery when planning a new messaging and collaboration system.

How Useful Are Performance Benchmarks?
Leading hardware vendors have published numerous performance-test results for Exchange Server in the past 2 years. These statistics show how Exchange Server 5.5 performance compares with previous versions of Exchange Server. Exchange Server’s scalability has improved drastically, because the Exchange developers rewrote crucial parts of the Exchange Server code to eliminate areas of contention in symmetric multiprocessing (SMP) environments and to support NT 4.0 libraries. (Previous versions of Exchange Server supported NT 3.51 libraries.) At press time, Exchange Server 5.5’s best published and validated performance-test results show that the product can run 15,000 Medium Messaging API (MAPI) users per server. Compaq achieved this result on a ProLiant 7000 with four 400MHz Pentium II Xeon processors. (For more information about the Compaq tests, see http://www.microsoft.com/exchange/guide/proliant.asp.) The same server supports far fewer users through previous versions of Exchange Server. Graph 1 shows the results of Exchange Server 5.5 and Exchange Server 5.0 performance tests on a different system, a Compaq ProLiant 6000 that has four 200MHz Pentium Pro processors, 2GB of RAM, and a RAID 5 array of twelve 4.3GB hard disks. (For the latest published Exchange Server 5.5 results, see http://www.microsoft.com/exchange/guide/perform_scale.asp.)

These benchmarks are impressive, but before you try to connect 15,000 clients to one Exchange Server machine, think about what the benchmarks don’t tell you. Hardware vendors use their expertise and resources to publish Exchange Server benchmarking results for their systems via Microsoft’s verification process. Vendors design these benchmarks to give Exchange implementation planners baseline references for comparing competing servers’ performance. However, hardware vendors might publish results of tests on platforms or configurations that real-world Exchange deployments wouldn’t use. For example, most vendors publish results for systems they configure with RAID 0 disk arrays. RAID 0 arrays provide the best disk subsystem performance, but this setup fails to protect the system against data loss. The same benchmarking tests might yield results up to 40 percent lower if the vendor used RAID 5 or RAID 1 disk subsystems, but you’ll probably choose RAID 5 or RAID 1 for your environment because of these options’ fault tolerance. If the vendor doesn’t perform the benchmarks on a configuration you can deploy, then you won’t be able to replicate the test results in a production environment.

In addition, most vendors conduct Exchange Server benchmarks in a one-server environment, but most real-world deployments include multiple servers. Networks add overhead for interserver communications to a system’s operations, so servers perform better in one-server benchmarking environments than in networked production environments. Finally, benchmarks don’t account for backup and disaster recovery tasks, IS maintenance concerns, or the effect of third-party add-ons to Exchange Server such as fax connectors and virus checkers.

You might deduce from published performance results that deploying between 5000 and 15,000 users per Exchange Server 5.5 system is feasible. But in the real world, such a deployment would be problematic. Take care when you interpret a vendor’s benchmarks to ensure that you could achieve similar results in your Exchange deployment and that the vendor based the tests on valid simulation methodologies. Ensure that the vendor performed the benchmark according to Microsoft’s guidelines for Exchange Server benchmarking. If a vendor runs a simulation on an improperly configured network, the test might saturate the client or network before the server reaches its maximum performance, which would underestimate the server’s performance.

Real IS Sizes
As a server’s user load increases, the Exchange Server IS grows. For example, an IS for a server with 1000 users, each of whom gets 30MB of mailbox space on the hard disk, is approximately 30GB. When you calculate the size of a new deployment’s Exchange Server IS, you need to consider the deployment’s deleted item retention configuration, IS maintenance requirements, and single-instance storage ratio—the average number of references in user mailboxes to each object in the IS. (For more information about Exchange Server’s single-instance storage, see Tony Redmond, "Inside the Exchange Information Store," April 1998.) In many environments, the Exchange Server IS’s storage requirements outweigh the system’s I/O file requirements. Suppose you analyze a machine and discover that the machine’s I/O operations require a subsystem of twelve 4.3GB disks. If you extend your system analysis to the IS’s storage requirements, you might find that the machine requires 24 disks because of your Exchange Server configuration. To calculate the disk space a server’s IS requires, use a formula that factors in these disk space needs—for example

(mailbox size X number of users) ÷ single-instance storage ratio X (1+ approximate percent of storage space you allocate for retention of deleted items)

Single-instance storage ratios vary widely from deployment to deployment; they typically fall between 1 and 2. Companies also dedicate different percentages of IS storage space to deleted item retention. Exchange Server 5.5 lets you configure how long your IS retains deleted items. You can probably expect the storage space the IS requires for deleted items to be between 5 and 10 percent of the IS size if you configure the server to save deleted items for 14 days. However, the required space varies among implementations depending on each environment’s servers and networks.

Suppose I want to calculate necessary storage space for an IS that will hold 2000 users (each of whom has access to 50MB of mailbox storage space) and that has a single-instance storage ratio of 1.7, and I allocate approximately 8 percent of the storage space for retention of deleted items. I plug these numbers into my formula to find that I need 62GB (50MB × 2000 ÷ 1.7 × 1.08) of storage space for the IS.

You need to add the storage space that IS maintenance (e.g., defragmentation, repair), upgrades, and other administrative activities require to the IS space requirement that the previous formula produces to determine the total amount of storage space you need to maintain your IS. Some ISs require as much disk space for maintenance as for user mailbox storage.

Risks of a Large IS
Because messaging and collaboration applications are crucial to most organizations, these products need to offer high availability and expedient disaster recovery. This need creates a dilemma for Exchange administrators who want to consolidate thousands of user accounts on each server.

If I increase the user load in my previous example to 5000 users per server, each server’s IS increases to more than 150GB. An IS of this size has extreme implications for an Exchange deployment. An administrator planning such a deployment must consider several important questions. First, can the network’s current devices back up the large IS within the time available for backup? Will the backup and restore times meet service-level agreements with internal or external customers? Second, is the increased number of users who are vulnerable to one system failure an acceptable risk? Finally, how much time will the Exchange Server system be unavailable during a restore?

Although many Exchange organizations want to deploy several thousand users per server, most opt to run fewer user accounts on each server because of backup and disaster recovery concerns. Graph 2 illustrates the implications of increasing IS size on the time a disaster recovery takes. (The graph’s numbers represent only an example; backup recovery times for ISs of each size depend on several system characteristics.) Many organizations today face decreasing backup time frames, so a large disaster recovery would be a problem for many firms. (For more information about Exchange Server disaster recovery, see the Exchange Server product documentation, or visit Microsoft’s Web site at http://www.microsoft.com/exchange/library/edrv3.zip.)

Reduce Risk Through Clustering
Another important part of disaster recovery planning is the decision whether to cluster Exchange Server machines. Exchange Server 5.5, Enterprise Edition supports Microsoft Cluster Server (MSCS—for more information about integrating the two products, see Tony Redmond, "Exchange 5.5/E and Microsoft Cluster Server," February 1998). However, Exchange Server supports only MSCS’s service failover mode. MSCS's more robust resource failover mode requires an application-specific resource .dll, and Microsoft doesn't provide such a .dll for Exchange. Exchange Server can perform resource failover operations through a generic MSCS resource .dll.

Another clustering limitation is that architectural design constraints in Exchange Server 5.5 permit only one Exchange Server instance to run in the cluster. Therefore, while one node runs Exchange services, the other node can’t run any Exchange services. Clusters that allow multiple simultaneous instances of services (active/active clustering) might be available in future versions of Exchange Server. For now, this limitation makes Exchange Server systems expensive to cluster and makes return-on-investment justifications difficult for administrators who must prove whether the increased availability and reliability of clustered Exchange Server computers justify the cost.

Administrators considering implementing Exchange Server clustering must determine whether clustering can resolve the leading causes of downtime in their Exchange environment. Many organizations’ leading causes of downtime are administrative and operational problems, which are problems that Exchange Server clustering won’t solve. Each organization must determine whether to cluster Exchange Server machines based on its cost constraints and how crucial messaging and collaboration are to its employees.

Exchange in the Real World
Administrators implementing Exchange Server 5.5 need to understand and interpret performance benchmarks properly to decide how to size servers for their environment. They also need to consider disaster recovery concerns such as clustering, backups, and restores when planning their deployments. And, they need to understand the effects Exchange Server configuration can have on day-to-day server administration, management, and support. To successfully deploy Exchange Server 5.5, you must focus on all these considerations, not just on performance and scalability. I hope Microsoft and hardware vendors will soon make deployment decisions easier by moving their focus beyond performance and scalability to providing customers with the information they need to address all aspects of an Exchange implementation.