Designing storage for Exchange
We already talked about storage environments and how they relate to the new Exchange Server 2013 architecture possibilities.
Due to the optimized and redesigned mailbox store architecture, the Input/Output Operations per Second (IOPS) required for running your Exchange environment decreased dramatically, which lead to possible redesign of your storage infrastructure, or at least consideration of it.
Getting ready
To complete the following steps outlined, make sure to review and understand storage-related terminology. Also, now would be a good time to check whether virtualization is a requirement or an option. Many companies already have some sort of storage solution they want to re-use, but that doesn't necessarily mean it's the best fit for your Exchange environment.
How to do it...
As it is impossible to give you a complete overview of all supported Exchange Server storage vendors, we decided to give you a bullet list of storage considerations in the Exchange Server 2013 context. These guidelines can help you evaluating the right storage solution.
Exchange Server 2013 supports about any type of storage architecture, including Direct Attached Storage (DAS) or Storage Area Network (SAN)—iSCSI or Fiber Channel based.
Only block-level storage is supported. This means that you can use NAS/SAN storage as long as it's either a direct drive mapping or an iSCSI LUN. NFS nor virtual disks stored on an NFS volume, that present block-level storage to Exchange are supported.
All currently existing physical disk types are supported for Exchange Server 2013, ranging from SATA, SAS, and Fiber Channel to SSD disks. Key things to watch out for are disk rotation speed and size. Disks with 5400 RPM are considered too slow in performance, so we don't suggest using these in production environments. Any 7200 RPM or 10,000 RPM disk should score well in both sizing and performance.
Of course, 15,000 RPM disks are also an option. However when it comes to comparing cost versus benefits, they might not be the best fit.
Exchange 2013 supports multiple RAID levels, depending on the usage. They are as follows:
RAID 1/10 are recommended for system partition and log files.
RAID 1/5/10 are recommended for database files volumes.
RAID 1/5/10 are recommended for database log files volumes, although RAID 0 gives better performance, but no redundancy on storage level.
JBOD (disk set without RAID) which is also supported for both database and log files volumes. It should only be considered in a high availability architecture, having three or more database copies!
Exchange 2013 supports databases up to 2 TB. There is no one-size-fits-all approach. Generally though, it's recommended to keep database sizes to a size which your environment can handle. This is mainly a best practice out of backup/restore and RTO perspective. Imagine needing to perform a restore of a 2 TB Exchange database, when you only have it stored on tape….
How it works...
It is impossible to give you a single answer on how to size and design your Exchange 2013 storage environment. Besides the guidelines we just read, the key on which to base your sizing are IOPS calculations. IOPS is commonly used to reference the performance storage devices, such as hard drives, solid state drives, and SANs.
Microsoft has made tremendous updates to the Exchange database design, resulting in a serious decrease of the required amount of disk IOPS. This is a good thing because disks are growing larger in disk size, but the IOPS they can handle have remained pretty steady over time. So the ideal goal is knowing your Exchange user profile, corresponding IOPS needed, and verifying what IOPS can be delivered by your storage platform.
For each Exchange Server edition since 2003, the Exchange product team provided a Mailbox Server Role Requirements Calculator, which could help with determining the storage requirements so you could match the correct solutions to it. Since the beginning of May 2013 (about 8 months after Exchange 2013 release date though), the calculator for Exchange Server 2013 is (finally) available.
The Exchange 2013 calculator can be downloaded from Microsoft through the following website:
Besides the Microsoft calculator, a lot of storage vendors also provide tools and whitepapers which describe to you best practices, calculated scenarios, and recommended sizing based on their own storage solutions.
To streamline the process of calculating, Microsoft created the Exchange 2010 Solution Reviewed Program (ESRP)—Storage 3.0, which is a toolset of testing parameters (JetStress tests) and documentation guidelines that storage vendors can use for getting their storage solution certified for Exchange Server. This program has recently been upgraded to reflect Exchange 2013 sizing as well.
All information on the ESRP and the different vendor's results can be found at the following website:
There's more...
The last thing you would want to do is put a storage system into production that doesn't meet the bar when it comes to the amount of IOPS. Storage vendors sometimes try to hide weaknesses or make their solution look better by tweaking some of the numbers or even the results from different tests. Therefore, you should always validate that the solution you chose meets the required amount of IOPS.
A good way to do this is to use the JetStress utility that Microsoft provides. As a matter of fact, running JetStress is also a requirement if you want your storage solution to be fully supported by Microsoft. This doesn't mean they will help you set up the solution, but in case of problems, support might ask for proof that it meets the requirements of your environment.
Because typical JetStress tests can take a while, people often skip them. You shouldn't.
Neil Johnson, a MCS Consultant based in the UK, has created the JetStress field guide for Exchange 2013 which has been released only recently. It is the starting point to understand what JetStress does and how to use it to validate your storage for Exchange 2013.
You can download the guide from the following webpage:
The way JetStress works is that it will simulate the typical load generated by an Exchange server, based on what parameters you provide to it. It will then monitor the transactions and based on that, return a Pass or Fail for configuring along with additional information that can help you understand why it passed or failed.
While running the JetStress tests, it's also a good idea to simulate a failure in your storage system. If you are using a RAID array, you might want to see what the impact of a rebuild would be on the result of JetStress. If you're running JetStress in a virtualized environment, don't wait until off-business hours to run the test, do it during the day to have more reliable results. After all, you will be running Exchange during business hours, won't you?
