Server virtualization is a very common trend in almost all corporate data centers. In many cases virtualization provides a lot of benefits. Today I am going to talk about why virtualization is almost never the best option for Exchange 2013. I’ll address several aspects; supportability, hardware utilization, economy, and high availability.

Hardware Utilization:

One of the best reasons to virtualize any server or workload is hardware utilization. It is absolutely true that if we checked, most server hardware in most data centers is underutilized. Be it RAM, CPU, IOPS, hard drive, or network, very few applications can be deployed in a manner that will fully utilize a dedicated server’s hardware. This is not the case with a properly deployed Exchange 2013 environment.

It is no secret that Microsoft has focused a lot of development resources on Office 365. While Microsoft does not release numbers, it’s a pretty safe guess that Microsoft has more than one hundred million mailboxes deployed on Office 365. With that large of a deployment, you can bet that Microsoft is keenly interested in squeezing every bit of power out of every single server. I promise you, Microsoft gets every bit of performance out of every server they can. All the experience Microsoft has gained working to make Exchange Online as efficient as it can be benefits on premises deployments of Exchange 2013. In all but the smallest companies, a properly deployed Exchange 2013 environment can be architected to fully utilize dedicated hardware. Does that mean that I would recommend virtual Exchange 2013 servers for companies too small to justify dedicated hardware? Nope, in my opinion those companies are going to be best served by Exchange Online.

Supportability:

One of the greatest lessons I learned during my time in the United States Marine Corps can best be articulated with the acronym K.I.S.S. (Keep It Simple Stupid). I learned that there are lots of reasons for complex solutions when everything is going your way, but when the stuff hits the fan my old friend Mr. Murphy is going to pop up and make you pay. Every possible failure domain you introduce will come back to bite you when you least expect it, so my design philosophy is always to remove all the complexity I can while still achieving the project requirements. In the case of virtualization, the hyper visor is another layer where something can go wrong. I have seen a number of Exchange outages caused by poor virtualization, and even more outages that were extended by work that needed to be performed at the virtualization layer. I’m not saying virtual servers are always a problem for Exchange, but I am saying that, in my opinion, they rarely bring more benefit than complexity.

Another aspect of supportability to consider is Microsoft support. Does Exchange 2013 support virtualization? The answer is a lot more complex than you might think. Information on the Windows Server Virtual Server Validation Program can be found HERE. Explaining the entire program is beyond the scope of this blog post, but I can say that I see a lot of unsupported configurations out there. I have been asked about Exchange 2013 on Windows Azure and Amazon Web Services many times, and the answer is both are unsupported. If you’re thinking about using those services, or any other similar service, for your Exchange deployment I would ask you to reconsider.

Economy:

A good Exchange 2013 deployment is expensive. There are no two ways about it. Many of my customers have a considerable investment in their virtual environments with an eye to saving money on physical servers in the long run. While this may be a valid strategy for many applications and/or workloads, it just is not the case for Exchange 2013. In my somewhat less than humble opinion, it is generally more expensive to deploy Exchange 2013 in a virtual environment than on dedicated hardware.

Exchange 2013 uses a lot of CPU and RAM resources. So much so, that in most cases a properly sized Exchange 2013 server will take most or all of the resources on many virtual hosts. If one virtual server takes all or most of the resources on your host, the economy of the situation is obvious.

Another reason many customers give to virtualize Exchange 2013 is to take advantage of shared storage. The reason that Exchange 2013 uses so much CPU and RAM is so that it can use slow and inexpensive SATA drives. Using faster hard drives will not reduce the RAM and CPU requirements, but they also will not improve performance over 7500k SATA drives.

Several storage vendors claim their data duplication can reduce your storage footprint for Exchange, and thusly justify their solutions.  They’ll offer various ways to verify the results of their solutions, but I’m willing to bet none of them will offer eseutil /ms as the recommended method to very their results. Eseutil /ms will show that the deduplication these products offer is only able to duplicate the white space in an Exchange database.

High Availability:

Many customers want to virtualize their Exchange 2013 deployments to take advantage of the high availability they have engineered into their virtual solutions. The problem is that this solution generally won’t work, or at least won’t work nearly as well as the high availability options built into Exchange 2013.

Microsoft has put considerable design resources into making the high availability options in Exchange 2013 very robust and inexpensive to implement. A full breakdown of Exchange 2013 high availably design is going to be beyond the scope of this blog, but I will say that the performance and reliability you’ll get from the 3 major hypervisor solutions won’t even come close to the native protection you can get from Exchange 2013.

In summary, Exchange 2013 is an application that is best deployed on dedicated hardware. While I have seen customers with requirements that made virtual deployments more feasible, those requirements tend to be political in nature as opposed to technical.

I’m not saying that you can’t have a good Exchange 2013 deployment on virtual servers, but I am saying your deployment will most likely be better deployed on dedicated hardware.