It wasn’t that long ago people laughed at the thought of running Exchange Server in a virtualized environment....
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Well, things have changed. I now have many customers who successfully run Exchange 2010 on Microsoft Hyper-V. Here is a list of five best practices they all use and so should you.
1. Read current documentation; properly virtualize the Exchange server roles
There are lots of blog posts and articles about virtualizing Exchange Server. Unfortunately, many of them are outdated. For example, you may read that you can’t virtualize the unified messaging role in Exchange 2010. That was true -- prior to Exchange 2010 Service Pack 1. Today, virtualizing the UM role is fully supported (with Exchange 2010 SP1 or higher). That said, make sure to install it -- by itself -- on a virtual machine (VM) that has 4 CPU cores.
Make sure to always always refer to the latest guidance from the Exchange team on what is and isn’t supported. I suggest reading the Exchange team blog on a regular basis.
2. Not all virtual disks are created equally
Consider using either fixed or pass-through disks when deploying VMs. If you allocate 120 GB to a virtual disk, you want to make sure that Exchange 2010 can use all of that space as soon as it needs it. You shouldn’t have to wait for the mailbox server’s disks to dynamically expand as new data is committed to disk. If you go with virtual hard disks (VHDs), make sure that they’re fixed.
That said, pass-through disks are an even better option. They are true physical disks that are connected to the Microsoft Hyper-V host and are essentially handed directly to the VM. This disk type will give you the best performance, but might add a bit more complexity to your design.
Finally, stay away from differencing disks when virtualizing Exchange 2010. Differencing disks might seem great for low-priority virtual machines because they let admins start with a base VHD, then store delta changes in another file. They also allow for speedy server deployments and let admins use the same base operating system VHD on 20 virtual servers, while simultaneously saving lots of space. Unfortunately, when it comes to virtualizing Exchange 2010, differencing disks cause major performance issues and are not supported.
Note Virtual machine snapshots are not supported. Make sure you have a backup and restore process that works and test it regularly.
3. Don’t use Hyper-V Dynamic Memory
Dynamic Memory is a great feature that is included with Hyper-V on Windows Server 2008 R2 SP1. It allows a physical host to treat memory as a shared resource, and memory can be given or taken away from a VM based on current memory demand and use.
The problem is, it doesn’t work well for Exchange servers and is not supported. Like other enterprise-grade Microsoft applications, Exchange 2010 is optimized and has memory-caching capabilities. If Exchange 2010 can’t completely control the amount of memory available to the machine, performance will suffer. Bottom line, make sure to disable dynamic memory on your Exchange VMs.
4. Think twice about VM placement in high-availability scenarios
Something else that changed with Exchange Server 2010 SP1 was Microsoft’s support stance on high availability in virtual environments. Virtualized mailbox servers can now be part of a database availability group (DAG), even though they’re hosted on clustered Hyper-V servers. This was unsupported in Exchange 2010 RTM. Therefore, as long as you’re running Exchange 2010 SP1 or later, it’s fine to take a virtual DAG node and Live Migrate it to another Hyper-V host.
That said, take the time to think about where you place VMs when you’re configuring Exchange 2010 for high availability on virtualized servers. For example, if you have two mailbox servers in a DAG, it doesn’t make sense to place both of those VMs on the same physical Hyper-V host. Instead, place them on individual hosts. This way, if one host fails, you still have a DAG member on another node that can quickly activate the databases, keep users online and save your company money.
The same goes for client access servers in a CAS array. Make sure that each server in a CAS array is located on its own Hyper-V host for the best availability.
5. Plan properly before deploying VMs
Architecting a solid Exchange 2010 design is no easy feat, and throwing virtualization into the mix adds another layer of complexity. Properly planning and sizing your virtual machines is the key to a successful implementation.
Be sure to use the Exchange 2010 Mailbox Server Role Requirements Calculator to help plan your Exchange deployment, whether it is partially or completely virtualized with Microsoft Hyper-V.
ABOUT THE AUTHOR
Mike Pfeiffer is a Microsoft Certified Master on Exchange 2010 and a Microsoft Exchange MVP. In addition to being an author and IT conference speaker, Mike delivers Exchange, Lync and PowerShell courses through Interface Technical Training in Phoenix, Ariz. You can find many of his thoughts online at mikepfeiffer.net, where he blogs regularly about Exchange Server and PowerShell-related topics.
Dig Deeper on Microsoft Exchange Server Performance