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.
2013/03/25 § Leave a comment
Long time no read. Oh well, it’s not like anyone ever reads the bloody blog anyway. That’s gotta change though, this is a way for me to organize my thinking. Actually, it’s a way for me to think.
Today, I was reading Tony Redmond’s blog. Tony Redmond sounds like a fake name, something in a pulp fiction detective novel or, dare I say, an 80s porn movie. Ahem. Rest assured, that’s his real name. Tony is a good writer in general and quite good at transferring information on Exchange server. His take on stuck messages in the OWA ‘drafts’ folder makes for easy & informative reading. Take a look.
Mail flow in most Mail Transport Agents—I’m thinking specifically of Sendmail or Postfix—is straightforward. Microsoft, not wanting to ever be accused of simplicity, decided that this was the way it would take care of mail flow through Exchange Server 2013:
If you look closely, it all makes sense. By which I mean that, given the design considerations for something that does the work Exchange Server is supposed to do (a hell of a lot more than just SMTP) then implementing such a blitzkrieg of an algorithm is required.
With great complexity comes added responsibility however, and that is why no Exchange administrator will ever be out of work. Interested in reading more about Exchange 2013’s mail flow? Have at it.