Microsoft tangles with VMware over Exchange “guidance”

Microsoft and VMware are at odds over some “guidance” the virtualizaton software maker has issued about Exchange and disaster recovery.

At issue is a section in a document published by VMware titled “Microsoft Exchange 2010 on VMware Availability and Recovery Options.” which discusses using Database Availability Groups (DAG) clustering for fast recovery following a disaster.

“Database level high availability can be achieved through the use of database availability groups.,” VMware said.

“In the event of a server host failure, a passive copy of the affected mailbox databases is activated,” it continued. “Client access servers establish MAPI connectivity to the newly active database copy and client connections are reestablished.”

“In the background, VMware HA powers-on the failed virtual machine on another server host, restoring the DAG membership and bringing the newly passive database up to date and ready to take over in case of a failure, or to be manually reactivated as the primary active database,” it said.

“While the use of database availability groups on top of hypervisor based clustering is not a formerly supported configuration, internal VMware tests have shown that the two technologies can co-exist and can be a viable solution to ensure maximum recoverability in the case of a host failure.,” it added.

That advice from VMware was bleakly viewed by Microsoft.

“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,” the company wrote at the Micrsoft Exchange Team blog.

“For example,” it continued, “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,” it added.

Microsoft went on to argue,

“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,” it added, “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.”

Needless to say, VMware didn’t take kindly to Microsoft’s criticism of the virtualization software maker’s advice. Far from reckless, Alex Fontana and Scott Salyer wrote at VMware’s Virtual Reality blog, the advice “can help our customers get greater value out of virtualizing Exchange.”

The VMware solution reduces complexity, they maintain.

“VMware HA is a very simple mechanism that automatically reboots a failed virtual machine on any available host in the vSphere cluster in the case of a host failure,” they explained. “From an application standpoint, the behavior of VMware HA is equivalent to a simple power-on of the machine on which the application is running. It is completely transparent to the OS and the application.”

When a DAG fails in the real world, an administrator will power on that node to restore availability protection. VMware HA does the same thing, only automatically, Fontana and Salyer asserted.

“Seems to us like that’s a pretty reasonable thing to do, and many of our customers agree and are happily using this in production,” the pair wrote.

The approach doesn’t increase the cost of deploying Exchange, the argued, because computing requirements remained unchanged since HA doesn’t rely on failover instances. Neither does it affect overall storage requirements, they contended.

Moreover, what could be simpler for administrators? “When a DAG node fails, you no longer need to manually detect the failure and bring the node back up–VMware HA does that automatically,” they added. “And VMware HA doesn’t require any OS- or app-level configuration changes.”

While VMware makes a strong case for its advice, when the rubber meets the road, that is, when something goes wrong and an administrator needs Microsoft to come to the rescue, the advice could backfire on those who heed it.

As Scott Lowe points out in his blog at VirtualizationAdmin.com:

“VMware is probably in the wrong when it comes to actively recommending to customers what Microsoft considers an unsupported configuration. While the solution is almost 100 percent likely to work from a technical perspective (and, this has been tested), Microsoft is known for their strict support policies when it comes to virtualization and, from the standpoint of ability to get support when necessary, this unsupported configuration could leave customers at risk for not getting support.”

Nevertheless, Lowe called Microsoft on the carpet for its position on the VMware solution.

“Microsoft: If you have solid technical reasons for not supporting HA (not DRS) for DAG members complete with the test results and numbers to back up the ‘cost and complexity’ claim, we want to hear it!” he wrote. “If there is something to the claim, additional information will help customers make much better decisions regarding availability and will go a long way toward helping us understand this stance.”