Bagikan melalui

Mailbox Server Processor Capacity Planning

  • Artikel

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Mailbox server capacity planning has changed significantly from previous versions of 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:

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 database availability groups (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

Messages sent or received per mailbox per day Database cache per mailbox in megabytes (MB) Single database copy (stand-alone) with estimated IOPS per mailbox Multiple database copies (mailbox resiliency) with estimated IOPS per mailbox Megacycles for active mailbox or stand-alone mailbox Megacycles for passive mailbox

50

3

0.06

0.05

1

0.15

100

6

0.12

0.1

2

0.3

150

9

0.18

0.15

3

0.45

200

12

0.24

0.2

4

0.6

250

15

0.3

0.25

5

0.75

300

18

0.36

0.3

6

0.9

350

21

0.42

0.35

7

1.05

400

24

0.48

0.4

8

1.2

450

27

0.54

0.45

9

1.35

500

30

0.6

0.5

10

1.5

Note

You must increase the megacycles per active mailbox by 10 percent for each additional database copy after the one active copy.

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-gigahertz (GHz) processors, which yields 3,333 megacycles per processor core. However, this processor configuration most likely isn't the processor configuration you're deploying. You can use the following steps to perform a megacycle adjustment to determine the available megacycles your server design can support.

  1. Open a Web browser, and then go to Standard Performance Evaluation Corporation.

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

  3. In the Available Configurations drop-down box, select SPECint2006 Rates. In Search Form Request, select the Simple option and then click Go. 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, consider that you're deploying a Dell PowerEdge M710 8-core server with Intel x5550 2.67GHz processors (2,670 megahertz (MHz)). 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 (3,333 MHz), 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 baseline platform)) ÷ (Baseline per core value) = Adjusted megacycles per core

30 × 3,333 ÷ 18.75 = 5,333 megacycles per core or 42,662 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   Just a bunch of disks (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,664 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,664 = 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).

Virtualization

If you’re sizing a new virtualized deployment, you don’t want to oversubscribe processors. Therefore, you want to have a 1:1 ratio of logical cores to virtual CPUs on your host. From there, use the physical sizing guidance discussed in this topic and then account for 10 percent hypervisor CPU overhead. For example, if you sized your physical deployment for 500 users per core, your virtual deployment would be sized for 450 users per core.

Calculating the Number of Required Mailbox Cores per Data Center

As discussed in Understanding Server Role Ratios and Exchange Performance, you will need to size your Hub Transport server, Client Access server, and global catalog server based on the load of the Mailbox servers.

It's a common assumption that the processor core ratio guidance is based on the total number of mailbox cores being deployed; however, that isn't the case. Generally, the Mailbox servers aren't running at 100 percent CPU utilization 100 percent of the time. A well-designed solution should never have 100 percent CPU utilization for an extended duration of time based on the 70 percent and 80 percent design thresholds described in the previous section.

To calculate the minimum number of Hub Transport server, Client Access server, and global catalog server processor cores, you need to determine the number of mailbox cores required to support the active mailbox databases during the worst failure model.

The formula to calculate the required mailbox cores within a data center is:

Required mailbox cores = (active mailbox CPU requirements) ÷ (adjusted megacycles per core) × (number of remaining servers) × (number of DAGs)

If you aren't deploying a high availability solution, the formula is:

Required mailbox cores = (active mailbox CPU requirements) ÷ (adjusted megacycles per core) × (number of Mailbox servers within the data center)

Example of Calculating the Number of Required Mailbox Cores per Data Center

Continuing with the previous example, the solution can sustain two server failures, with each remaining server requiring 18,000 megacycles. Therefore:

Required mailbox cores = (18,000 ÷ 3,333) × 2

= 5.4 × 2

= 11 total cores

This means that, within this data center, a total of 11 cores will be used out of the available 16 mailbox cores during the targeted failure model (or 5.5 cores per remaining Mailbox server).

Based on this data, the minimum number of processor cores that should be deployed within the data center for the Hub Transport server, Client Access server, and global catalog server is:

Minimum Hub Transport server (with antivirus) processor cores per data center = (number of required mailbox cores per data center) ÷ 5

= 11 ÷ 5

= 3 cores

Minimum Client Access server processor cores per data center = (number of required mailbox cores per data center) × 3 ÷ 4

= 11 × 3 ÷ 4

= 33 ÷ 4

= 9 cores

Minimum global catalog server (64-bit) processor cores per data center = (number of required mailbox cores per data center) ÷ 8

= 11 ÷ 8

= 2 cores

Return to top

 © 2010 Microsoft Corporation. All rights reserved.