Making Sense of the Exchange Mailbox Server Role Requirements Calculator
The Exchange 2013 Server Role Requirements
Calculator, or storage calculator as it used to be known, is basically
a complicated Excel spreadsheet that contains the calculations
necessary to take your design requirements, and turn them into some storage-specific requirements. We
will concentrate on the interesting prediction values that emerge from
the calculator rather than on how to use it. Ross Smith IV has written
many articles on the Exchange Team Blog about using the calculator. We
strongly recommend reading some of these posts before attempting to
work with the calculator:
The Exchange 2013 Server Role Requirements Calculator can be downloaded here:
Let's begin by examining the Disk Space
Requirements table, which is on the Role Requirements tab. The Disk
Space Requirements table shows how much disk capacity the solution will
require in the database, server, DAG, and the total environment (see Figure 1).
This is very useful, since it shows us the capacity requirements for
each database plus transaction log combination for the specific user
profile and high-availability configuration specified.
In this example, you can see that for each
volume used to store a mailbox database, its transaction logs and
content index database needs to be at least 2264 GB in size to avoid
running out of disk space. This amount comprises 1510 GB for the
mailbox database and 37 GB for the transaction logs, and the rest is
needed to account for content index and sufficient volume free space to
avoid filling up the disk.
FIGURE 1 Disk Space Requirements table in the Exchange 2013 Server Role Requirements Calculator
If we move to the Host IO and Throughput Requirements table, as shown in Figure 2,
there is another deluge of interesting information. This table is of
interest to us in understanding the IOPS requirements for our storage
and the throughput requirements for background database maintenance (BDM).
FIGURE 2 Exchange 2013 Server Role Requirements Calculator IOPS and BDM requirements
The values in this
table map directly to the target values that will be required when you
learn about storage performance validation with Jetstress. Jetstress is
the tool we use to simulate an Exchange storage I/O workload to prove
that our solution is capable of meeting the demands predicted using the
Exchange 2013 Server Role Requirements Calculator.
The most important bits of information
from the Host IO and Throughput Requirements table are the Total
Database Required IOPS per database and per server plus the Background
Database Maintenance Throughput Requirements.
The Background Database Maintenance Throughput Requirements value
defines how much sequential read-only I/O will be required to support
the background checksum process. Generally speaking, if you are
deploying to direct attached storage (DAS), you do not need to consider
BDM. However, if you are deploying on SAN or iSCSI, BDM throughput may
be an issue. There are many cases where SAN storage, especially iSCSI,
can be performance-limited by the throughput requirements of BDM on
Exchange Server 2010. Exchange Server 2013 has dramatically reduced the
throughput requirements for BDM down to 1 MB/sec from 7.5 MB/sec
because of observations from the Office 365 service and the number of
CRC errors that were detected during the process. Total Database
Required IOPS per database and per server refer to the random IOPS
required for the mailbox database. It is important to note that we do
not usually consider Log IOPS when planning Exchange storage
performance, since it is entirely sequential and easy on the disk. As a
caveat to this, it is recommended that you speak with your storage
vendor, since this approach may not apply to some SAN technologies and
you will need to take their advice on IOPS performance scaling.
Nonetheless, the approach is well proven for directly attached storage
deployments.
If we look at the Volume Requirements tab,
we can see additional information about our storage requirements. This
table shows the maximum number of mailboxes per DB, DB size, DB size
plus overhead, and log size plus overhead (see Figure 3).
This is useful for determining how many mailboxes can be stored for
each database before it is considered full. It also shows how much
space should be allocated for transaction log data.
FIGURE 3 Database and LOG Configuration/Server table
On the same tab, we can see the
calculator's recommended volume layout. This shows how many databases
are recommended per volume and the capacity requirements for each (see Figure 4).
The calculator provides a recommended
layout. However, you should just view this as a starting point. The
problem with all of the values that we have accumulated up to this
point is that they are theoretical minimum values, and we need to map
them to actual physical hardware that we can buy and deploy in real
places. In most cases, the calculator does a very good job of getting
you into the right ballpark, but you will need to apply common sense to
turn the recommendation into something practical to deploy.
FIGURE 4 DB and Log Volume Design / Server table
