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

Topic Last Modified: 2012-07-23

We recommend breaking the storage design process into three steps. The following sections provide detailed information about each of the design steps, including mailbox storage requirements and best practices.

Step 1: Gather Storage Input Requirements

Several Exchange 2010 architectural factors influence mailbox storage design. The following table lists the most important factors that affect mailbox storage design.

Architectural factors in mailbox storage design

Design factor Description Storage design impact

Mailbox count

The maximum number of mailboxes targeted to be hosted on a specific Mailbox server.

Performance   More mailboxes equal more messages delivered and opened per server. This generates more log and database I/O.

Capacity   More mailboxes equal more capacity to store mailbox content. This affects the number of databases and size of databases per server. More mailboxes also equal more logs generated per server per day.

Reliability   In general, the more mailboxes hosted on the Mailbox server, the greater the need for high availability.

Mailbox concurrency

The percentage of users that connect to the Mailbox server at the same time measured over a one hour period.

Performance   Higher concurrency equals more messages delivered and opened per server. This generates more log and database I/O. In general, 100 percent concurrency is used for standard information worker storage sizing.

Capacity   Higher concurrency equals more logs generated per server per day.

Mailbox size

The maximum mailbox quota per mailbox, for example, maximum mailbox size equals 10 GB. This includes capacity required for the primary mailbox, personal archive, and recoverable items (dumpster) data.

Performance   Larger primary mailboxes equal more content to process for infrequent database operations, for example, full Microsoft Outlook offline folder files (.ost) sync and new view creation in Microsoft Office Outlook Web App. This can generate slightly more log and database I/O.

Capacity   Larger mailboxes equal more capacity to store mailbox content. This affects the number of databases and size of databases per server.

Mailbox usage profile

The usage characteristics of users on the Mailbox servers, generally defined as messages sent and received per day and average message size in kilobytes (KB).

Performance   The more intensive the mailbox usage profile, the more log and database I/O that can be generated.

Capacity   A more intensive mailbox usage profile equals more logs generated per server per day.

E-mail client types

The types and percentages of different e-mail clients, for example, Outlook 2003 Cached Exchange Mode, Windows Mobile, Microsoft Exchange ActiveSync, and Microsoft Office Outlook Web App.

Performance   Different clients exhibit different performance characteristics on the server.

E-mail client extensions

Microsoft and third-party applications that extend the functionality of the e-mail client, for example, Office Communicator and Windows Desktop Search clients.

Performance   Depending upon implementation, e-mail client extension applications can have a light to very heavy I/O impact on the Mailbox server database I/O.

Server applications

Applications that either run on or against Exchange Mailbox servers, for example, third-party mobile device applications and antivirus applications.

Performance   Depending on implementation, server applications can have a light to very heavy I/O impact on Mailbox server database I/O.

High availability requirements

Whether Exchange 2010 high availability is used and how it's configured, for example, number of copies, number of sites, and lagged copies.

Performance   High availability solutions may require slightly more I/O than non-high availability solutions to handle the additional log volume I/O produced by log replication.

Capacity   Using high availability increases the amount of database file storage required (depending upon the number of copies). If circular logging is used, log capacity may be reduced. Using high availability equals more logs generated per server per day.

Reliability   Deploying high availability increases the viable number of storage options. Less reliable storage, storage without RAID or just a bunch of disks (JBOD), may be used when multiple database copies are used in a high availability deployment.

For more information about the features mentioned in the preceding table, see the following topics:

Step 2: Design Storage Architecture Based on I/O and Capacity Requirements

After you've completed gathering the Exchange 2010 storage input requirements, you need to design your storage architecture based on I/O and capacity requirements. There are several ways to configure your storage architecture. You can calculate the requirements for the storage architecture manually, or you can use the Exchange 2010 Mailbox Server Role Requirements Calculator. Calculating your requirements manually requires a deeper understanding of mailbox storage design, which is provided by the topics listed in "Calculate the Mailbox Server Role Requirements Manually" later in this topic. When you use the Mailbox Server Role Calculator, it allows you to input your information, and then it provides a recommended best practice for your design.

Calculate the Mailbox Server Role Requirements Manually

Complete the following steps to derive your Mailbox server role architecture:

  1. To determine your high availability model, see Understanding High Availability Factors.

  2. To calculate your database and log capacity requirements, see Understanding Mailbox Database and Log Capacity Factors.

  3. To determine your memory requirements, see Understanding the Mailbox Database Cache.

  4. To calculate your database and log performance requirements, see Understanding Database and Log Performance Factors.

  5. To determine your logical unit number (LUN) architecture based on your requirements, see Understanding Exchange 2010 LUN Architecture.

  6. To determine your storage architecture based on your requirements, see Understanding Storage Configuration.

  7. To determine your CPU requirements, see Mailbox Server Processor Capacity Planning.

To see how all this information comes together, review Exchange 2010 Mailbox Server Role Design Example.

Use the Mailbox Server Role Requirements Calculator

The Exchange 2010 Mailbox Server Role Requirements Calculator enables you to determine your requirements for the Mailbox server role by specifying a set of input factors. The calculator can determine the requirements for memory, storage (I/O performance, capacity, and storage configuration), optimal LUN layout, and CPU megacycles. Many variables need to be accounted for before you can design an optimal solution for an Exchange 2010 Mailbox server, and the calculator can help you in your design process. For more information about the calculator (and to download the calculator), see the Exchange Server Team Blog article Exchange 2010 Mailbox Server Role Requirements Calculator.

Note:
The content of each blog and its URL are subject to change without notice. The content within each blog is provided "AS IS" with no warranties, and confers no rights. Use of included script samples or code is subject to the terms specified in the Microsoft Terms of Use.

Step 3: Validate Storage for Performance and Reliability

Before implementing a storage solution in a production environment, it's important that you validate that the solution is configured correctly. This section provides guidance for successfully testing a storage solution for Exchange, beginning with a program that includes solutions that have already been tested.

In addition, you'll find information about several tools that can help you manage, test, and monitor your storage solution. For more information about understanding and troubleshooting I/O performance, see Understanding Database and Log Performance Factors.

Exchange Solution Reviewed Program

When selecting a storage solution, we recommend you choose a solution that has been reviewed by the Microsoft Exchange Solution Reviewed Program (ESRP) for storage, known as ESRP-Storage. ESRP-Storage is an Exchange-specific test, best practices publication framework, and review process to facilitate the creation of known, good Exchange storage solutions. The goals of ESRP-Storage are to:

  • Provide storage vendors with prescriptive guidance about Exchange storage testing and best practices publication.

  • Develop a mechanism to review storage solutions to make sure that they meet Exchange best practices.

  • Provide customers with well-tested and high-quality storage solutions targeted for Exchange deployments.

For more information, see Microsoft Exchange Solution Reviewed Program (ESRP).

Note:
ESRP-Storage isn't a Microsoft certification, qualification, or logo program.

Because storage can be configured in many ways, evaluating tested configurations and using best practices can reduce costs and decrease the time to deployment.

Storage Testing

Before testing a solution, some work is required to understand what it is you're trying to achieve by testing. Some of the keys to successful storage testing include:

  • Determine testing goals. For example, consider the performance, throughput, and capacity numbers needed.

  • Test with as many servers attached to the storage as you will have in production. This includes non-Exchange servers and workloads.

  • Test with production-size databases with the physical disk capacities filled to production level. Most physical disk performance characteristics will change based on the data set size.

  • Determine that storage meets the transactional I/O requirements, and determine the maximum performance of the solution within acceptable latencies.

  • Determine that storage meets the backup throughput and performance requirements to meet your backup and restore service level agreement (SLA).

Storage-Related Tools

The Microsoft Exchange Server Jetstress tool accurately simulates Exchange I/O characteristics. It includes both a stress test and a performance test, which show the maximum performance of a LUN within acceptable latencies. The Exchange Load Generator simulates Microsoft Office Outlook clients.

Both tools simulate Outlook. Simulating Outlook clients is the only way to measure actual client latency (rather than just the server disk latency). For more information about these tools, including how to download them, see Tools for Performance and Scalability Evaluation.

Important:
The Exchange Jetstress tool should be used on systems prior to placing production data on the server. Jetstress shouldn't be used on systems containing production data.
Important:
The Exchange Load Generator is intended for use in test environments, not in production environments.

Monitoring Server Storage Health

Monitoring your storage solution is critical in identifying hardware and software warnings and error conditions before they lead to data corruption or downtime.

The following tools can help monitor your storage solution. These tools are available in the Toolbox node of the Exchange Management Console:

  • Best Practices Analyzer Tool

  • Performance Monitor

  • Performance Troubleshooter

In addition, you can also use Microsoft System Center Operations Manager 2007 to monitor your storage solution, as well as several other aspects of your Exchange organization.

Performance Monitor (perfmon.exe) is the Microsoft Management Console (MMC) performance snap-in for Exchange 2010. Perfmon, which uses the MSExchangeIS performance object to retrieve counter information, provides information that allows you to gauge the health of your storage solution. For more information, see Performance and Scalability Counters and Thresholds.

Monitoring Storage Solution Health

On many storage solutions, there's a way to see performance metrics. Monitoring these metrics can catch performance issues before they affect Exchange. If available, System Center Operations Manager 2007 integration from the storage vendor can assist in making sometimes proprietary metrics easy to understand. Some of the general metrics to watch include:

  • Disk Utilization Percentage   How busy are the physical disks?

  • Read Cache Hit Ratio   How well is the storage controller cache being utilized?

  • Write Pending Requests   How often is the controller waiting for the physical disk?

  • Storage Processor Utilization Percentage   How busy is the storage controller processor?