Virtualizing Microsoft Exchange with VMware

Recent research from Gartner’s Burton Group has concluded that “Enterprise production e-mail servers should be deployed virtualized by default (meaning that it should be an exception backed by specific technical considerations when they are deployed on “bare metal”).” While this underscores the benefits of virtualization I mentioned in my previous blog, it would be wise to follow best practices to get the best results.  Here are some items to consider when virtualizing your Exchange Servers on ESX.

Memory Requirements.   An Exchange 2010 (and 2007) installation running the roles of Mailbox, Hub Transport, Client Access and Management Tools requires 16GB of memory to avoid page swapping!  As you know, you can allocate a maximum of 255GB to a Virtual Machine (VM) on ESX.  If you’re migrating from Exchange 2003, the increased memory requirements will come as quite a shock.  Exchange 2007/2010 must run on the Windows x64 platform because the increased memory capacity of the x64 platform allows Exchange 2010 to cache the information stored on disk. The additional memory in the VM is used to cache the Exchange Server information.   This makes the Exchange 2007/2010 significantly more scalable than previous versions.  Allocating an appropriate amount of memory to your Exchange virtual servers will ensure good performance on these VMs.  Allocating more memory to your Exchange VMs will reduce the disk load on the ESX host due to a reduction in page swapping.  For the best performance, avoid using the memory overcommit feature in ESX. This will keep you from allocating more memory to VMs than the amount of physical memory on the ESX host. 

Number of vCPUs.  Exchange 2010 is the first version of Exchange that can benefit from multiple vCPUs in the VM.  In the case of Exchange 2007, using four vCPUs instead of one in the VM would have little or no performance benefit. Conversely, going from one to four vCPUs in Exchange 2010 VM can significantly increase performance of the Exchange VM.  We suggest configuring most Exchange Servers with two to four vCPUs.  Of course the appropriate number of vCPUs depends on many factors, so this is a general guideline. Each vCPU allocated to VMs running on an ESX host must be scheduled on physical cores within the host. For this reason, the number of vCPUs in a VM should never exceed the number of physical CPU cores on the ESX host.  When possible, try to have the same number of vCPUs on all VMs running on an ESX host so the ESX CPU scheduler can optimize CPU scheduling. 

Disk Configuration. Many of the same rules that apply to the disk configuration of a physical Exchange server apply to an Exchange VM.  If you have a large Exchange Mailbox Server with heavily used databases consider creating three storage groups: 

1.    Storage Group 1 setup as a RAID 1 to load the OS (VM Drive C:)

2.    Storage Group 2 setup as a RAID 1 for the Exchange Server Logs (VM Drive D:)

3.    Storage Group 3 setup as a RAID 5 or RAID 10 for the Exchange Databases (VM Drive E:)

This configuration will give you the best disk performance for your Exchange VM, though it might be a little overkill for a smaller Exchange installation.  Remember, you can somewhat compensate for poor disk performance by allocating more memory to the Exchange VM for disk cache. If you need to have a vmdk larger than 256GB, make sure that you format the Storage Group with the appropriate block size. The relationship between block and vmdk size is listed below:

The largest Storage Group on ESX is 1.99TB.

Database Availability Groups. As you know, one of the cool features of Exchange 2010 is the Database Availability Groups or DAG. The DAG allows you to have redundant Exchange Databases without purchasing a SAN or creating a cluster but using a SAN allows you to enjoy advanced vSphere features such as vMotion, HA and DRS. You must have at least two ESX hosts to properly implement DAG on Exchange 2010. You must make certain that the Exchange Mailbox Server VMs that service the same DAG never run on the same ESX host.  If both of the Exchange VMs are on the same ESX host and the host goes down, your Exchange databases will still be inaccessible. 

These are some of the common configuration tips and tricks to help you confidently virtualize Exchange Servers in an ESX environment.  Hopefully this blog entry will put you ahead of the curve on the way to a successful Exchange VM implementation on VMware.