Exchange 2013 Sizing Cheat Sheet (Part 1)

If you would like to read the next part in this article series please go to Exchange 2013 Sizing Cheat Sheet (Part 2).

Introduction

Sizing is both a science and an art form”, so says Jeff Mealiffe in his terrific blog post Ask the Perf Guy: Sizing Exchange 2013 Deployments. Jeff reminded me of my first article on the topic of Exchange sizing, The Art and Science of Sizing Exchange 2003. The guidelines for sizing an Exchange infrastructure have evolved a lot since those early days with Exchange. Nowadays I’m not sure if it’s simpler or more complex to design an Exchange infrastructure, but one thing is for sure, we now have advanced tools like the Exchange 2013 Server Role Requirements Calculator that do all the work for us, although some basic (to say the least) understanding of the Exchange Server architecture and components is still fundamental.

Historically the guidelines provided by Microsoft come from test labs and production deployments. Recently Microsoft have begun focusing more on production environments (and keep in mind that lots of data comes from Office 365) and Dogfood. One can assume that this shift may represent better guidelines, but remember that Exchange sizing is an art and also an evolving science, and sometimes what seemed a good recommendation today may not look that good in the future, especially because users keep changing their mailbox consumption patterns (in 2003 there was no iPhone :)).

This article intends to give you a quick overview of the sizing guidelines for the different Exchange Server roles. The recommended way of correctly size Exchange Server is to use the above mentioned calculator, but I promise that if you read until the end of this article, you’ll have a better understanding of the math behind the tool.

Image
Figure 1: Exchange 2013 Server Roles

Sizing Process

A simplified Exchange design process will have, at least, these 3 major phases:

  1. Estimate/Gather/Define Requirements. Whether you’re evolving an existing infrastructure or designing a new one from scratch, you must define the baseline and the assumptions for the new Exchange architecture. This includes:
    • User profiles: gather any available data on the existing messaging deployment or estimate user profile requirements if this is a totally new solution. DO NOT GUESS USER PROFILES!
    • Organization requirements such as the desired mailbox size, service level objectives, number of sites, number of mailbox database copies, storage architecture, growth plans, deployment of 3rd party products, etc.
  2. Calculate Exchange required infrastructure. The easiest and recommended way to do this is with the calculator tool. Make several iterations with the calculator, validating some possible hardware and high-availability scenarios in order to reach one final result that makes sense to you not only from a technical, but also from a financial perspective.
  3. Solution validation. Use tools such as Jetstress to validate the storage design, and perform any other necessary pre-production lab testing to ensure that the production rollout and implementation will go smoothly.

Exchange Server 2013 Minimums

As a starting point, we can consider the very hardware minimums for Exchange Server 2013:

  • 64Bit CPU
  • 8GB RAM for MBX, 4GB for CAS, or 8GB for Multi-Role.
  • Page File = RAM + 10MB
  • 30GB Free on install drive plus 500MB for each language pack.
  • 200MB free on system drive.
  • 500MB free on queue drive.
  • Disks formatted as NTFS.

Working Example

In order to better illustrate the sizing process, let’s assume the following configuration for our future Exchange infrastructure.

  • 5,000 mailboxes
  • 200 message/day profile, with 75KB average message size
  • 10GB mailbox quota
  • Single site
  • 3 mailbox database copies, no lagged copies
  • 2U commodity server hardware platform with 12 internal drive bays
    • 2 drive RAID array for OS and Exchange binaries
    • 1 drive spare
    • 9 drives for mailbox database storage
  • 7200 RPM 4TB midline SAS disks are used
  • Mailbox databases are stored on JBOD direct attached storage, utilizing no RAID
  • 8 node DAG, support 2 node failures

Mailbox Role

User profile usually determines resource requirements, but you should take into account some factors that influence sizing, such as:

  • Number of mailboxes
  • Security/auditing mechanisms
  • Use of mobile devices
  • Outlook mode (online/cached)
  • Archiving/Messaging Record Management
  • High Availability (DAG)

DISK

The storage for the Mailbox role must be sized for

  • Capacity (GB)
  • Performance (IOPS)

To determine the actual size of a mailbox on disk, we must consider 3 factors: the mailbox storage quota, database white space, and recoverable items.

Estimated Database Whitespace per Mailbox = per-user daily message profile x average message size
= 200 x 75 = 14.65MB (in our example)

Recoverable Items Folder Size = (per-user daily message profile x average message size x deleted item retention window) + (mailbox quota size x 0.012) + (mailbox quota size x 0.03)
= (200 x 75 x 14) + (10GB x 0.012) + (10GB x 0.03) = 635.16MB (in our example)

Mailbox Size on disk = mailbox quota + database whitespace + Recoverable Items Folder

In our example, the actual size of the mailbox will be 10GB + 14.65MB + 635.16MB = 10.63GB

To calculate the total storage space required, we must use the following formula:

Total Storage = Mailbox Space + Content Indexing Space + Log Space

CONTENT INDEXING SPACE

Per-Database Content Indexing Space = database size x 0.20

Per-Volume Content Indexing Space = (average database size x (databases on the volume + 1) x 0.20)

MAILBOX SPACE

  1. Consider 5% free space per drive

Available Space (excluding required free space) = Formatted capacity of the drive x (1 – free space)

  1. Adjust the drive size to the formatted size. In our example, 4TB drives will have 3725 GB
  2. Calculate the maximum number of DBs per drive, assuming maximum size per DB < 1TB. In this example let’s assume 4 DBs per drive.
  3. Calculate the content indexing required space. The space required for content indexing will be 20% of the database size, with an additional 20% of one database for content indexing maintenance tasks.

Image

  1. Now we can remove the space for content indexing from our available space on the volume:

 Image
Image

  1. To get our maximum database size, divide the last result by the desired number of databases per disk.

Image

  1. Given this value, we can then calculate our maximum users per database (from a capacity perspective):

Image

With 9 database volumes and 4 database copies per-volume, we can have up to 36 total database copies per server.

Image

With 96 active copies and 66 users per database, we can serve a maximum of 66 x 96 = 6,336 users. Since we need only 5,000 total users, we can continue with this configuration. If the maximum users were inferior to required users, we had 2 choices:

  1. Increase the number of nodes of the DAG
  2. Increase the number of disk volumes per server. Keep in mind that each Exchange server is limited to 100 databases.

With 66 users per-database, that means we will expect to consume the following space for mailbox databases:

Estimated Database Size = 66 users x 10.63GB = 701.58GB
Database Consumption / Volume = 701.58GB x 4 databases = 2806.32GB

Using the formula mentioned earlier, we can compute our estimated content index consumption as well:

701.58GB database size x (4 databases + 1) x 0.20 = 701.58GB

LOG SPACE

To calculate Log Space, use the following table:

Message profile (75 KB average message size) Number of transaction logs generated per day
50 10
100 20
150 30
200 40
250 50
300 60
350 70
400 80
450 90
500 100

Table 1

Log Capacity to Support 3 Days of Truncation Failure = (65 mailboxes/database x 40 logs/day x 1MB log size) x 3 days = 7.62GB

Log Capacity to Support 1% mailbox moves per week = 66 mailboxes/database x 0.01 x 10.63GB mailbox size = 7.02GB

Total Local Capacity Required per Database = 7.62GB + 7.02GB = 14.64GB

Log Space required / Volume = 14.64GB x 4 databases = 58.56GB

TOTAL STORAGE SPACE

Total Storage = Mailbox Space + Content Indexing Space + Log Space

= 2806.32GB + 701.58GB + 58.56GB = 3566.46GB

Since we have a total of 5000 users, and each DB has 66 users, we’ll need 76 mailbox DB. As we have 3 copies, the total DB in the DAG will be 76 x 3 = 228. Since we sized each disk volume to have 4 DB, we need a total of 228 / 4 = 57 disk volumes.

The total used storage will be 57 x 3566.46GB = 198.52TB.

IOPS

Messages   sent or received per mailbox per day Estimated   IOPS per mailbox (Active or Passive)
50 0.034
100 0.067
150 0.101
200 0.134
250 0.168
300 0.201
350 0.235
400 0.268
450 0.302
500 0.335

Table 2

Using our example:

66 mailboxes x 4 databases per-drive x 0.134 IOPS/mailbox at 200 messages/day profile = 35.38 IOPS per drive

CPU

  • Estimated Per-Mailbox CPU Consumption:
Messages   sent or received per mailbox per day Mcycles   per User, Active DB Copy or Standalone (MBX only) Mcycles per User, Passive DB Copy
50 2.13 0.69
100 4.25 1.37
150 6.38 2.06
200 8.50 2.74
250 10.63 3.43
300 12.75 4.11
350 14.88 4.80
400 17.00 5.48
450 19.13 6.17
500 21.25 6.85

Table 3

Note:
Baseline platform for CPU guidance changed in 2013. Mcycle requirements in 2010 and 2013 cannot be directly compared.

Continuing with our example, the high availability requirements for the design of the 5,000 user example resulted in a total of 76 DBs, divided by 6 nodes (2 node failures), meaning we’ll have a maximum of 13 active databases at any time out of 29 total database copies per server (228 / 8), and we know that there are 66 users per database, we can determine the per-server CPU requirements for the deployment.

(13 databases x 66 mailboxes x 8.5 mcycles per active mailbox) + (16 databases x 66 mailboxes x 2.74 mcycles per passive mailbox) = 7293 + 2893.44 = 10,186.44 mcycles per server

  1. Find the SPECint_rate2006 score for the processor that you intend to use for your Exchange solution.
    • On the website of the Standard Performance Evaluation Corporation, select Results, highlight CPU2006, and select Search all SPECint_rate2006 results.
    • Under Simple Request, enter the search criteria for your target processor, for example Processor Matches E5-2630.
    • Find the server and processor configuration you are interested in using (or if the exact combination is not available, find something as close as possible) and note the value in the Result column and the value in the # Cores column.
  1. Obtain the per-core SPECint_rate2006 score by dividing the value in the Result column by the value in the #      Cores column.
  2. To determine the estimated available Exchange workload megacycles on the target platform, use the following formula:

 Image

  1. Make sure the maximum CPU utilization doesn’t go above 80%.

Note:
TURN OFF HYPERTHREADING: It can have significant impact to some Exchange service memory footprints.

Memory

  • The minimum memory should be always 8GB
  • Use the following case to calculate the total memory per server
Messages sent or received per mailbox   per day Mailbox role memory per active mailbox   (MB)
50 12
100 24
150 36
200 48
250 60
300 72
350 84
400 96
450 108
500 120

Table 4

Mailbox Memory per-server = (worst-case active database copies per-server x users per-database x memory per-active mailbox)

Per-server   DB copies Minimum   physical memory (GB)
1-10 8
11-20 10
21-30 12
31-40 14
41-50 16

Table 5

In our example, since we have a maximum of 13 active database copies per server, the necessary memory will be 13 x 48MB x 66 = 40,2GB (round up to 48GB).

Network

  • 1 x Gbit minimum
  • DAG – each server should have at least two networks: a single MAPI network and a single Replication network.

Summary

This concludes part 1 of the Exchange 2013 Sizing Cheat Sheet. On the next and final part, we’ll cover the remaining Exchange 2013 roles: CAS and Edge.

If you would like to read the next part in this article series please go to Exchange 2013 Sizing Cheat Sheet (Part 2).

About The Author

1 thought on “Exchange 2013 Sizing Cheat Sheet (Part 1)”

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top