Tag Archives: exchange

Answering Exchange Virtualization Questions and Addressing Misleading VMware Guidance

The title of this post reflects a blog post on the Exchange Team Blog (aptly named: You Had Me At EHLO). You can find it here: http://msexchangeteam.com/archive/2010/11/09/456851.aspx. While the wording is a bit strong I agree with the points raised in the blog post.

Main point of the post in my opinion is:

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.

This is an important item to address in a multi-server Exchange design running in a virtualized environment. While things like VMware HA are great for protecting against host failures it will not (as mentioned further along in the article) protect against application failures. If the availability requirements stay within anything that can be done with a single datastore on a single server then using HA and vMotion are perfectly fine in my opinion but go beyond that and you’ll soon see issues arising from using two types of clustering/HA measures for the same application. You’ll be using anti-affinity rules to prevent clusternodes from being migrated to the same host for instance. Now think about having to do that for an Exchange cluster using multiple datastores running on multiple servers. It just makes things more complex than they need to be.

Read the rest of the article for more information on the subject. Thanks to @douglasabrown for posting the article to Twitter.

3.01 and MS Exchange

In earlier posts I commented on what we will not virtualize. One of the application I mentioned was MS Exchange due to the lack of 64bit support (needed for Exchange 2007).

With the release of VI3.01 today there is production support for W2003 64 bit edition but in the end we decided against virtualizing our Exchange environment. Apart from the extra licensing for VI3 which makes it more expensive than just replacing the servers we feel it will make our environment more complex a bit too soon.

Because of our experiences with Exchange we would still cluster the servers with MS Cluster Services but at the moment only a handful of SAN’s support VMotion for MS clustered servers so we would need to take extra measures with regards to which host an Exchange cluster VM is located.

Should the replacement of the Exchange servers have come somewhere in 2007 we might have made a different decision but at the moment we don’t want to make that step yet.

The projected Exchange environment is as follows:

  • 2 Exchange Frontend servers (IBM x3550) in loadbalanced cluster
  • 3 Exchange Backend servers (IBM x3650) in active-active-passive configuration
  • 1 Bridgehead server (IBM x336, will become available through virtualization)
  • 1 Global Catalog (IBM x346, will also become available through virtualization)

All the new servers (the x3550 and x3650) will have the new dual core Xeon’s. This is an environment sized for heavy traffic on 4000 mailboxes and 10000 public folders.