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 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.
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.
Storage selection and planning
When choosing disk types and storage for your environment, Microsoft provides a list of supported products and best practice recommendations on TechNet.
To calculate your storage needs, the Exchange 2010 Mailbox Role Requirements calculator can help you collect criteria and design a solid architecture. The calculator is not a requirement for Microsoft support.
For additional information from Microsoft storage partners, visit the Exchange Solution Reviewed Program (ESRP) -- Storage.
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 firstname.lastname@example.org.