Accepting Exchange 2010 storage redesigns
Over the past decade, storage area network (SAN) products with Fibre Channel switches and
cabling have had network administrators drooling.
But times are changing. A new, more cost-conscious economy has Exchange Server admins looking at cheaper disk options that can still maintain
performance. This shift means that IT teams must be re-educated on which applications are
supported, what kind of performance to expect and which best practices should be put in place.
Supported storage architectures
First and foremost, Exchange Server 2010 doesn’t
When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by Exchange professionals today working with Exchange, Outlook and other related technologies.
Margie Semilof, Editorial Director
Premium Access
Register now for unlimited access to our premium content across our network of over 70 information Technology web sites.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy
Dig Deeper
-
People who read this also read...
This was first published in April 2011
support the network-area storage (NAS); however,
the server does support Fibre Channel (FC) SANs and iSCSI SANs, as well as direct-attached storage
(DAS) using SAS or SATA-class disks. And although Exchange 2010 supports the more expensive storage
options, it was designed specifically to work with lower cost RAID and RAID-less
JBODs.
Obviously, each enterprise has its own needs, but the Microsoft Exchange team notes that all
organizations have “the ability to deploy large mailboxes at low cost” because of the company’s
focus on compatibility with more cost-effective disk products. This is evidenced in Exchange 2010,
which Microsoft implemented with JBOD storage arrays (Figure 1). The architecture for JBOD uses
fewer disks than other storage arrays, and those disks -- either SATA or SAS -- are cheaper than
same-capacity disks for an FC array.
Figure 1. Architecture for Exchange Server 2010 JBOD storage arrays.
Skeptics may argue that you get what you pay for and you should expect more errors and storage
failure-rate increases when using cheaper disk. Typically, this belief is accurate, but design
improvements over the years to traditional storage make it surprising to see a lower failure rate
than anticipated.
So long, Single Instance Storage
Single Instance Storage (SIS) is as old as Exchange Server itself. It was
designed into the server to reduce the amount of disk space needed to store messages at a time when
disk capacity was at a premium.
Exchange’s database table structure has remained unchanged for 20 years, and so did SIS.
However, advancements in Exchange transport -- with features like cached Exchange mode and an
increase in the number of databases you can deploy -- has reduced the effects of SIS.
In order to take Exchange 2010 to the next level, the development team looked at the inexpensive
price tag associated with relatively high-performance, high-capacity disks. Microsoft wanted to
leverage those disks by allowing for larger mailboxes as well as a personal archive that admins to
finally eliminate .pst file use.
To achieve these goals, Microsoft discovered that a new structure that focused less on the
database and more on the mailbox itself would be a better approach. It also decided the time had
come to remove SIS, as it was delaying other storage changes.
“In order to improve the store and ESE [Extensible Storage Engine], to change our IO profile
(from many, small, random IOs to larger, fewer, more sequential IOs) and to resolve our
inefficiencies around item count, [Microsoft] had to change the store schema,” said Ross Smith IV,
a member of the Exchange Customer Experience Team in a blog post. “Specifically, we moved away from
a per-database table structure to a per-mailbox table structure. This architecture, along with
other changes to the ESE and store engines (lazy view updates, space hints, page size increase, b+
tree defrag, etc.), netted us not only a 70% reduction in IO over Exchange 2007, but also
substantially increased our ability to store more items in critical path folders.”
Seventy percent improvement is unbelievable, especially considering the advances Exchange 2007 had over Exchange 2003. What does this all mean? Cheaper storage can be leveraged for
the equivalent, or near equivalent, performance of storage with a higher price tag in Exchange
2007.
But the announcement about the removal of SIS sparked some controversy among Exchange admins. To
combat some of the bloating that occurs without SIS, a targeted compression mechanism was
implemented; however, it only compresses message headers and bodies that are either text or
HTML-based. In truth, this “solution” can actually lead to some pretty heavy bloating. Take, for
example, an email message with a 10 MB attachment that will be sent to 20 people. In actuality,
that one message takes up 200 MB of space, instead of the 10 MB consumed if Exchange used SIS.
There are circumstances where the new compression cannot contain the bloat; Microsoft recommends
that you establish reasonable attachment size restrictions and work extensively with Exchange
2010’s built-in retention policy settings -- Messaging Records Management (MRM) 2.0 with retention policies and tags.
Embracing change in your Exchange environment
Change is difficult. Exchange admins will need to accept the fact that, with Exchange 2010, cheaper
disks are better, larger mailbox sizes are acceptable and the loss of SIS is a good thing. How?
Start small.
First introduce the use of the personal archive feature with retention policies and tags; this
will help you avoid mailbox bloat that occurs as a result of removing SIS. Then start to eradicate
.pst files completely. Exchange Server 2010 Service Pack 1 (SP1) allows you to keep archive mailboxes on a separate database from the production mailbox
database. This means you can use low-cost disks for the archive while still holding onto expensive
SANs for production databases.
ABOUT THE AUTHOR:
J. Peter Bruzzese (Exchange MVP, Triple-MCSE, MCT, MCITP: Enterprise Messaging) has been
working with Exchange for 10+ years. He has recently released several Exchange video series
for Train Signal and can be reached at peter@trainsignal.com.
Disclaimer:
Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
