Calculate Your Server Size

 

This topic provides you with a method that shows how to determine your server sizing requirements, specifically focusing on the hardware that is needed to support a group of users. Because of the wide variety of Microsoft® Exchange configurations and user profiles, it is difficult to determine accurately the number of users supported by a server. You must consider the different types of clients, the activity level of the users, the capacity of the storage subsystem, and how the Exchange server is configured to use the disk resources.

Use the following steps to help you assess these issues and determine what hardware you require:

1. Determine your usage profile.

2. Select a server based on your usage profile.

3. Validate your disk subsystem capacity.

Note

The method described in this section also applies to Exchange 2000 Server. With Exchange Server 2003, you will see slightly lower user loads and significantly better use of memory than with Exchange 2000 Server. Exchange Server 2003 uses approximately 10 percent fewer disk resources than Exchange 2000 Server for the same user profile. If you upgrade and select a new server, include this adjustment in your estimate.

Determine Your Usage Profile

To calculate how many users a server can support, you must first determine your current usage profile. You can calculate a usage profile by using the following two key metrics together:

• Megacycles/mailbox   Megacycles per second, per mailbox. The raw processor usage required per mailbox that is measured during the peak two-hour period on a production server. For example, if a user uses one megacycle/second during peak operation and there are 1,000 users on the server (1,000 megacycles per second), a single 2,000-MHz processor operates at 50 percent CPU usage.

  Note

  The actual units used in this measurement are megacycles per second, per mailbox. For brevity, "per second" is omitted in this section.

• IOPS/mailbox   Input/output per second, per mailbox. The raw database (DB) disk usage (input/output per second) required per user that is measured during the peak two-hour period on a production server. This metric does not include transaction log input/output (I/O) operations. For example, if each mailbox uses 0.5 DB IOPS during peak activity and there are 1,000 users homed on the server, there are 500 DB IOPS. IOPS/mailbox metrics are based on random read/write Exchange database I/O operations.

  Note

  The actual units on this measurement is IOPS per second, per mailbox. For brevity, "per second" is omitted in this section.

Usage profiles are based on production data that may include third-party applications in addition to Microsoft Outlook®. The recommendations in this section are not specific to any particular client or client version. When you calculate megacycles/mailbox and IOPS/mailbox, use the current number of mailboxes on that server.

For detailed steps about how to calculate megacycles per mailbox, see How to Calculate Megacycles per Mailbox.

For detailed steps about how to measure IOPS per mailbox, see How to Measure IOPS per Mailbox.

If the server contains many unused mailboxes or runs other applications that do not add much load during the peak two hours, your results will not represent a typical user load. Choose a server that has typical user mailboxes for your measurements, or do not include the unused mailboxes in your calculation.

Be aware that different days of the week have slightly different usage loads. For example, in many companies, Mondays have a heavier load than other days of the week. A good time to measure typical peak activity is between 08:00 and 10:00 locally on a Monday.

If the server runs other processes that consume significant server resources, consider using the Process\% Processor Time counter for the Store.exe process instead of total CPU usage. Because there are many factors that affect CPU usage that are nonlinear (such as the effect of memory caches and how servers scale with the number of CPUs), use this calculation as a guideline to determine your processing needs. The actual amount of processing needs depends on how much your final hardware differs from the hardware that you use currently for the measurement.

Note

If the users in a company are diverse usage requirements, you may have to measure usage profiles separately for different groups of users. For example, the sales engineers may have a different usage profile than the local marketing group. Having separate measurements is helpful only if the groups of users are significantly different.

Select a Server Based on Your Usage Profile

After you have determined your usage profile (megacycles/mailbox and IOPS/mailbox), you can calculate your CPU and disk subsystem requirements.

The following sections provide four example usage profiles, and a sample server hardware recommendation is also given. You can compare your user's profile with the sample profiles, determine which profile best matches the needs of your company, and use the recommended hardware as a guideline. For example, if you have both heavy users and light users, use the guidelines for the heavy users.

Each guideline below is specific to a usage profile and server/storage area network configuration. The Hewlett Packard StorageWorks Enterprise Virtual Array or CLARiion FC-4500 storage area network (SAN) is used in these examples, but any SAN that provides the same disk throughput will work. After you select appropriate hardware, validate that the disk subsystem meets your needs. For more information, see "Validate Your Disk Subsystem Capacity" later in this topic.

It is recommended that you use a 4-processor (2.8 GHz) server for high-end server configurations. The recommended hardware does not take into account other performance factors, such as network capacity, server memory, and cache sizes. However, by using the example usage profiles, you can estimate if a server has sufficient CPU and disk capacity.

For detailed steps about how to calculate your mailbox server CPU requirements, see How to Calculate Mailbox Server CPU Requirements.

For detailed steps about how to calculate your mailbox server disk subsystem requirements, see How to Calculate Mailbox Server Disk Subsystem Requirements.

Example Usage Profiles

This section provides example usage profiles and recommended hardware for each profile. Use the information you collected in the previous section to determine the example profile that most closely matches your current requirements.

Depending on your mailbox size and user activity, your IOPS/mailbox measurement may be significantly higher or lower than the examples listed in the following sections. For example, one company had user profiles with 4 IOPS/mailbox. The large IOPS/mailbox were mostly because the users had no mailbox quotas (typical mailbox sizes were 1 to 10 GB). The users also sent messages with large attachments (attachment limits had been raised to 25 MB).

Heavy Knowledge Worker Profile

A Heavy Knowledge Worker (HKW) is a very intense knowledge worker profile. Users who fit this profile have jobs that depend heavily on email. Users may have Cached Exchange Mode clients. With this profile, you can expect the following usage load:

• Megacycles/mailbox: approximately 2.5

• IOPS/mailbox: approximately 0.75

Sample large capacity server for an HKW profile

Server hardware	4 processor, 1,996 MHz (Hyper-Threading), 4 GB RAM
Storage area network hardware	Hewlett Packard StorageWorks Enterprise Virtual Array 4 storage groups, 5 databases per storage group, spread across 48 disk spindles using RAID0+1
Mailboxes per storage group	1,150
Mailboxes per server	4,600
Peak processor usage	80%
Peak disk usage	84%

In this sample configuration, the server can support 5,100 HKW users. With 5,100 HKW users on the server, the peak processor usage is 80 percent, which leaves sufficient overhead for periods of extremely high load.

It is estimated that 48 spindles can handle 4,800 IOPS/sec (assuming disks support 100 IOPS/spindle). Therefore, with 4,600 users requiring 0.75 IOPS/mailbox, the peak disk usage for the database drives is 72 percent. If you consider that a RAID1 configuration requires two I/O operations for every write, the estimated throughput is reduced to 3,840 IOPS/sec (for an explanation of how this value was calculated, see "Estimating Disk Capacity" later in this topic). The actual peak disk usage shown in the table above is slightly higher because it is based on a measurement of actual disk capacity instead of an estimate.

Medium Knowledge Worker Profile

A Medium Knowledge Worker (MKW) is an intense knowledge worker profile. Clients may be using BlackBerry or other roaming devices. Users who fit this profile have jobs that depend heavily on e-mail. With this profile, you can expect the following usage load:

• Megacycles/mailbox: approximately 1.9

• IOPS/mailbox: approximately 0.4

Sample large capacity server for an MKW profile

Server hardware	4 processor, 2,800 MHz, 4 GB RAM
Storage area network hardware	Hewlett Packard StorageWorks Enterprise Virtual Array 3 storage groups, 1 database per storage group, spread across 30 disk spindles using RAID0+1
Mailboxes per storage group	1,575
Mailboxes per server	4,725
Peak processor usage	80%
Peak disk usage	67%

In this sample configuration, the server can support 4,725 MKW users. With 4,725 MKW users on the server, the peak processor usage is 80 percent, which leaves sufficient overhead for periods of extremely high load.

It is estimated that 30 spindles can handle 3,000 IOPS/sec (assuming disks support 100 IOPS/spindle). Therefore, with 4,725 users requiring 0.4 IOPS/mailbox, the peak disk usage for the database drives is 63 percent. The actual peak disk usage shown in this table is slightly higher because it is based on a measurement of actual disk capacity instead of an estimate.

Light Knowledge Worker Profile

A Light Knowledge Worker (LKW) is a light knowledge worker profile. Users who fit this profile typically have small mailbox quotas. With this profile, you can expect the following usage load:

• Megacycles/mailbox: approximately 0.75

• IOPS/mailbox: approximately 0.18

Sample large capacity server for an LKW profile

Server hardware	4 processor, 2,800 MHz, 4 GB RAM
Storage area network hardware	Hewlett Packard StorageWorks Enterprise Virtual Array 3 storage groups, 1 database per storage group, spread across 30 disk spindles using RAID0+1
Mailboxes per storage group	3,000
Mailboxes per server	9,000
Peak processor usage	76%
Peak disk usage	46%

Very Light Knowledge Worker Profile

A Very Light Knowledge Worker (VLKW) is a very light e-mail user. Users who fit this profile probably use Post Office Protocol version 3 (POP3) and have small mailbox quotas. With this profile, you can expect the following usage load:

• Megacycles/mailbox: approximately .33

• IOPS/mailbox: approximately .078

Sample large capacity server for a VLKW profile

Server hardware	4 processor, 2,000 MHz, 4 GB RAM
Storage area network hardware	CLARiion FC-4500 4 storage groups, 1 database per storage group, spread across 18 disk spindles using RAID0+1
Mailboxes/Storage Group	6,700
Mailboxes/Server	20,100
Peak Processor Usage	76%
Peak Disk Usage	46%

Validate Your Disk Subsystem Capacity

The final step in determining server sizing is to validate your disk subsystem capacity. After you select a disk subsystem, you should test the throughput of the hardware to make sure it meets your requirements. You can use the Jetstress tool, which Microsoft provides, to measure the performance of your disk subsystem. Jetstress generates stress loads that simulate Exchange Database read/write load. When you run the tool, load each SAN with the maximum number of IOPS (I/O operations per second) without exceeding 20 ms of read or write latencies. For more information about Jetstress, see Exchange Server 2003 Performance Tools.

Many different types of disk subsystems can service an Exchange messaging deployment. The sample subsystem discussed in the following section is an example, and it is not intended to be a recommendation of a particular storage subsystem. Whatever disk subsystem you select, you should first verify through testing that the subsystem meets your requirements.

Sample Test Results on a Fibre Channel SAN

The data in Table C.5 shows the test results obtained when testing the maximum sustainable throughput on a Fibre Channel SAN. The test was conducted in a lab environment.

Jetstress SAN test

Function	Log	Database
Storage group configuration	6 disk with RAID0+1	6 disk with RAID0+1
Disk write latency (ms)	3	10
Disk read latency (ms)	0	20
Disk transfers/sec	135	430
Disk reads/sec	0	285
Disk writes/sec	135	145
IOPS/spindle	Not applicable	71.7

In this example, Jetstress testing sustained a maximum rate of 430 IOPS per storage group database. The Jetstress test was run with the following parameters:

jetstress -l L:\logfile_location -Z -A -I 50 -D 50 -R 0 -N 0

Note

If Exchange logical units share spindles with other nonmessaging applications or servers, performance may decline. Exchange performs best when disks are dedicated to the Exchange server. If Exchange is sharing spindles, the actual performance may be worse than the performance observed during lab tests.

Based on the measured throughput that the Jetstress test reveals, you can determine how many users your disk subsystem can support. For example, in this scenario, the storage area network can support 1,075 HKW mailboxes.

Estimating Disk Capacity

If you want to estimate disk capacity, a good guideline is to expect about 100 IOPS/sec for each spindle (this assumes 10,000 rpm). Depending on your disk configuration, you may need to make adjustments. For the Exchange database disks, a reasonable ratio of disk reads to disk writes is 3:1. However, you may want to measure the ratio yourself for your users. Assuming a ratio of 3:1, the following table shows the throughput estimates for the RAID0, RAID1, RAID0+1, and RAID5 configurations.

Estimated RAID throughput per spindle

Raid configuration	Estimated IOPS/second per spindle
Raid0	100
Raid1	80
Raid0+1	80
Raid5	57

These calculations estimate that 48 disks striped together are capable of 3,840 IOPS/sec. Similarly, 5 disks in a RAID5 configuration are capable of 285 IOPS/sec.

In a RAID0 configuration, each read and each write generates one I/O operation. In the RAID1 and RAID0+1 configurations, each read generates one I/O operation, but each write requires two I/O operations (a write to each mirrored disk). In RAID5, each write requires four I/O operations: two reads to calculate parity and two writes (one for data, one to write parity). Therefore, the initial number of reads and writes is expanded for RAID1, RAID0+1, and RAID5. For an example of the increase in I/O operations, see "Sample Calculation" later in this topic. In terms of the initial number of reads and writes, the apparent throughput is diminished.

Sample Calculation

The following table shows how many I/O operations are required for 300 read I/O operations and 100 write I/O operations for each RAID configuration.

Sample RAID I/O operation performance

RAID configuration	Number reads and writes	Total I/O operations
RAID0	1 read + 1 write	400
RAID1	1 read + (2 write)	500
RAID0+1	1 read + (2 write)	500
RAID5	1 read + (4 write)	700

In this example, you can see that 400 transactions (300 reads, 100 writes) produces 500 I/O operations in a RAID1 configuration. The apparent throughput is reduced by the ratio of 400/500, or 0.8. Therefore, instead of estimating 100 IOPS per spindle for RAID0, a better estimate is 80 IOPS per spindle.

Planning Your Topology With System Center Capacity Planner 2006

System Center Capacity Planner 2006 is a Microsoft product which is designed to create a system architecture model for deploying server applications including Exchange Server 2003. A typical model consists of the following:

• Topology: Site locations, types of networks, network components, and network characteristics (bandwidth, latency).

• Hardware: Server distribution and characteristics, server and network mapping.

• Software: Server role and service mapping, file and storage device mapping.

• Usage profiles: Site usage and client usage.

After you create a model, you can run a simulation that provides a summary and details about the performance of the application and its supporting components. For more information about this tool, see the System Center Capacity Planner 2006 Web page.

Summary

The three steps to take when sizing a server are:

• Determine the usage profile.

• Select hardware and calculate if the hardware CPU and disk is adequate for the usage profile.

• Validate the performance of the disk subsystem.

Usage profiles can vary over time; therefore, you must monitor your servers regularly to maintain overall good performance and proper load.