A number of people working for Nutanix have been in the vanguard of those who would like to see NFS supported as a valid storage option for Exchange deployments, some of whom cheerfully recommend that “customers continue to run Exchange on Nutanix containers presented via NFS.“ In my mind this is a bad idea because it puts customers into an unsupported configuration. Running what is often a mission-critical application in a deliberately unsupported manner has never really appealed.

As you might be aware, the current situation is that Exchange 2010 and 2013 supports three storage architectures: Fibre Channel, iSCSI, and DAS. These architectures are supported because Microsoft knows that they work well with Exchange and are implemented by a wide range of storage vendors in a predictable and robust manner, all of which creates supportable solutions for customers.

As I have discussed before, Microsoft has a number of technical issues that have to be resolved before NFS can be added to the list of supported storage architectures. We can argue this point to the nth degree, but it’s not me that needs to be convinced that NFS is supportable for solutions created by multiple vendors. At the end of the day, the vendors who want to sell NFS-based solutions have to convince Microsoft. And Microsoft have to be convinced that NFS will be implemented at the same high quality by every vendor – and that those vendors can support their hardware in the field if things go wrong.

I think Microsoft has another concern too: there doesn’t appear to be too much customer demand that Exchange supports NFS. At least, this was the strong impression formed when Jeff Mealiffe queried an audience of several hundred people during his “Virtualization Best Practices” session at MEC last April. Only 3 or so people put their hand up when asked. If the commercial demand existed, you can bet that Microsoft would be all over NFS like flies around cow dung.

Those who want to see NFS join the list of supported architectures are diligent about advancing their case across a range of social media. An example is a Reddit debate. Twitter is also a favourite medium, which we’ll get to shortly. Another is the write-up in a TechNet forum that sets out the case for Exchange to support VMDKs mounted on NFS datastores. This post makes the point that there is a “gap in supporting Exchange in VMware vSphere & KVM with datastores connect via NFS 3.0.” That gap exists but the evidence from the audience pool at MEC is that it is a relatively small gap in the overall context of the Exchange market.

In saying this I accept that the gap (in support) might be terribly important to certain companies who wish to standardize their virtualization platform around NFS. But that’s not evidence that consistent and perceivable customer demand exists in sufficient quantity to warrant Microsoft to do the work necessary to certify that NFS indeed works (in a supportable manner) with Exchange.

Remember that once a storage architecture is supported, that support has to stay in place for an extended period (probably ten years given Microsoft’s normal support policies) and that support must be available on a worldwide basis. Convincing management to sign up for the costs necessary to support another support architecture without evidence that this will do anything to increase either Microsoft’s profitability or market share is a hard case to argue. And this proposal has to be viewed in the context of an on-premises market that will decline over time as a sizeable chunk of the installed base moves to Office 365 or other cloud providers. So the case being advanced is a good technical debate that runs into rough waters when money and market issues are factored into the equation.

It does not seem like a good economic decision for Microsoft to support NFS, but does the technology work? It certainly seems like quite a few companies have followed the Nutanix advice to run Exchange databases on NFS storage. To demonstrate that everything works just fine, Nutanix explained in the Reddit debate how they ran a JetStress test. They reported that “the Exchange Solution Reviewed Program (ESRP) Jetstress test (ran) for 24 hours in a single Windows 2008 VM with 4 PVSCSI adaptors serving 8 x VMDKs hosted on a single NFS datastore and no surprise it PASSED with flying colours.” This is all very well, and I am sure that everyone associated with the test was tremendously happy.

However, running Jetstress is no way to prove supportability, which is the key issue debated here. Jetstress certainly allows you to stress storage subsystems to prove their stability, so the test simply proves that (a specific version of) Nutanix’s implementation of NFS works when exercised by JetStress. It does nothing to prove the case for supportability of NFS within Exchange deployments. More work would have to be done to ensure that a guaranteed standard of implementation and performance was achieved for NFS across the industry. A single test run by a single vendor against a single storage configuration proves nothing.

It’s also true that the configurations that are capable of passing the guidelines laid down in ESRP are often “odd” and impractical in terms of real-life deployments, so saying that a test was passed with flying anything really doesn’t help us understand how NFS would cope with Exchange over a sustained period across multiple software versions deployed by different people around the world.

Some comments from a Nutanix employee on my Twitter feed

Going back to Twitter, I received some advice from Nutanix employees that I should engage with their initiative to encourage Microsoft to support NFS. I should stop being a sheep and work to convince Microsoft to change their “outdated and embarrassing support policies.” Quite.

I found it odd to see the debate reigniting because Nutanix has a configuration that presents iSCSI storage to Exchange. Given that this configuration exists, I wonder why we have to debate NFS support at all. It would seem much more productive all round for Nutanix to tell customers to use the fully-supported iSCSI approach rather than expending all these cycles trying to convince Microsoft that NFS should be supported too.

In my past, I spent over a decade in Chief Technology Officer or Technical Director jobs at Digital, Compaq, and HP. As such, acknowledging that I have been known to be wrong (many times), I think I have a reasonable grasp of how to assess the import and worth of a technology. So I spent a little time looking at the information available on the Nutanix web site.

Up front I have to admit that I have no hands-on experience of Nutanix products. Their literature indicates that they have some interesting technology created by people with a strong track record in the storage industry. As such, its products are certainly worth checking out if you are interested in virtualization. However, I have some doubts about some of their statements concerning Exchange.

For example, browsing Nutanix’s “Microsoft Exchange Solution Brief,” I was interested to find the assertion “With more than 50% of Microsoft Exchange installations now virtualized, it is critical to select the right server and storage architecture.” Although no one could quibble with the advice, I think they are way off with the preamble. I have never seen any reliable data to indicate that the majority of Exchange deployments are virtualized and no evidence is offered by Nutanix to support this statement. And anyway, what do we mean by an installation being virtualized? Does it mean that a single CAS is virtualized? Or all CAS and no mailbox servers? Or all Exchange servers in an organization?

It’s absolutely certain that virtualization is an important technology for many who deploy Exchange but I don’t think it is so widely deployed as to now be in the majority. I asked Microsoft and they didn’t think so either but couldn’t comment publicly. I accept that the document is intended for marketing purposes but it is not good when the first statement in the text can be so easily queried.

Nutanix and Exchange High Availability

Another question is how Nutanix positions their technology alongside Exchange high availability. The picture above is taken from a presentation given by Nutanix representatives to customers where the recommendation is to use VM replication to copy databases to a disaster recovery site. Another recommendation is to take a separate copy to use for litigation or on-hold purposes.

This arrangement smacks of the old-fashioned arrangements needed before the advent of the Database Availability Group (DAG) in Exchange 2010 where storage subsystems copy Exchange databases to a separate disaster recovery site. It doesn’t reflect current best practice, which is to stretch the DAG to cover servers in the DR site and use normal Exchange replication to keep database copies in the DR site updated so that they can be quickly switched into action should a problem affect the primary site.

Exchange has transitioned from depending on separate hardware replication to being able to provide this level of resilience within the appliance. I would have had no problem with the approach in an Exchange 2007 deployment but I think its value must be questioned in Exchange 2010 and 2013. It seems like a case where a product can do something so we’ll do it, even though a better method is available. I can see how the approach would work, but it’s always best to seek simplicity in DR and it seems better to allow the application to do what the application is designed to do in these situations rather than to layer on an additional technology to serve the same purpose. The case can be argued either way.

I also don’t understand the need for a separate immutable copy for litigation or in-place hold. These are features that are designed into Exchange 2010 and Exchange 2013 and you don’t need any additional hardware or software to gain this functionality. To be fair, some circumstances might require a configuration like this to satisfy a particular regulatory demand, but I can’t think of one right now.

I am not slamming Nutanix’s technology or the value proposition that they advance to potential customers. I rather like their can-do attitude and their willingness to take on the big players in the storage world (an example is in this blog about EMC) with new technology and approaches.  However, I do think that some Nutanix employees are prone to hyperbole and that the advice extended to the Exchange community is sub-optimum and in some cases (as in the solution brief), incorrect.

Perhaps Nutanix would be better to focus on building Exchange solutions based on their technology that embrace, enhance, and extend the functionality that’s already available in Exchange rather than starting crusades to support technology that does not seem to be wanted by many. At least, not by those who attended the recent Microsoft Exchange Conference, a group that I assume represents the core audience to which Nutanix wants to sell their products.

After all, if Nutanix can deliver iSCSI storage (a supported storage architecture for Exchange), why do they want to insist on campaigning for NFS? The “Nutanix Bible” and the blog referenced above indicate that this is possible, so I really don’t know why all the hot air exists around NFS.  I must be missing something!

Follow Tony @12Knocksinna