As enterprises decide whether to virtualize Exchange Server 2013, they need to examine their storage needs as well...
as which resources will be allocated when virtualizing the messaging platform. But the decision involves more than storage allocation. In the second part of this series, Exchange MVP Michael Van Horenbeeck discusses how data deduplication and high availability fit into the decision-making process.
Another important aspect of the storage discussion is data location. If you're using a storage area network in your virtual environment, it's likely that several instances of Exchange Server will live on the same underlying SAN. In a site-resilient setup, you'll likely have two SANs to cover for them.
If we consider the four-node Exchange Server example, all members of the same Database Availability Group (DAG), you'll have two servers hosted in one data center and another two in the other data center, with your data residing on the same SAN. A SAN outage would cause two Exchange Servers and data to fail simultaneously. While you still have two nodes left in the other data center, this scenario is less likely to happen with just-a-bunch-of-disks (JBOD) storage in different servers. Truth be told, it's not often that a SAN simply fails. But when it happens, it's a single point of failure -- not to mention a huge mess. Also, when using a SAN, you potentially undermine the high availability (HA) Exchange offers -- and that doesn't make much sense.
How high availability fits in
Virtual platforms allow you to easily move virtual machines (VMs) between hosts in a cluster. This can be useful when you're performing maintenance on one of the hosts, but it's critical for HA. Being able to move a VM from a failed host to another one ensures that the VM continues to work, despite the failed, underlying hardware.
To minimize the risk of a single host failure affecting more than one Exchange Server, you should not cohost Exchange Servers on the same physical hosts. You can make sure this doesn't happen by using anti-affinity rules, as they're called in the Hyper-V world. This ensures that certain VMs are always kept on separate hosts.
The virtual platform's capability to fail over a VM to another host is relevant only when the physical host is failing. Being able to move a VM to a different host doesn't prevent issues with the VM. And the platform's built-in HA is not enough to ensure an Exchange server remains available.
Instead, use Exchange's built-in data-protection features, such as DAGs. These features are fully application-aware and will make decisions based on the application's health. This means problems in the underlying hardware might cause Exchange to fail over a database on another Exchange Server and VM. Therefore, don't place Exchange VMs on the same server, especially when you combine Exchange's built-in HA features and the HA feature from the virtualization platform. You don't want Exchange to fail over to a VM that lives on the same (failing) host.
To virtualize or not to virtualize Exchange Server 2013?
I suggest admins run Exchange Server 2013 physically rather than virtually. On one hand, most organizations may have already invested in a virtual platform. If that virtual environment meets all the technical requirements, it might make sense to use it and cash in on the investments that were made.
However, there are technical limitations to consider, in addition to the cost of storage. All this, as well as the total cost of ownership, will likely be higher than they would be if you were using local JBOD storage.
It all depends on scale. The larger your organization is, the more sense it makes to run Exchange physically. When you dig into the so-called preferred architecture that Microsoft lays out, there's little room left to defend virtualization. However, there are many organizations just too small to deploy the preferred architecture. These organizations might be better candidates for virtualization, but they might also be the perfect fit for Office 365 and can avoid the pain of running Exchange on-premises all together.
About the author:
Michael Van Horenbeeck is a technology consultant, Microsoft Certified Trainer and Exchange MVP from Belgium, mainly working with Exchange Server, Office 365, Active Directory and a bit of Lync. He has been active in the industry for 12 years and is a frequent blogger, a member of the Belgian Unified Communications User Group Pro-Exchange and a regular contributor to The UC Architects podcast.