Fakehosting Exchange

2013/03/26 § Leave a comment

I’m tired of virtualization. Literally. As in saying and typing virtualization. I am a big, big fan of the technology, mind. I’m just tired of that word.

In the coming months, I will be working on virtualizing (ugh) our Exchange server installation and there’s a need to find out how to “size” (ugh) the virtual infrastructure for smooth 2010 or 2013 operations.

David Davis (echo, echo) has good recommendations that I will be using to help me decide what goes into the VM/ESX host combination, a sample of which follows:

  • When allocating processors, only assign multiple virtual CPUs (vCPUs) if you can determine that your Exchange virtual machines (VMs) can really take advantage of the additional processors; otherwise, you’re wasting resources.Start with the smallest number of vCPUs and work your way up as more processors are needed.
  • Ensure that the total number of vCPUs assigned to all Exchange 2010 VMs is equal to (or less than) the total number of cores on the ESX host machine. If you assign more vCPUs to mission-critical VMs than the physical host has available, you are overcommitting CPUs, and taking a chance that your Exchange VMs won’t have CPU cycles when they’re needed. Instead of a 1:1 mapping of cores to vCPUs, use CPU reservations to protect those CPU resources for Exchange VMs.
  • Overcommitting memory with VMware vSphere is common — and even recommended — but don’t overcommit memory when virtualizing Exchange 2010. If you do, you’ll have to deal with memory ballooning, compression and paging — all of which will diminish performance.
  • Use storage multi-pathing to ensure storage area network (SAN) availability.VMware recommends providing a minimum of four paths from a VMware ESX host to a storage array, which means the host requires at least two host bus adapter (HBA) ports, two Fibre Channel ports and two SAN ports.
  • Allocate separate network adapters and networks for VMotion, VMware fault tolerant (FT) logging traffic and ESX console access management. Use at least two network adapters for Exchange production traffic to leverageVMware network interface card (NIC) teaming capabilities. Generally, at least four network adapters are recommended per ESX host.
  • Use the VMXNET3 virtual network adapter driver instead of the default E1000. In mission-critical VMs like Exchange 2010, the para-virtualized VMXNET3 will result in better performance. Also, ensure that VMware Toolsis installed on each VM as the VMXNET3 virtual NIC driver.
  • Don’t skimp on host server hardware. No amount of virtualization features can fix old or slow hardware.
  • When virtualizing Exchange 2010, make sure you’re up-to-date with the latest service pack.
  • Use vSphere High Availability (HA) to automatically restart your Exchange VMs in the event of a host failure.

Hold your nose, close your eyes and jump in for the rest.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading Fakehosting Exchange at /var/log.

meta

%d bloggers like this: