Everyone's entitled to their view of what really matters in terms of hardware configurations for an application like Exchange. The server folks will argue the details of CPU and memory to the nth degree and the storage people really get into I/O, drive speeds, and capacity. It's all goodness because it keeps people gainfully occupied. But we live in a world where simplicity is becoming a watchword as the influence of cloud services is felt. I wonder what affect this will have on storage vendors who sell into the Exchange market. Microsoft has shown its hand in the way that JBOD is used for Exchange Online and the on-premises market is declining. What will the storage vendors do?
Following my post on “The story of Exchange IOPS” outlining the journey of Exchange from being an I/O hog to something far less demanding on storage systems, a recent request from Josh Odgers from Nutanix to consider his post “Peak performance vs Real World – Exchange on Nutanix Acropolis Hypervisor (AHV)” seemed to be opportune. His point that “peak performance benchmarks should be taken with a grain of salt” is well made.
I’ve had my share of run-ins with some folks at Nutanix before, notably two years ago regarding their heartfelt feeling that the Exchange product group should support NFS-based storage. That debate fizzled out, perhaps because of lack of customer interest. At least, that’s what seemed to be the case when very few of those who attended the MEC 2014 conference in Austin put up their hand when asked if they wanted NFS to be supported. I last touched base with Nutanix at their booth at Ignite 2015 last May and everything seemed to be at an even keel. Nutanix do fast storage, support SMB for Exchange, and they have some interesting solutions, such as the one described in this post. And I have heard some good feedback about them too, despite some hiccups that you might have read about in the past.
However, looking forward it seems that two influences are becoming more of an obstacle for companies that sell high-end storage into the Exchange market.
First, there’s the fact that the Exchange product group has a very strong focus on cheap and cheerful storage. The crusade to drive I/O requirements to very low levels has reduced the attractiveness of sophisticated storage systems that deliver lots of IOPS. If you can’t use a resource, why pay for it?
Microsoft runs Exchange Online inside ever-expanding archives and large Recoverable Items capacity.on JBOD storage and uses Native Data Protection (aka four copies of each database, one of which is lagged) to insulate users from failure. And drive failure is one thing that you can be guaranteed of with cheap JBOD. But who cares when you buy literally millions of cheap 8 TB drives to provide 50 GB Exchange Online mailboxes plus
Because Microsoft sees the on-premises demand for Exchange reducing as companies move workload to Office 365, it’s inevitable that their engineering priorities are firmly focused on making the cloud platform work as efficiently as possible. Cost efficiency is an important part of that equation. The upside for those who want to stay on-premises is that technology transfer back into releases like Exchange 2016 have improved high availability and reduced I/O demand.
Second, the drive to virtualize servers was the fashionable thing to do some years ago. I perceive that this is less of a must-do now. In terms of Exchange, Microsoft has influenced the debate in a number of ways. They tell people that virtualization is not used inside Office 365, they point to the extra complexity involved when servers are virtual, and the preferred architecture for Exchange 2016 is firmly based on physical multi-role servers.
Advocates for virtualization might disagree with Microsoft (like the VMware guru who told the Exchange team they were wrong about performance last year) and it is certainly true that those who really know their way around VMware and Hyper-V can do wonderful things on these platforms, but perhaps not for Exchange. In my eyes, nothing beats a physical mailbox server.
Over sixty million commercial Office 365 users are active, which gives a sense of how many mailboxes have moved over. The vast majority of those mailboxes came from the small to medium market segment (which means different things in different countries). Many large companies have moved some or all mailboxes to the cloud but lots more have not (yet). Larger IT shops are where the operational maturity exists to exploit virtual servers and other enterprise-class components like Storage Area Networks or indeed the intelligent storage solutions made by vendors such as Nutanix and NetApp.
All of which makes me think that the real impact of Microsoft’s crusade to reduce I/O demand in Exchange has not yet been felt by storage vendors. However, as large enterprises consider their options for future email services and more workload transitions into the cloud, I wonder what space will be left for storage vendors to exploit. It will be interesting to see what solutions appear at the Ignite 2016 conference in Atlanta next September to understand how the storage vendors are responding to a real and obvious threat.
Changing circumstances might also mean that vendors pay less attention to eye-catching claims about how many mailboxes can be supported on a particular configuration (like the sometimes flawed examples published in Microsoft’s Exchange Solution Reviewed Program) and focus more on added value. After all, there’s no point in having a car that’s as fast as a Formula 1 racer if it can’t be used on the road (and to bring the shopping home).
Coming back to the original point, as we move forward into the third decade of Exchange, it seems to me that the challenge for storage vendors is not about proving how many I/Os they can produce on a sustained basis using artificial test suites like JetStress. Instead, it might be better if vendors focused on other aspects like simplicity, reduced cost, and helping customers to extract more advantage from software features like Native Data Protection. Just a thought.
Follow Tony @12Knocksinna