Do this before virtualizing Exchange Server 2010

Step 1: Select and verify a hypervisor
Microsoft doesn’t support every configuration of Exchange Server running on a hypervisor. The company recognizes that Exchange is a high-priority workload that consumes a lot of resources, so it places limits on what it allows you to virtualize.

Microsoft supports Exchange 2010 on hypervisors that have been validated by the Windows Server Virtualization Validation Program. Microsoft hasn’t validated every virtual platform, but most major products have been approved, including Microsoft Hyper-V R2, VMware vSphere ESXi 4.1 and XenServer 5.6. Verify that your hypervisor is on the list.

Step 2: Determine your virtual Exchange design
Even if you’re using an approved hypervisor, not all Exchange designs are supported in virtual environments. Microsoft will support Exchange Server 2010 on production hardware only when the following conditions are true:

• The VM is running Windows Server 2008 SP2 or Windows Server 2008 R2. Microsoft will likely recommend Windows Server 2008 R2 SP1 once it has been released.

• The VM is not running the Unified Messaging (UM) server role. Microsoft supports each of Exchange’s other server roles in a virtual environment, but has concerns about performance for virtualized UM.

  A UM server requires substantial processing power with little tolerance for processing latency, which may not be guaranteed in a virtual environment. In short, keep your UM servers physical -- at least for now.

• The virtual machine is not using dynamically expanding virtual hard disk files such as VHD or VMDK files. Disk files can be either SCSI pass-through or iSCSI, but must be block-level storage. Microsoft does not support the use of network-attached storage (NAS) for Exchange Server.
• The VM does not use differencing disks, delta disks, linked clones or hypervisor-layer snapshots. These mechanisms link virtual hard disks to create dependencies that could affect Exchange functionality and possibly cause it to fail down the road. Pay particular attention to the lack of support for disk snapshots; you should never create hypervisor-layer snapshots of an Exchange server’s disks.
• The number of assigned virtual processors should never exceed two times the number of logical processors on the physical host. This 2:1 ratio refers to the number of virtual processors that have been assigned to all colocated VMs on the host. In this calculation, logical processors represent the number of processors per core times the number of cores on the server.

Step 3: Provision storage for Exchange data stores
Exchange needs processing and memory resources to accomplish its job, but storage provisioning is another important consideration. You’ll not only need to determine how much storage to provision, but also how that storage will be presented to the server.

Two mechanisms are common among essentially all hypervisors.

1. The creation and presentation of a virtual hard disk: This “encapsulated” storage brings the benefits of virtualized disks to your Exchange design. It can, however, introduce complexities with your backup schemes and incur a slight loss of performance over raw disks. Encapsulation also tends to create extremely large virtual hard disks that become difficult to manage in the long run.
2. The creation and presentation of “raw” storage such as a SCSI pass-through disk or Raw Disk Mapping: Raw disks do not see the benefits of virtual hard disks, but they may be easier for backup and restore, depending on the capabilities of your backup solution. Additionally, they don’t experience the same complexities that virtual hard disks do as they grow. Microsoft supports both types of disks for Exchange storage; however, it recommends the use of raw storage when it’s feasible.

With Exchange Server 2007, Microsoft did not support the direct connection of iSCSI storage into the VM. The official support guidelines have changed with Exchange 2010, now allowing iSCSI direct connections into virtual machines. However, even though it now allows this configuration, Microsoft does not recommend using it because the network stack inside the VM isn’t fully featured. It does not include the kinds of network accelerations enjoyed by physical hosts. You will get optimal performance and full supportability when iSCSI storage is configured on the host machine and presented to the VM as a pass-through disk.

For more information, check out Microsoft’s full storage support statement under the section titled Hardware Virtualization.

Step 4: Design Exchange Server for high availability
High-availability options are built into Exchange Server with database availability groups (DAGs). They are also internal to the hypervisor via live migration. Microsoft doesn’t support the use of both high-availability approaches in combination. More importantly, DAG cluster node failures during a live migration have been reported.

Live migration and DAGs are complementary technologies; both aim to accomplish the same task but do so at different levels of the application stack. Live migration works at the level of the entire VM. DAGs, on the other hand, are application-specific instances of database clustering.

DAGs provide a superior level of service specific to Exchange. You can create multiple DAGs for each data store. DAGs can also be tiered to support failover and disaster recovery situations as well as the additional requirements of data archival. Thus, experts often suggest that virtualized Exchange environments leverage DAGs over and above live migration as a solution for database high availability.

Step 5: Guarantee Exchange Server performance
Virtualization makes financial sense because it allows multiple VMs to share physical server resources. However, the laws of physics always apply.

Exchange’s various server roles can require substantial processing power and memory to accomplish their tasks without taking a performance hit. On the other hand, combining too many VMs on the same server can create contention as they vie for resources.

Your virtualized Exchange design should effectively monitor server performance to ensure that resource contention does not occur. Make sure Exchange has a minimum service level by setting resource reservations -- minimum levels of resources guaranteed to specific servers.

And since Exchange is memory-intensive, ensuring that hypervisor memory overcommitment doesn’t affect the server’s memory needs will also preserve its service levels. Don’t overcommit host memory until Exchange’s memory usage stabilizes and you have a good understanding of how much memory it actually needs.

Once you’ve completed these five planning steps, you can begin clicking through the virtual Exchange installation. Choosing New -> Virtual Machine is, for the most part, the only extra step you need.

For additional help, visit Microsoft’s Exchange documentation. Also, be sure to pay attention to Microsoft’s specific hardware virtualization requirements.

New information was recently added to this tip.

ABOUT THE AUTHOR:

Greg Shields, MVP, is a partner and principal technologist with Concentrated Technology. An IT industry analyst, author, speaker and trainer, you can find Greg at concentratedtech.com.