Exchange 2010 Mailbox Server Role Design Example

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

This topic provides an example of how to determine the appropriate memory, capacity, I/O, and CPU performance requirements for the Mailbox server role and its accompanying architecture.

You can use the Exchange Server 2010 Mailbox Server Role Requirements Calculator to determine the appropriate requirements for the Mailbox server role by specifying your set of input factors. The calculator can determine the requirements discussed in this example. For more information about the calculator (and to download it), see the Exchange Server Team Blog article Exchange 2010 Mailbox Server Role Requirements Calculator.

For more information about the Mailbox Server role storage design, see Mailbox Server Storage Design.

The scenario used in this example is that of a three database copy solution that makes use of JBOD (just a bunch of disks) storage. For the purposes of this example, consider the following architecture requirements:

• Six Mailbox servers participating in a single database availability group (DAG)

• Exchange Mailbox server also hosts the Hub Transport and Client Access server roles

• Three high availability mailbox database copies, no lagged database copies

• 7.2 K (7,200 RPM) 1-terabyte SATA spindles are used

• JBOD storage configuration (1 logical unit number (LUN) / Database LUN architecture)

• For backup architecture, using the native data protection features provided via single item recovery and mailbox resiliency

• A restore LUN is deployed for maintenance and recovery operations

• Each LUN has at minimum 20 percent free space

• The solution should survive double server failure events

• The only server role installed is the Mailbox server role

Contents

Mailbox Capacity Requirements

Database Copy Requirements

Mailbox Memory Requirements

Mailbox I/O Requirements

Mailbox CPU Requirements

Mailbox Capacity Requirements

The following example illustrates appropriate sizing for an environment in which there are 24,000 2-GB 100 messages per day profile mailboxes spread across six Mailbox servers that are participating within a DAG with each database having three copies. These mailboxes receive an average of 37 MB of mail per five-day work week, with an average message size of 75 KB. Single item recovery is enabled with a 14-day deleted item retention window. The following calculations are used to determine the mailbox size:

Mailbox Size = Mailbox Limit + Whitespace + Dumpster

Whitespace = 100 messages per day x 75/1024 MB = 7.32 MB

Dumpster = (100 messages per day x 75/1024 MB * 14 days) + (2048 MB x 0.012) + (2048 MB x 0.03) = 188.6 MB

Example values for determining actual mailbox size on disk

Because this environment leverages JBOD storage, the maximum database size that can be deployed is dependent on the size of the disk. To determine the maximum database size for the JBOD scenario, use the following formula where the formatted capacity of a 1TB disk is 931 GB, the Free Space Percentage Requirement is 20 percent, and the Content Index Percentage is 10 percent:

Maximum Database Size = [Formatted Disk Capacity x (1 – Free Space Percentage Requirement)] / (1 + Content Index Percentage)

= [931 GB x (1 - .2)] / ( 1+ .10)

= 744.8 GB / 1.1

= 677 GB

In this environment, each user’s mailbox consumes 2.25 GB of disk space. To support 24,000 mailboxes, with a 677 GB database size, it's necessary to have 102 databases. This requirement results in a final count of 235 mailboxes per database.

However, because this solution is leveraging a JBOD storage architecture, it's vital to ensure that the number of mailboxes per database not exceed the amount of random I/O that can be achieved on the single disk. Because this solution is leveraging large form factor 7.2K SATA spindles, the spindle can achieve a maximum of 55 random I/O per second (IOPS) when fully utilized. Factoring in a 20 percent I/O overhead growth buffer, this means that the spindle can handle a total of 44 random IOPS.

Provided that the user base has a 100 messages per day profile, each mailbox is expected to consume 0.1 IOPS; therefore, the disk can support a maximum of 440 mailboxes with this IOPS profile. Because the capacity calculations determined that the maximum number of mailboxes that can be supported is 235 and this is below the 440 mailboxes determined based on the IOPS profile, this solution can be deployed on a single disk.

To determine the actual database size, use the following formula:

Database Size = Number of Mailboxes x Mailbox Size on Disk x Database Overhead Growth Factor

Based on the number of mailboxes, the actual size of the mailboxes, and the database growth overhead factor of 20 percent, the database size is 619 GB as shown in the following table.

Database capacity requirements

To ensure that the Mailbox server doesn't sustain any outages as a result of space allocation issues, the transaction logs also need to be sized to accommodate all of the logs that will be generated during the backup set. Provided that this architecture is leveraging the mailbox resiliency and single item recovery features as the backup architecture, the log capacity should allocate for three times the daily log generation rate in the event that a failed copy isn't repaired for three days. (Any failed copy prevents log truncation from occurring.)

A 100 messages per day profile mailbox generates 20 transaction logs per day on average, so a 24,000 mailbox environment will generate 576,000 transaction logs each day. Therefore, each database will generate 5,647 logs per day. One percent of the mailboxes are moved per week on one day (Saturday). The solution makes use of the native data protection features within Exchange and, therefore, doesn't perform backups and is sized to tolerate three days without log truncation.

As shown in the following table, this server requires 23 GB of space for each database copy.

Log capacity requirements

Provided that this is a Mailbox Resiliency and JBOD configuration with three copies, each database and its corresponding transaction logs will be placed on the same LUN. The LUN size required is:

LUN Capacity = Database Size ÷ (1 - Free Space Percentage Requirement)

= (Database Size + Transaction Log Size + Content Index Size) ÷ (1 - 0.2)

= (619 GB + 23 GB + 61.9 GB) / 0.8

= 879 GB

Determining required LUN size

Return to top

Database Copy Requirements

Provided that there are a total of 102 databases required to support 24,000 mailboxes and that each database has three copies, the DAG will support a total of 306 databases. 306 databases spread across six Mailbox servers means that each Mailbox server will house 51 database copies. The database copies should be distributed across the servers in the DAG in such a way that server level failures cause active databases to fail over to as many remaining servers as possible (database copies aren't distributed in a symmetric fashion).

To maximize the efficiency of the Mailbox servers participating in the DAG, the active databases will be equally distributed across all Mailbox servers. As a result, when all six Mailbox servers are functioning, each server should be hosting 17 active database copies.

In the event that a single Mailbox server fails, the 17 databases will be redistributed across the remaining Mailbox servers increasing the active database copy count per server to 21.

In the event that two Mailbox servers fail, the 34 databases will be redistributed across the remaining Mailbox servers, increasing the active database copy count per server to 26. It's this active copy count that will be used to size the memory and CPU requirements for the Mailbox server.

For more information about how to distribute the database copies across the Mailbox servers, see Database Copy Layout Design.

Return to top

Mailbox Memory Requirements

With a message profile of 100 messages / day, the minimum required memory per mailbox to support the database cache is 6 MB. With a worst case active mailbox database count per server being 26, each server could host a total of 6,110 live mailboxes. In addition, there are a total of 51 databases per server. The Mailbox server requires a minimum database cache of 12 GB. Therefore, the amount of memory required to support the database cache is:

Minimum Required Database Cache = MAX((Number of Live Mailboxes x Memory Required / Mailbox), Minimum Memory for Databases)

= MAX(6110 x 6/1024 GB, 12 GB)

= MAX (36 GB, 12 GB)

= 36 GB

When deploying a multi-role architecture, the total physical memory required to support this configuration is 64 GB, based on the table in Understanding the Mailbox Database Cache.

Return to top

Mailbox I/O Requirements

Each mailbox sends or receives 100 messages / day. Therefore, each mailbox has an IOPS profile of 0.1. Each database houses 235 mailboxes. Therefore, the total amount of database volume I/O is:

Database Volume I/O = Number of Mailboxes x IOPS Profile x (1 + I/O Overhead Growth Factor)

= 235 x 0.1 x 1.2

= 28.2 IOPS

The amount of database read I/O percentage for this architecture is 60 percent. Therefore, each database volume generates 16.92 IOPS of read I/O and 11.28 IOPS of write I/O.

In this architecture, each log stream generates 50 percent of the database write I/O. Therefore, the log write I/O per volume is 5.64 IOPS.

The 26 active database copies also generate log read I/O that's 10 percent of the log write I/O; therefore the log read I/O for these databases is 0.56 IOPS.

Considering each large form factor 7.2K SATA disk generates 55 random IOPS, there are no concerns that the disk can't handle the I/O requirements of the database.

Return to top

Mailbox CPU Requirements

During a double server failure event, the remaining servers each host 26 databases for a total of 6,110 active mailboxes per server. Based on the calculations found in Mailbox Server Processor Capacity Planning, each server has the following CPU megacycle requirements.

Determining CPU megacycle requirements

Provided that the chosen server platform can support a total of 26,400 megacycles, the server CPU platform can support the environment during a double server failure event.

Return to top

 © 2010 Microsoft Corporation. All rights reserved.