In-Depth
The Ultimate Virtualized Machine: Exchange Server
Virtualizing the Microsoft e-mail platform can yield infrastructure savings, and it's not as risky as some IT pros fear -- if done right.
Despite the potential for huge cost savings, many IT pros have avoided virtualizing their Microsoft Exchange infrastructures, fearing Exchange would become less reliable. And if Exchange stops working, the company stops working -- and so does the IT person who decided to virtualize it.
Fear not. If Exchange is virtualized properly within Microsoft support guidelines, you have no reason for concern. Do you think the Microsoft Exchange team would go out of its way to sabotage its own success? Exchange is known as one of the most stable solutions and is the most utilized e-mail system globally. Redmond would never give the green light on virtualizing Exchange unless there was a solid way to do so without sacrificing reliability and performance.
The fact is many shops are running Exchange and other server applications on hardware that's underutilized. So they're running too many boxes with too much CPU and memory. When looking at your infrastructure collectively, the best way to reduce energy and maintenance costs is to combine systems through virtualization. And in the process you typically get all the cool admin features that come from those who deploy private clouds.
When looking at the entire spectrum of servers you might want to virtualize, Exchange should be high on your list, considering how mission-critical it is. To ensure higher availability of Exchange, you need to ensure N+1 redundancy -- that is, components (N) have at least one extra (+1) -- so you're looking at multiple Exchange Servers, which can get costly on all those underutilized systems. By virtualizing your Exchange Server roles you can ensure redundancy without excessive costs.
When it comes to virtualizing Exchange, there might be some questions, concerns or myths that keep you up at night, so let's resolve them.
What server virtualization program is best for Exchange?
We could endlessly hash out the performance and feature specs. In the end, you want to know if your solution -- such as Microsoft Hyper-V and VMware vSphere, among others -- is better than the competitive VM platform. It's going to come down to more of a religious battle than anything else. Microsoft has a Server Virtualization Validation Program that reviews potential vendors and determines if the vendor configurations fit the requirements. All the main ones are listed in the program. There might be differing advice from these vendors on how to virtualize Exchange, however, so in the end it's best to follow the guidelines Microsoft recommends.
There's another angle here you might want to consider with regard to virtualizing Exchange and the platform you choose. You might have VMs for other applications running on the same system, which could affect which virtualization solution you choose. In that scenario, vSphere has additional features when compared to Hyper-V that may make for a better argument (though the cost is typically greater as well). With the new Microsoft Windows Server 2012 we'll have to revisit virtualization features with Exchange -- especially when the company releases Exchange Server 2013 next year. Whether or not you plan to move to Exchange Server 2013, it bears noting there will be no direct migration from Exchange Server 2003 to Exchange Server 2013 support, so you're looking at moving first to Exchange Server 2007 or 2010 and then to 2013.
David Davis, a VMware vExpert and columnist for Redmond sister publication Virtualization Review, believes the debate between vSphere and Hyper-V isn't religious but more of a logical list of pros and cons. Davis says it comes down to cost, feature set, educational options, third-party support and tools, and the scope of the product line. I'd agree, but in the end we'd still end up in a religious debate because our focus is different. He's looking at which solution is best overall. I'm willing to concede feature sets and product line scope for a more cost-effective solution, combined with which company I feel has the ability to win the future (Microsoft, in my opinion). For a true cost and feature comparison, check out the "Agnostic Virtualization Comparison."
If you do choose Hyper-V, you also need to decide whether to stick with the more widely deployed Hyper-V version 2, which is built into Windows Server 2008 and Windows Server 2008 R2, or to go with the newest version, Hyper-V version 3, which comes in the new Windows Server 2012, released in September. Where the enhancement to Hyper-V version 3 really comes into play is if you use a parent Windows Server 2012 system to host child VMs. Here, running Exchange will be more scalable. The chart illustrates this point.
Microsoft Technical Evangelist Keith Mayer is bullish on the scalability improvements Hyper-V version 3 brings to Exchange. "The increased VM resource densities in Hyper-V [version] 3 of up to 64 virtual processors and 1TB RAM per virtual machine will be a big boost to virtualizing mission-critical, heavy-duty workloads like Exchange mailbox server roles and multi-role servers," Mayer wrote in the late-August blog post, "Best Practices for Virtualizing Microsoft Exchange 2010."
Can I virtualize all five server roles: Mailbox, Client Access, Hub Transport, Unified Messaging and Edge Transport?
Not too long ago my answer would've been, "Yes you can, but Microsoft won't support it." The Unified Messaging role was one of those roles that didn't get support until after Exchange Server 2010 SP1 and now Exchange Server 2010 SP2. There was a media component that apparently was cleared for virtualization. That doesn't mean IT pros didn't virtualize the role. (They did, and it worked fine with Hyper-V version 2.) It just means it wasn't part of the support policy. This has been resolved by Microsoft, and now you certainly can virtualize the Unified Messaging role -- and have support if you follow the guidance. According to the guidelines, Microsoft wants you to have four virtual processors for the VM (with memory sized appropriately) and four physical processor cores available to the VM at all times (so no processor oversubscribing). Remember, a virtual CPU represents one core of a physical CPU, not an entire physical CPU.
How does virtualization affect Exchange performance?
This really depends on what you do. Some folks purchase a monster system that would normally be underutilized if running a single Exchange Server. Then they use virtualization and deploy multiple systems only to overutilize the hardware with VM sprawl. So rather than giving Exchange the required amount of CPU and memory allocation, they cheat the server and low-ball the memory, thinking they can add it at any time they need.
Can't I just use dynamic memory or over-commit to fix this problem?
The Exchange Mailbox role is designed to use as much RAM as you give it for buffering and caching, and it will only give up that RAM if there are other applications battling with Exchange for it. Therefore, Microsoft recommends you turn off memory oversubscription or dynamic memory because Exchange is designed to work better with static memory sizes that conform to the support policy. This is especially the case when it comes to the Mailbox server role. Size your environment accordingly. Sizing is made easier by using the requirements calculator.
Are you saying there's no performance hit with virtualization?
Exchange MVP Clint Boessen explained it well in his blog post, "Pitfalls to Virtualizing Exchange 2010", when he wrote: "Exchange performs best when it can interact with the physical components of a server directly. If you disagree with this statement that's usually a symptom exhibited right after a VMware conference -- hopefully it will go away." It's a funny, but true, line. Obviously performance will be different (less than) what it would be if you ran Exchange on a physical box with the same allocated resources. And the impact will depend on so many different factors that nobody can give you a magic -- "it should be a 5 percent impact" -- promise that makes you sigh with relief.
What's the best way to virtualize the Mailbox role in terms of storage?
When you're working with a lab and virtualizing Exchange, there's nothing wrong with using fixed virtual hard disks (VHDs) on the system. Even smaller environments can use fixed VHDs. (Dynamically expanding disks or disks that use some kind of differencing or delta mechanisms are not supported.) But fixed VHDs aren't considered the best method. Rather, you want to go with SCSI pass-through storage or iSCSI storage. This will give you the best disk I/O performance.
Any tips for Exchange database availability groups (DAGs) and virtualization?
Don't put a whole DAG on a single server. Though this sounds ridiculous, I've seen it done. A person sets up a two- or three-server DAG with virtualized Mailbox servers and places them all on the same physical server. Talk about missing the single-point-of-failure purpose of a DAG. There are a lot of ways to use DAGs and virtualization. Maybe you aren't comfortable yet with virtualizing your Mailbox server role. Fine -- keep the active copy for your DAG on a physical server and place a virtualized Exchange Server in your environment to hold your passive copy or lagged copy. DAG design can be a subject unto itself, but the point is make sure you split up your virtualized servers on two or more separate physical machines.
What failover options are provided for entire servers?
Microsoft recommends you follow its directions with regard to high availability for the Mailbox server role through DAG, and non-Mailbox server roles through redundancy, load balancers and so forth. However, this question really calls into play the issue of live migrations or quick migrations, which VMware folks refer to as vMotion, while others have different terms. Here's what Microsoft says it supports, according to the Exchange Team Blog:
"Exchange Server virtual machines (including Exchange Mailbox virtual machines that are part of a DAG) may be combined with host-based failover clustering and migration technology, as long as the virtual machines are configured such that they will not save and restore state on disk when moved, or taken offline. All failover activity must result in a cold boot when the virtual machine is activated on the target node. All planned migration must either result in shutdown and cold boot, or an online migration that makes use of a technology like Hyper-V Live Migration.
"Hypervisor migration of virtual machines is supported by the hypervisor vendor; therefore, you must ensure that your hypervisor vendor has tested and supports migration of Exchange virtual machines. Microsoft supports Hyper-V live migration of these virtual machines."
The Exchange Team is effectively saying it supports the Hyper-V quick migration feature (not live migration or VMware vMotion or others). And they aren't saying this should be utilized as a failover move, but more as a planned move or possibly a load-balancing strategy for your servers (but not related to failures). With failure scenarios they want you to stick with the existing options mentioned earlier. So, as long as the VM is coming up from a cold boot on the new host and it isn't coming up from a saved state persisted on disk, it should be fine. Especially with regard to DAG members, this is key to avoid having the system come up as "stale."