With the release of Exchange Server 2016 it’s time for on-premises customers to consider their upgrade options. Which means that it’s also a good time to review their Exchange storage strategy.
Since the days of Exchange Server 2010 the storage performance requirements for Exchange have decreased, which is a good thing. Exchange 2010 required far fewer IOPS for a given mailbox count than Exchange 2007 or 2003 did, and Exchange 2013 improved on this even further.
For Exchange 2016 we again see improvements in the storage engine, driving down the IOPS requirements. The development goal is to make it as cheap as possible to run an Exchange server with large mailboxes, and therefore a large overall storage footprint, by making Exchange databases run well on slower, lower cost disks. On-premises customers benefit from this, as does Microsoft in Exchange Online.
This means that deploying Exchange with expensive, high performance SAN storage is no longer required. Microsoft’s Preferred Architecture document reinforces this, as does their experience with running Exchange Online.
But does that mean the days of Exchange running on SAN are behind us? No, it doesn’t.
Storage vendors would like to say that the reason Exchange should still be deployed on SAN is because of the great features that a SAN can bring to the table, such as hardware-based replication, backup, or recovery. Most SANs boast features that look great on marketing slides, and are helpful for many applications. They just aren’t required for Exchange, and in some cases can be detrimental to Exchange.
None of that makes a big difference to most customers though. The real reasons for deploying Exchange on SAN are usually around standardisation, and leveraging existing investments. When a SAN already exists, has a proven track record of performance, and has mature operational procedures established, many organizations will prefer to simply expand the available capacity of the SAN rather than invest in a new storage type for one application.
A key driver of SAN use is virtualization, and virtualization is a popular way of deploying Exchange on-premises, despite the Preferred Architecture recommending physical server deployments. Even customers that I speak with who use the Preferred Architecture as the basis for their design tend to deviate from that guidance in three areas; virtualization, storage, and backups.
But those are customers who are deploying a highly available, site resilient Exchange environment. A lot of customers I encounter are deploying a single Exchange server. Even though Office 365 offers a compelling alternative to a single-server on-premises deployment, many customers simply aren't quite ready to move to the cloud yet. The reasons may be technical, such as bandwidth issues, or they may be policy related, such as regulatory compliance issues. Sometimes, it's just an emotional decision, with the decision makers not "feeling" ready for the cloud.
What I'm seeing in the market clearly indicates that running Exchange on SAN is not going to disappear any time soon. Whatever the reason, customers running a simple on-premises Exchange deployment usually prefer to fit that server into their existing, standard platform of virtualization and SAN. The larger impact on Exchange deployments on SAN is going to be from adoption of Office 365 and other cloud services. As long as Exchange is being deployed on-premises, we’re going to continue to see it deployed on SANs.