As you move through the process of virtualizing Exchange Server 2010, remember that Exchange is a mission-critical...
enterprise application. A cautious, systematic approach will yield the best results. Follow the steps outlined below to minimize problems and streamline your Exchange 2010 virtualization project.
Step 1: Identify the five Exchange 2010 server roles
The ultimate goal here is to move each Exchange Server 2010 role from a physical server onto a virtual machine (VM). Remember, not all roles are required, and some roles can be combined.
The Exchange 2010 roles are:
- Mailbox server
- Client access server
- Unified messaging server
- Hub transport server
- Edge transport server
Note: In the original release of Exchange 2010, Microsoft did not support virtualization of the unified messaging server role because of its complexity and resource requirements. That changed with Exchange Server 2010 SP1.
Before moving forward, consider which roles you will be using, the total number of Exchange VMs you will need to create and any roles that could be combined into a single VM.
Step 2: Sizing Exchange virtual machines
Sizing the physical servers that you'll use for Exchange 2010 virtualization isn't very hard. In actual practice, most administrators purchase the largest server possible and add that server to their high availability (HA)/distributed resource scheduler (DRS) cluster, providing CPU and memory resources to all VMs, including the Exchange virtual machines. Consequently, your virtual host hardware may provide 196 GB of RAM and two 10-core CPUs per server, but your VM sizes will be much different.
So how do you size the virtual machines that will soon be running your Exchange infrastructure? Microsoft's Exchange Server Profile Analyzer (EPA) will help you predict your Exchange resource utilization. Armed with that information, you'll know exactly how to size your Exchange VMs through the hypervisor, further facilitating the Exchange 2010 virtualization process.
If you're creating a new virtualized Exchange 2010 environment and don't know what your Exchange resource utilization will be, you can use predefined formulas to size your mailbox VMs. To see the formulas and VM sizing tips, review VMware.com's Microsoft Exchange 2010 on VMware: Design and Sizing Examples.
Figure 1. VMware provides recommendations that can help Exchange admins provision virtual machines for their deployments.
VMware.com's guide explains how to scale your virtual Exchange infrastructure using building blocks. The idea is to deploy multiple smaller Exchange servers instead of a single (or a few) large Exchange Server VMs.
For example, Figure 1 illustrates what the resource demands might look like for 16,000 mailboxes. Once you have a physical resource perspective, you can allocate server resources to virtual machines to meet the recommended requirements.
As an alternative, performance monitoring tools can help you identify the resource utilization of physical Exchange servers. You can also use that data to provision Exchange role VMs.
Step 3: Configure vSphere and create Exchange VMs
At this point, you can configure your vSphere infrastructure for Exchange and create your Exchange VMs. Be sure to create a HA/DRS cluster across your production vSphere servers. This ensures that if a physical host fails, Exchange VMs will be restarted on another host automatically. This strategy also allows VMs to be migrated to another host (using a tool such as vMotion) if they aren't getting the resources they need on the current host.
When it comes to the VMs you'll need to create for Exchange, you should create a greater number of smaller VMs (instead of a few larger VMs). Also consider how much CPU and RAM you will assign to each.
Some other considerations include the following:
- Size your virtual machine storage based on the Exchange 2010 Mailbox Server Role Requirement Calculator.
- Set memory resource reservations on each VM equal to the memory configured for that VM so that no memory is overcommitted, only to be swapped back in later. This is inefficient and can impair performance on the VM and your Exchange 2010 virtualization project.
- Ensure that you have enough network interface cards and host bus adapters to support your Exchange VM needs. Connectivity is often overlooked with Exchange, and adequate access to the network and SAN will keep things running smoothly.
- Create a resource pool for your Exchange VMs. This puts some of the server's resources in reserve and prevents Exchange VMs from contending for resources along with all the other VMs in the infrastructure.
Read the full series
Check out the rest of this Exchange 2010 virtualization on VMware vSphere series
Step 4: Test and train
Now that you've created your Exchange VMs, it's time to test your configuration. Exchange VMs should communicate with one another, end users should be able to access email, and you should have a read on things through a performance monitoring tool.
Document the performance and be sure to check periodically. Changes in Exchange VM performance may require resource adjustments to your role VMs or other workload rebalancing across multiple servers.
Also, take time to confer with and train other IT administrators. Changes to administrative processes should be documented and communicated.
About the author
David Davis is the author of the VMware vSphere video training library from Train Signal (including the new vSphere 5 video training course). With more than 18 years of enterprise experience, Davis has written hundreds of virtualization-related articles for the Web and is a vExpert, a VMware Certified Professional, a VMware Certified Advanced Professional-Datacenter administration, and Cisco Certified Internetwork Expert #9369. His personal website is VMwareVideos.com.