Table 1 outlines some of the most interesting changes in Exchange 2013 that have an impact on storage.
TABLE 1: Storage enhancements in Exchange Server 2013
One of the interesting trends in Exchange
Server 2010 and Exchange Server 2013 is that the Exchange product group
will trade CPU utilization if it buys a reduction or smoothes out
random disk I/O. This approach makes sense as we consider the hardware
growth prediction during the Exchange Server 2013 life cycle. Moore's
Law states that transistor densities double about
every two years. This growth rate is expected to taper off to a
doubling of transistor density every three years starting at the end of
2013. Regardless, the industry expects that available processor power
will continue to rise, whereas mechanical disk random IOPS performance
is expected to remain static. Exchange Server 2013 is designed to take
best advantage of both the hardware resources currently available and
those that are projected to be available during the life cycle of the
product.
Exchange 2013 reduces IOPS by roughly 45
percent over Exchange Server 2010. If we consider active mailboxes
only, Exchange Server 2010 required 0.0012 × user profile compared to
Exchange Server 2013 requiring 0.00067 × user profile. If we plug in
numbers for 100 messages sent and received per mailbox/per day/per user
profile, this means that if the mailbox was hosted on Exchange Server
2010, it would require 0.12 IOPS/mailbox. But on Exchange Server 2013,
it would need only 0.067 IOPS/mailbox.
Automatic Database Reseed
This is the single most important change in
Exchange Server 2013. Quite simply, automatic database reseed makes
deploying a JBOD storage solution viable for many organizations that
found JBOD too difficult to manage in Exchange Server 2010.
The fundamental idea behind automatic database reseed
is that you allocate more disk spindles to each DAG node than you
require for your active and passive databases. The additional spindles
are formatted and mounted, but they are not used to store database or
logs. In the event of the failure of a disk spindle that is being used
for an active or passive database copy, Exchange will make use of the
“spare” disk spindles and automatically perform the necessary database
reseed operation.
So why is automatic database reseed better
than RAID? JBOD plus AutoReseed requires fewer disks than RAID 10 and
does not suffer from the same level of performance degradation inherent
in RAID 5 during rebuild. It also doesn't require the same level of
operational maturity to maintain data availability.
Multiple Databases for Each JBOD Disk Spindle
The change allowing multiple databases for each
JBOD disk spindle was necessary to permit the use of larger disk
capacities without increasing the maximum mailbox database size above 2
TB. This change is often confused with storing multiple databases per
volume but it is subtly different. What this change actually means is
that in Exchange Server 2013, there exists the ability to store
multiple mailbox databases on a single JBOD spindle, that is, a single
disk spindle presented to the server. We have always been able to store
multiple databases on a RAID array, but storing multiple databases on a
JBOD spindle was previously not supported.
Seemingly, this change is simple to
understand since it gives us the ability to store multiple databases on
each spindle. This lets us retain the 2 TB maximum recommended mailbox
database limit yet still takes advantage of larger-capacity disk
spindles. However, this represents only half of the benefit of this
change. The other half is that, when we reseed the disk spindle, we may
potentially have multiple JBOD disk spindles participating in the
reseed operation. Testing so far with Exchange Server 2013 suggests
that a single spindle reseed operation, like those that already exist
in Exchange Server 2010, runs at around 20 MB/sec. Testing with
Exchange Server 2013 and multiple databases for each spindle shows that
the reseed operation runs at around 20 MB/sec per spindle used in the
reseed operation. For example, if a spindle stored two database copies and
the alternate copies of those databases were on different spindles, the
reseed operation would take place at around 2 × 20 MB/sec = 40 MB/sec. Figure 1 shows you potentially how to store four databases for each disk spindle with a JBOD deployment in Exchange Server 2013.
FIGURE 1 Multiple databases for each JBOD spindle layout
Now let's examine the reseed scenario
where we have lost the JBOD disk spindle in Server 1. In this case,
active workload for DB1, as shown in Figure 1,
has been moved to Server 2. All of the remaining workload has stayed in
place. The disk in Server 1 has been replaced, and all databases are
now being reseeded from the active copy, as shown in Figure 2.
FIGURE 2 Multiple databases for each JBOD spindle reseed
Testing shows that, for each reseed
operation per source spindle, we can expect around 20 MB/sec
performance. Where we have multiple reseed operations for each spindle,
we can get around 24 MB/sec performance in total for that spindle.
Let's see what this data yields for approximate reseed times.
Exchange Server 2010 (single DB/spindle)
- 2 TB data = ~29 hours
- 8 TB data = ~116 hours
Exchange Server 2013 (four DBs/spindle)
- 2 TB data = ~9.1 hours
- 8 TB data = ~36 hours
When we combine the reseed performance
benefit with being able to make use of larger disk spindle capacities
and automatic database reseed, it makes JBOD in Exchange Server 2013 a
compelling proposition from a cost/simplicity perspective and also from
an operational perspective. Thus, it is a win/win scenario.
