Mailbox Server Processor Capacity Planning

Mailbox server capacity planning has changed significantly from previous versions of Microsoft Exchange due to mailbox resiliency provided in Microsoft Exchange Server 2010. Exchange 2010 has been reengineered with the concept of mailbox resiliency, in which the architecture changed so that automatic failover protection is now provided at the individual mailbox database level instead of at the server level. There are two primary changes that affect the Mailbox server role capacity planning process:

• Hosting active and passive database copies on the same server
• Providing database copy count

You can use the information in this topic to better understand these changes and as design guidance for sizing mailbox servers when configured for mailbox resiliency.

Contents

Hosting Active and Passive Database Copies on the Same Server

Database Copy Count

Design Steps

Hosting Active and Passive Database Copies on the Same Server

In Exchange 2010, you can host both active and passive database copies on the same server when the server is configured for mailbox resiliency. The processors on each server service the workload from both active mailboxes (hosted on active, mounted databases) as well as passive mailboxes (hosted on passive databases). The processor requirements for passive mailboxes and databases must be considered when performing Exchange 2010 mailbox capacity planning. A passive database copy uses CPU resources to check or validate replicated logs, to replay replicated logs into the database, and to maintain the content index associated with the database copy. In general, each passive mailbox (hosted on a passive database copy) equates to 15 percent of the CPU utilization required to host the active mailbox (hosted on an active database copy).

A key aspect of Exchange 2010 mailbox capacity planning is determining how many database copies you plan to activate on a per-server basis when configured for mailbox resiliency. There is a range of designs from which you can choose, but we recommend the following models:

• **Design for all database copies activated   **In this model, you design your server to handle 100 percent of hosted database copies becoming active.
• **Design for targeted failure scenarios   **In this model, you design your server to handle the active mailbox load during the worst failure case.

For more information, see the following topics:

• Understanding High Availability Factors
• Understanding Processor Configurations and Exchange Performance
• Understanding Memory Configurations and Exchange Performance

Return to top

Database Copy Count

Using Exchange 2010 mailbox resiliency, you can configure multiple database copies (up to 16 copies per database). Each additional database copy increases the CPU work the server hosting the active copy must do. This additional work on the server with the active copy is primarily log replication and content indexing because each passive copy will retrieve content to index from the active copy.

The per-mailbox CPU requirements of the server hosting the active database copy must be increased by 10 percent for each additional database copy (for example, one copy = 10 percent, two copies = 20 percent, and so on). This factor is only applied to the CPU requirements for the server hosting the active database copy. The CPU used to host passive database copies isn't applied to this calculation. For more information, see Understanding Processor Configurations and Exchange Performance.

Return to top

Design Steps

Due to new sizing factors, additional steps are required to size mailbox servers when configured for mailbox resiliency. The general steps are as follows:

1. Consider high availability requirements for the overall solution architecture. Consider mailbox resiliency or a stand-alone solution, site resiliency, the number of database copies required, and the number of servers or DAGs to handle common failure cases.
2. If using mailbox resiliency, choose which database activation model to design for. (Design for targeted failure scenario, or design for all database copies activated.)
3. Use the following table to estimate CPU and memory requirements based on design. Consider CPU and memory requirements for active mailboxes, CPU requirements for passive mailboxes, and CPU requirements on the active mailbox for additional database copies. Use the activation model choice to define the maximum number of mailboxes the design can accommodate.

The following table provides estimated values based on user profile. The estimated values are based on a peak two-hour period during the knowledge worker workday (for example, from 10:00 until noon). This peak period is often twice the 8 to 10-hour daily average load. The user profile description has been omitted because the range of profiles has grown as e-mail usage has increased.

Per mailbox database cache, IOPS, and CPU estimates based on user profile and message activity

Calculating the Megacycles for Different Processor Configurations

The example in the next section "Example of Capacity Planning for a Mailbox Server" uses a baseline processor configuration, 2 x 4 core Intel Xeon x5470 3.33-GHz processors, that yields 3300 megacycles per processor core. However, this processor configuration most likely isn't the processor configuration you're deploying. Therefore, you will need to perform a megacycle adjustment to determine the available megacycles your server design can support. Use the following steps:

1. Open a Web browser, and then go to www.spec.org.

   Note

   The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.

2. Click results, highlight CPU2006, and then select Search CUP2006 Results.

3. In the Available Configurations drop-down, select SPECint2006 Rates.  Under Simple Request, enter the search criteria (for example, Processor Matches x5550).

4. Find the server and processor you're planning to deploy, click Execute Simple Fetch, and note the resulting value.

For example, let's say you're deploying a Dell PowerEdge M710 8-core server with Intel x5550 2.67GHz processors (2670 Hertz). For this configuration, the SPECint_rate2006 results value is 240, with a value of 30 per core (known in the formula as "new platform per core value").

The baseline system (HP DL380 G5 x5470 3.33GHz, 8 cores), has a SPECint_rate2006 results value of 150, or 18.75 per core (known in the formula as "baseline per core value").

To determine the megacycles of the M710 platform example, use the following formula:

((New platform per core value) * (Hertz per core of new platform)) / (Baseline per core value) = Megacycles per core

Then, using the example values as follows, you have:

30 * 2670 / 18.75 = 4,272 megacycles per core or 34,176 megacycles per server

Example of Capacity Planning for a Mailbox Server

The following example illustrates the processor sizing process. The example has the following design assumptions:

• Mailbox count   12,000.
• Mailbox profile   150 messages sent or received per day.
• Availability requirements   Mailbox resiliency within a single site, tolerance for double-server failures.
• Storage architecture   JBOD (not RAID) storage with three database copies, 300 mailboxes per database, 40 databases with 30 database copies per server (or 120 database copies per DAG). The three database copies are randomly distributed across the four nodes so no two servers look alike.
• Activation model   Targeted failure scenario, where double-server failures are tolerated with minimal outage. This results in 20 databases out of 30 copies per server being activated after two server failure events.
• Server platform   2 x 4 core Intel Xeon x5470 3.33-GHz processors.

The following process applies:

1. Calculate server count   A four-node DAG is required to tolerate double-server failures, so the design needs to begin with four Mailbox servers within the DAG.
2. Calculate maximum active mailboxes per server based on the activation model   Assuming the active databases are equally distributed across the nodes, each server would ideally host 3,000 active mailboxes (12,000 ÷ 4). To calculate the active mailbox count after a double-node failure (based on this example), the mailbox count would be divided by the remaining two nodes, which equals 6,000 active mailboxes per node (12,000 ÷ 2).
   In this example, the MaximumActiveDatabases parameter on the Set-MailboxServer cmdlet is configured for 20.
3. **Calculate active mailbox CPU requirements   **Multiply the maximum number of active mailboxes (20 × 300 = 6,000 active mailboxes) by the megacycles per active mailbox (6,000 × 3 megacycles = 18,000 megacycles), based on the preceding table. Multiply this value by 10 percent for each additional database copy.
   In this example, there's one active copy and two passive copies for every database, so the 18,000 megacycles is increased by 20 percent (18,000 × 1.2 = 21,600 megacycles).
4. **Calculate passive mailbox CPU requirements   **Multiply the number of passive mailboxes (when a server is hosting the maximum number of active mailboxes) by the megacycles per passive mailbox (3,000 × .45 megacycles = 1,350 megacycles), based on the preceding table.
5. **Add active and passive CPU requirements to get total CPU requirement   **In this example, 21,600 active mailbox megacycles + 1,350 passive mailbox megacycles = 22,950 megacycles total CPU requirement.
6. **Apply total CPU requirement to hardware platform   **This example uses a 2 x 4 core Intel Xeon x5470 3.33-GHz processor-based server. This equates to 26,640 megacycles (8 × 3,330 MHz). Divide the required megacycles by the available megacycles based on the server platform to estimate the CPU utilization at peak period after a double-node failure (22,950 ÷ 26,640 = 86 percent predicted CPU utilization). The 86 percent CPU utilization rate represents a fully utilized server with almost no space, but because this is based on a double-failure condition that occurs during the peak period, this rate may be acceptable.
   We recommend that stand-alone servers be designed to not exceed 70 percent utilization during peak period, and two-node and three-node configurations that can only tolerate a single-node failure be designed not to exceed 80 percent utilization at the peak period (during a node failure).

Return to top