This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - Step 3: Keep the Exchange 2013 migration process smooth: Read more in this section
- How will server roles changes affect a migration to Exchange 2013?
- Checklist prepares you for an Exchange 2013 migration
- Complete these four essential tasks before the migration
- Five gotchas when migrating to Exchange 2013
- Why is a required coexistence period necessary in an Exchange migration?
- Don't forget mailbox database size when planning for storage
Explore other sections in this guide:
- 1. - Step 1: Confirm that a move to Exchange 2013 is the right decision
- 2. - Step 2: Look at the features that will be most helpful
Planning storage architecture for Exchange Server 2013 is something of an art form. Your storage architecture impacts everything -- performance, scalability and reliability. So it's worth taking some time to examine your options for Exchange mailbox databases and Microsoft's storage recommendations.
The key to achieving the best possible performance and reliability is to isolate the Exchange Server data types from each other. At a bare minimum, you should have a volume dedicated to storing the Windows operating system without Exchange Server binaries, a volume for Exchange Server databases and a volume for the transaction logs supporting those databases.
You might also consider using a dedicated volume for the server's page file or volumes for each Exchange Server database.
Database sizing for Exchange 2013
Exchange Server 2013 makes it possible to create large mailbox databases. The maximum Exchange mailbox database size you can create is at least 2 TB, but some Microsoft documentation actually has a 16 TB limit. In any case, allowing Exchange Server databases to reach multiple terabyte sizes is generally not recommended.
Even though Exchange Server 2013 is perfectly capable of creating and running multi-terabyte databases, using excessively large databases can negatively affect things like backup, recovery, replication (especially with regard to the initial seeding) and general database maintenance. It's best to limit the maximum size of an Exchange mailbox database to about 200 GB whenever possible.
The maximum number of databases a single Exchange 2013 server can accommodate decreased from Exchange Server 2010. Exchange Server 2010 Enterprise Edition allowed up to 100 databases, but this limit decreased to 50 databases with Exchange Server 2013.
DAGs and database replication
The primary fault-tolerant mechanism in Exchange Server 2013 is Database Availability Groups (DAGs), which replicate mailbox database copies across multiple mailbox servers.
Although DAGs are straightforward, there is one storage-related aspect to the replication process that's easy to overlook. Exchange Server databases are optimized based on the underlying disk structure. As such, Microsoft doesn't support copying databases from one disk type to another. For example, if a database is stored on a disk that uses 512 byte sectors, then that database shouldn't be replicated to a disk that uses four KB sectors.
What about RAID configurations?
When it comes to database volumes, the best practices for RAID array configurations depend on many factors, including the size of the deployment and whether the database is being replicated.
For a small Exchange deployment with non-replicated databases, it's generally recommended to protect your database volume with RAID 5. A RAID 5 array should include no more than seven disks; performance may diminish if you add additional disks because of the overhead in maintaining parity information for the array.
Medium-sized Exchange deployments with non-replicated databases should consider using either RAID 0+1 or RAID 6 to protect database volumes. These RAID configurations are also an option for smaller organizations, but the cost can sometimes be a deterrent.
Larger organizations that take full advantage of DAGs may not need to worry about implementing fault-tolerant RAID configurations. Such organizations can get away with using "just a bunch of disks" (JBOD) storage as long as there are a sufficient number of database copies to protect the organization against potential disk failures. If you're considering JBOD storage, you should have no fewer than three database copies and two lagged copies.
Disk partitioning using GUID Partition Table in Exchange 2013
When provisioning disks for Exchange 2013 databases, Microsoft recommends you use GUID Partition Table partitioning because it supports larger sizes than are possible using Master Boot Record partitions. Any volumes that will store Exchange mailbox databases must be formatted with NTFS; an allocation unit size of 64 KB is recommended. Avoid using operating system features such as NTFS encryption, defragmentation or deduplication on volumes containing Exchange databases. BitLocker encryption is supported for Exchange Server use, but it tends to work best when used with non-clustered mailbox servers.
There are a number of considerations when provisioning Exchange Server storage. The Exchange Server 2013 Server Role Requirements Calculator can help you to ensure that your storage option adheres to Microsoft's latest best practices.
About the author
Brien Posey is a ten-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a chief information officer at a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation's largest insurance companies and for the Department of Defense at Fort Knox.