There's a wealth of helpful information available to help admins make any instance of virtualized Exchange a happy...
one. However, many deployments run into the same problems: poor performance, service outages, unpleasant user experiences and even data loss. Here are five common mistakes many admins make when creating a virtual Exchange deployment.
Deployment mistake #1: Incorrectly configuring Exchange VMs
The most common error I see in Exchange virtual machines (VMs) is incorrectly configured VMs. Some examples include the following:
- Not having the right hypervisor tool version installed.
- Not disabling time sync with the hypervisor host.
- Not enough vCPUs.
- Not enough RAM or using dynamic RAM.
- Not configuring resource reservations on an overcrowded host.
- Consolidating too many roles, making the VM too big for the host.
- Not consolidating enough roles, making too many VMs.
- Leaving the page file set to defaults on a slow VHD.
Keep a close eye on your vCPU configurations. Many hosts -- especially those running earlier hypervisor versions -- will experience performance problems if any VM has more vCPUs than the physical number of cores on each processor.
Deployment mistake #2: Using improper data stores
Microsoft and hypervisor vendor best practice guides are clear; using file level storage for virtual Exchange Server data is not supported.
Sure, VMware has a performance paper that shows Exchange using virtual machine disk files (VMDKs) on a network file system (NFS) data store, but even that paper says it is not a guide for deployment and was only done to show the improvements in NFS throughput -- end of story.
This does not mean you cannot use VMDKs or virtual hard disks (VHDs) for Exchange VMs. That said, you may not want to use them in the first place, because they add a small amount of I/O overhead. If you do, make sure that the files are on volumes attached to the virtualization host via a block-level protocol such as SAS, SATA, SCSI, iSCSI, or Fibre Channel.
Remember, NFS and SMB/CIFS are not supported. Exchange does a lot of careful manipulation when it comes to file and metadata writes and reads. This is to ensure minimal data loss and optimal performance. A block-level protocol with proper write caching ensures that these steps work as designed.
With Exchange 2013, Microsoft now supports using Server Message Block 3.0 (SMB 3.0) with the hypervisor to store VM virtual hard drives that store Exchange data. The caveat here is that they must be fixed-length (full-size) hard drives, not expanding. You cannot use SMB 3.0 to mount file shares for Exchange data within the VM.
File-level protocols cannot make the proper assurances. Problems become catastrophes because file-level protocols unwittingly sabotaged Exchange's safety measures.
Deployment mistake #3: Incorrect networking
Virtualizing the client access server (CAS) and hub transport roles, or standalone mailbox servers, is relatively easy. When you virtualize a database availability group (DAG) however, your virtual networks could become an added complication. There are two main mistakes I often see people make:
- They use the wrong virtual network adapter. This is usually because the default VM build process requires specific properties that are only present in the legacy or compatibility interface.
- They assign the client and replication networks to the same virtual switch and host interface as each other, the host-storage interface or the host-management interfaces. Even on a low-traffic DAG member, this mistake can cause intermittent and untraceable cluster heartbeat instability.
The moral here is simple -- pay attention. Use the right type of interface for best performance and stability, and make sure to separate your client and replication networks using multiple host interfaces and virtual switches.
Deployment mistake #4: Improper role co-location
When Exchange Server roles exist on separate VMs, there is a risk for data loss if the VMs are on the same host. When a DAG member goes down and log files are missing, the activating DAG member tries to restore the data from the transport dumpsters on the hub transport servers. If the key hub transport server was on the same host, data is lost and the database will not fail over.
The easiest way to avoid this mistake is to deploy multi-role (think mailbox, CAS and hub transport) Exchange VMs. The caveat here is that doing so drives up VM resource requirements. Therefore, many admins are skeptical at the prospect of doing so.
Deployment mistake 5: Snapshot-based backup
VM snapshots are a compelling and easy backup story. However, they're also a great way to destroy Exchange data, not to mention the fact that they're not supported.
So why are snapshots bad? Consider what happens when a VM snapshot is restored:
- The memory state is restored, but is not consistent with Active Directory or the rest of the organization.
- The data is inconsistent and must be checked at best or is lost. This requires database reseeds for all copies.
- If all the DAG members must be restored, there is no consistent data copy.
In the long run, VM snapshots end up creating more work than they save.
About the author
Devin Ganger is a messaging architect and technical writer with more than 15 years of experience in administering messaging systems and Windows, Unix and TCP/IP networks. Today, he works primarily with Exchange Server, Windows Active Directory and related Microsoft and third-party technologies. Ganger was recognized as a Microsoft MVP for Exchange Server from 2007 to 2011.