Mailbox Storage Design Process
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
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:
To determine your high availability model, see Understanding High Availability Factors.
To calculate your database and log capacity requirements, see Understanding Mailbox Database and Log Capacity Factors.
To determine your memory requirements, see Understanding the Mailbox Database Cache.
To calculate your database and log performance requirements, see Understanding Database and Log Performance Factors.
To determine your logical unit number (LUN) architecture based on your requirements, see Understanding Exchange 2010 LUN Architecture.
To determine your storage architecture based on your requirements, see Understanding Storage Configuration.
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?
© 2010 Microsoft Corporation. All rights reserved.