Microsoft Exchange Server 2010 will support VMWare HA

Microsoft Corporation has changed his option in supporting VMWARE  and starting with the Service Pack 1 will support VMWARE high availability.

reviously, Microsoft had said it wouldn’t support VMware High Availability (HA) or other hypervisor-based, third-party failover tools because they could make it more expensive and complex to run Exchange. But users all along doubted there were any technical issues that would make it risky to run VMware HA with Exchange database availability groups (DAGs).

“At this point, application vendors will get so much resistance from their customers if they take the position of not supporting their product running on a virtual platform,” said Shannon Snowden, manager of delivery services at New Age Technologies in Louisville, Ky., in an email. “They eventually have to change their stance.  That includes Microsoft.”

New Exchange 2010 DAG failover support policy
Microsoft issued its new support statement Monday during the TechEd North America conference.

“Combining Exchange 2010 high availability solutions (database availability groups (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, is now supported,” Kevin Allison, an Exchange general manager, wrote on The Exchange Team Blog.

The blog post doesn’t mention VMware HA by name, but in an interview, senior technical product manager Jim Lucey confirmed that the new support will include this product. The blog post also cites “improvements … made in Exchange Server 2010 SP1” and “more comprehensive testing of Exchange 2010 in a virtualized environment” as reasons for the new support policy.

But Lucey said in this case, quality-assurance testing was the difference-maker.

“There is no technical change to DAGs with regard to live migration and HA,” he said. “We did testing with Service Pack 1 and so made that the basis of support.”

Microsoft will support its own products, and if the cause of the support issue is a third-party tool, Microsoft will either engage that vendor directly, or in the case of a competitor such as VMware, engage the Technical Support Alliance Network to coordinate support.

Matthew Liebowitz, a solutions architect for Manhattan solutions provider Kraft and Kennedy, Inc., said he was “thrilled” to see the updated policy. But he cautioned that users should make sure deployments are configured correctly.

“I never saw much technical merit to the restriction against using VMware HA in combination with DAGs, but I have seen issues with DAGs and vMotion and [Distributed Resource Scheduler],” he said.

Exchange 2010 VMware HA support: A long time coming
Despite the new policy, Microsoft still argues that DAGs make tools such as VMware HA redundant because they are aware of both application and hardware failures.

The spat over support began last fall, when, VMware issued a white paper (PDF) explaining how its HA feature can be used alongside Exchange 2010’s DAGs for application high availability and disaster recovery. The Microsoft Exchange Team took umbrage, calling VMware’s guidance “reckless” and saying that it “puts Exchange customers at risk.”

The conflict continued into March, when VMware returned fire with an architecture design proposal that claimed to eliminate the need for DAGs. The back and forth between the two vendors drew plenty of attention from the virtualization community, much of which was critical of Microsoft.

Lucey acknowledged that this criticism prompted further testing of Exchange 2010 DAGs with third-party HA and live-migration tools.

“As more customers move toward virtualization, we’re going to adapt to the trend,” he said. “From an Exchange perspective, we saw customers demanding [this support] and said, ‘Let’s do the testing.’”

 

 

 

Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments

Microsoft has published an interesting article about their official support for installing Exchange on Hyper-VVirtual Server 2005 virtual machines.

To make a long story short, here are the support policies for both Exchange 2007 and Exchange 2003:

Support Policy and Recommendations for Exchange Server 2007

Microsoft supports Exchange Server 2007 in production on hardware virtualization software only when all the following conditions are true:

• The hardware virtualization software is Windows Server 2008 with Hyper-V technology, Microsoft Hyper-V Server, or any third-party hypervisor that has been validated under the Windows Server Virtualization Validation Program.
• The Exchange Server guest virtual machine:
  • Is running Microsoft Exchange Server 2007 with Service Pack 1 (SP1) or later.
  • Is deployed on the Windows Server 2008 operating system.
  • Does not have the Unified Messaging server role installed. All Exchange 2007 server roles, except for the Unified Messaging role, are supported in a virtualization environment.
• The storage used by the Exchange Server guest machine can be virtual storage of a fixed size (for example, fixed virtual hard drives (VHDs) in a Hyper-V environment), SCSI pass-through storage, or Internet SCSI (iSCSI) storage. Pass-through storage is storage that is configured at the host level and dedicated to one guest machine.Note:

  In a Hyper-V environment, each fixed VHD must be less than 2,040 gigabytes (GB). For supported third-party hypervisors, check with the manufacturer to see if any disk size limitations exist.

  • Virtual disks that dynamically expand are not supported by Exchange.
  • Virtual disks that use differencing or delta mechanisms (such as Hyper-V’s differencing VHDs or snapshots) are not supported.
• No other server-based applications, other than management software (for example, antivirus software, backup software, virtual machine management software, etc.) can be deployed on the physical root machine. The root machine should be dedicated to running guest virtual machines.
• Microsoft does not support combining Exchange clustering solutions (namely, cluster continuous replication (CCR) and single copy clusters (SCC)) with hypervisor-based availability or migration solutions (for example, Hyper-V’s quick migration). Both CCR and SCC are supported in hardware virtualization environments provided that the virtualization environment does not employ clustered virtualization servers.
• Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots capture the state of a virtual machine while it is running. This feature enables you to take multiple snapshots of a virtual machine and then revert the virtual machine to any of the previous states by applying a snapshot to the virtual machine. However, virtual machine snapshots are not application-aware, and using them can have unintended and unexpected consequences for a server application that maintains state data, such as Exchange Server. As a result, making virtual machine snapshots of an Exchange guest virtual machine is not supported.
• Many hardware virtualization products allow you to specify the number of virtual processors that should be allocated to each guest virtual machine. The virtual processors located in the guest virtual machine share a fixed number of logical processors in the physical system. Exchange supports a virtual processor-to-logical processor ratio no greater than 2:1. For example, a dual processor system using quad core processors contains a total of 8 logical processors in the host system. On a system with this configuration, do not allocate more than a total of 16 virtual processors to all guest virtual machines combined.

Support Policy and Recommendations for Exchange Server 2003

Microsoft supports Exchange Server 2003 in production on hardware virtualization software (virtual machines) only when all the following conditions are true:

• The hardware virtualization software is Microsoft Virtual Server 2005 R2 or any later version of Microsoft Virtual Server.
• The version of Exchange Server that is running on the virtual machine is Microsoft Exchange Server 2003 with Service Pack 2 (SP2) or later.
• The Microsoft Virtual Server 2005 R2 Virtual Machine Additions are installed on the guest operating system.
• Exchange Server 2003 is configured as a stand-alone server and not as part of a Windows failover cluster.
• The SCSI driver that is installed on the guest operating system is the Microsoft Virtual Machine PCI SCSI Controller driver.
• The virtual hard disk Undo feature is not enabled for the Exchange virtual machine.Note:

  When a Microsoft Virtual Server SCSI adaptor is added to a virtual machine after the Virtual Machine Additions have been installed, the guest operating system detects and installs a generic Adaptec SCSI driver. In this case, the Virtual Machine Additions must be removed and then reinstalled for the correct SCSI driver to be installed on the guest operating system.

Rest of the recommendations are at Microsoft website.

Exchange Server 2010 DAGs and VMware High Availability

If you are planning to deploy Exchange Server 2010 Database Availability Groups, and you virtualize your Exchange environment, then it is important to understand the supported scenarios.

Microsoft makes it very clear in their system requirements for Exchange Server 2010:

Microsoft doesn’t support combining Exchange high availability solutions (database availability groups (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. DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn’t employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.

In short, DAG members should have any virtualization high availability options disabled.

This is in slight contrast to the advice from VMware themselves:

While the use of database availability groups on top of hypervisor based clustering is not a formerly (sic) 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.

To paraphrase, it isn’t supported but we think you’ll be fine.

You might get some push back from customers or managers who have been sold on the idea of VMware HA for everything, or who take the line from VMware as implied support for the configuration.  But in the real world I prefer to go with what is supported over what is possible.