Microsoft vs VMware on Exchange Virtualization and HA Best Practices

I recently pointed out the difference between Microsoft and VMware guidance on mixing Exchange Server 2010 DAGs with hypervisor HA features.  In short, Microsoft clearly states that hypervisor HA features should be disabled for DAG members, while VMware considers it to be an effective solution.

My own view on this hasn’t changed – stick to what is supported, not what is possible.

I’m not a VMware expert so I have no way to dig deeper into whether VMware HA would be a viable or effective solution when mixed with Exchange Server 2010 DAGs.  Others around the industry have weighed in from their position of knowledge and it seems that there may be an issue of interpretation of how different hypervisor HA features work.

Which doesn’t change the support position of Microsoft at all.

It seems that Microsoft has been receiving more than a few customer enquiries about this recently which has prompted this statement on the Microsoft Exchange Team blog.

While Microsoft embraces virtualizing Exchange servers because virtualization gives organizations additional choice and deployment flexibility to meet business requirements and lower IT costs, we’re concerned by deployment guidance that doesn’t accurately follow our Exchange best practices and deployment guidelines.

From there the language gets a little stronger (emphasis added by me).

For example, we feel VMware’s misleading guidance represented in their recent “Exchange 2010 on VMware Availability and Recovery Options” document (and accompanying “Exchange 2010 on VMware Best Practices Guide”) puts Exchange customers at risk, and brushes aside important system requirements and supported configurations. Their guidance could also greatly increase the overall cost of managing your Exchange infrastructure.

Microsoft goes on to make their position very clear (emphasis theirs this time).

VMware specifically recommends combining their VMware HA solution with the Exchange application-aware high availability solution, which is an unsupported configuration. It is important to note that VMware’s HA solution only protects from some hardware failures, while the Exchange high availability solution protects against both hardware and application failures (including a process for patching guest virtual machines). It is simply reckless for VMware to recommend customers deploy this configuration, while ignoring important Microsoft system requirements and unsupported scenarios. In addition, VMware also seems to gloss over the fact that combining these HA solutions will result in new storage requirements that increase cost and complexity. Considering that a significant focus of Exchange 2010 is reducing storage costs, promoting a strategy that increases storage costs isn’t consistent with our customers’ requirements.

There is nothing within the material that explains how combining Exchange database availability groups (DAGs) with VMware HA will provide a faster end-user mailbox recovery than using Exchange DAGs alone. Since Exchange HA protects against hardware and application failures, it is hard to imagine how VMware can provide a faster, and simpler solution than Exchange HA alone.

Microsoft does not support combining Exchange high availability (DAGs) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers. Microsoft recommends using Exchange DAGs to provide high availability, when deploying the Exchange Mailbox Server role. Because hypervisor HA solutions are not application aware, they cannot adapt to non-hardware failures. Combining these solutions adds complexity and cost, without adding additional high availability. On the other hand, an Exchange high availability solution does detect both hardware and application failures, and will automatically failover to another member server in the DAG, while reducing complexity.

So not only is it unsupported, it may in fact be pointless and more expensive to implement and manage as well.

Like I said earlier I’m no VMware expert, but that makes a lot of sense to me.