Best practices for virtualizing Exchange – Part 1: VMware

Virtualization – it seems like everyone is moving to virtualize as much as they can. Whether they do it on-premises, or in the cloud, reducing physical machine counts in favor of increasing virtual machine counts is a trend that continues to grow. When you consider how many Exchange servers a company needs to have, and how critical it is for them to be highly available and fault tolerant, virtualizing them just makes sense.

In this three-part series, we want to look at best practices for virtualizing Microsoft Exchange.

We’re going to try to take a vendor agnostic approach to this, covering both VMware and Hyper-V, but not comparing the two. We will point out where support differs, which may be an important factor for some, but we’re not going to try to convince you one platform is better than the other. We’re also not going to talk about the merits of physical versus virtual. Instead, this series is going to go with three presumptions in place.

1. You are going to virtualize your Microsoft Exchange server(s)
2. You already have a virtualization platform in place
3. You just want to know what you should watch out for, or anything you want to be sure you do, to have the best experience doing this.

If you’re good with that approach, let’s jump into the first part, that is, Exchange on VMware!

Support

Let’s get this one out of the way. Microsoft doesn’t support VMware, and it doesn’t support Exchange running on VMware. You can’t blame them as it’s not their product. Now, let’s look closer at what “doesn’t support” means. Firstly, they won’t hang up on you if you call in with a problem running Exchange and your virtualization platform is VMware. They just need to move from guaranteeing resolution to “commercially reasonable” support. If the problem is Exchange; they will help you out. If the problem starts to look like VMware is the source of the problem, you will either need to engage VMware or move your Exchange servers to supported hardware or Hyper-V before they can continue. I’ve been on calls with both Microsoft Support and VMware Support; they do play well with one another but, neither can be the sole source of support for the other. If you are going to deploy Exchange on VMware, plan on keeping support contracts with both, and needing to work with both if something comes up. Microsoft’s official statement on Exchange 2013 virtualization can be found at https://technet.microsoft.com/en-us/library/jj619301(v=exchg.150).aspx.

Versions

Our recommendations are based on Exchange 2013. You can, to a limited extent, use the same guidelines for Exchange 2010, but the disk I/O load for mailbox servers running Exchange 2010 is so much greater than for those running 2013, so my advice is you stick with physical boxes for any production mailbox servers. Don’t even try to virtualize Exchange 2007; not to mention that you should really be getting off that platform ASAP! And if you are still running Exchange 2003, you have far more problems than trying to figure out how to virtualize them! As for Exchange 2016…these guidelines should hold true for that platform as well. If something major changes after GA, we will update this post in the comments section.

Resources

Here’s the bottom line on what you want to do with resource allocation to Exchange on VMware.

CPU

• Keep your CPU allocation 1:1. Don’t over-commit. Cores per socket should be 1.
• Enable hyper-threading on both the host and the VM.
• Enable non-uniform memory access.
• Keep the VM sized to fit within a single NUMA node. If the NUMA node has 8 cores, don’t assign more than that to the Exchange server.
• Fewer servers with multiple cores is better than more servers with fewer cores.

Memory

• Do not over-commit memory. Not now, not ever. Don’t be that person.
• Reserve memory allocations to ensure your VM will always have the amount of memory it should.

Storage

• Do not thin provision disks.
• Format NTFS (of course!) with a 64KB allocation unit size.
• Use four (or more) vSCSI adapters and spread your disks across all four.

Network

• Assign multiple NICs
• Use the VMXNET3 network card

HA/FT

To avoid a DAG failover when you vMotion a server,

• Enable jumbo frames on vmkernel ports
• Dedicate interfaces to vMotion
• Set your cluster heartbeat to 2000ms
• Use an anti-affinity rule for each DAG so you don’t have both DAG members on the same host

Do’s

• If you are going to setup for vMotion (as if you would not) make sure to use multiple NICs.
• Enable non-uniform memory access.
• Set the power policy to high-performance. This is not the time to try to save a few KWs.
• Run your appropriate sizing calculations, jetstress your storage, and ensure you have sufficient Global Catalog servers for your Exchange environment. Virtualization does not make any of these less important than with physical servers.

Don’ts

• Don’t use snapshots.
• Don’t keep any volumes on NFS.
• Don’t put two DAG members on the same host.
• Don’t disable the balloon driver.
• Don’t use RDMs.

Let us know your experiences with virtualizing Exchange below and check back soon for our next post where we will go over best practices/recommendations for virtualizing Exchange on Hyper-V.