Partager via

Exchange 2010 Virtualization distilled.

  • Article

Sizing:

1. Always size/spec servers and configure as if they were physical. For example, when configuring a DAG node, ensure that it has both a network interface dedicated for a MAPI network, and at least one NIC for a dedicated replication network.

2. Add 10-12% more resources (RAM/CPU) to account for virtualization overhead

This section below has been condensed from Best Practices Whitepaper for running Exchange on HyperV

https://www.microsoft.com/en-us/download/details.aspx?id=2428
1.Memory oversubscription or dynamic adjustment of virtual machine memory must be disabled for production Exchange servers guest machines. (page 11/Guest Memory)

2. Storage: (page 11/Storage)

Consider the following best practices when configuring Hyper-V guests:

    • Fixed VHDs are recommended for the virtual operating system.
    • Allow for a minimum of a 15-GB disk for the operating system, allow additional space for the paging file, management software, and crash recovery (dump) files. Then add Exchange server role space requirements.
    • Storage used by Exchange should be hosted in disk spindles that are separate from the storage that hosts the guest virtual machine's operating system.

  • For Hub Transport servers, correctly provision the necessary disk space needed for the message queue database, and logging operations.

For Mailbox servers, correctly provision the necessary disk space for databases, transaction logs,
the content index, and other logging operations

3. Locating Guests on hosts:

  • Never deploy Mailbox servers that are members of the same Database Availability Groups (DAGs) on the same root.
  • Never deploy all the Client Access Servers on the same root.
  • Never deploy all the Hub Transport servers on the same root.
  • Determine the workload requirements for each server and balance the workload across the Hyper-Vguest virtual machines.
  • Deploy the same Exchange roles across multiple physical server roots (to allow for load balancing and high availability).

4. Disable Dynamic Memory on the Exchange Guests (page 19)

Dynamic adjustment of virtual machine memory should must be disabled for production Exchange servers.

Below excerpted from the support policy at https://technet.microsoft.com/en-us/library/cc794548(v=EXCHG.80).aspx See also "Demystifying Exchange
Virtualization" https://blogs.technet.com/b/exchange/archive/2011/10/11/demystifying-exchange-2010-sp1-virtualization.aspx and "Understanding Exchange 2010
Virtualization"

Virtualization Scenarios That Are Not Supported

The following scenarios are not currently supported in production environments when virtualizing Exchange Server with Hyper-V:

•Snapshots, differencing/delta disks
•Virtual processor/physical processor core ratios greater than 2:1
•Applications running on the root virtual machine (excluding antivirus, backup, management software,etc.).
•Oversubscription of memory on the host machine/dynamic memory on the Exchange Server)*

*technically supported, but strongly not recommended**

**Really, it is strongly not recommended. I have gone to numerous virtualized Exchange environments where static assignment of RAM to Exchange mailbox guests was overlooked, or not configured.

In some environments, in the application log, event ID 906, source ESE, was evident:

"A significant portion of the database buffer cache has been written out to the system paging file. This may result in severe performance degradation." (duh…)

I have yet to see a 906 event that does not show that at least 80% of the DB cache has been flushed to page file. You really don't want this to happen, as the DB cache plays a major role in reducing IO.

Not only does flushing your DB cache, which can be anywhere from 2-92GB, increase disk IO, it further compounds your IO performance by not giving you the benefits of page coalescing, detracts from performance by increasing paging (how many of you have a spindle dedicated to your paging file?). That's just the start of performance issues, the first domino to fall, so to speak. If you don’t understand how this can happen, you may want to read about memory ballooning, as that other hyper visor vendor calls it. See this link for more information, keeping in mind that Exchange never has been able to deal with “hot-add” memory (or “hot-subtract”, as the case may be). Statically assigning RAM to the guest, should prevent that behavior from occurring.

Live Migration:

Exchange server virtual machines, including Exchange Mailbox virtual
machines that are part of a Database Availability Group (DAG), can 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 start when the virtual machine is activated on the target node

With Exchange 2010 SP1 (or later) deployed:

•All Exchange 2010 server roles, including Unified Messaging, are supported in a virtual machine.
•Unified Messaging virtual machines have the following special requirements:

?Four virtual processors are required for the virtual machine. Memory should be sized using standard best practices guidance.
?Four physical processor cores are available for use at all times by each Unified Messaging role virtual machine. This requirement means that no processor oversubscription can be in use. This requirement affects the ability of the Unified Messaging role virtual machine to utilize physical processor resources

•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.