Your Guide to Virtualizing Exchange 2010 on vSphere (Part 1)

For a few years now we’ve been providing guidance on virtualizing Exchange on vSphere. Although not fully supported at the time, customers were looking for guidance to virtualizing Exchange 2003 and 2007 and so we created best practices guides and performance studies. Today we continue to provide best practices, design and sizing, and availability guides for Exchange 2010 on vSphere. With all of those resources out there one could ask, “What else is there to cover?” In this first posting of two I wanted to take a step back and look at some of the pre-requisites for designing an Exchange environment on vSphere. In Part 2 of this series I’ll jump forward to some design considerations to keep in mind when virtualizing Exchange on vSphere. What about the technical details in between pre-reqs and design considerations? We’ve got those well covered and I’ll provide links at the end of this article.

Microsoft Exchange Server, for most organizations, is the central communications stream and as such becomes critical to the daily operations of the business, or a business critical application. Unlike the typically virtualized workloads of days past, these business critical applications typically require a dedicated project staff and budgets, and are highly visible throughout the organization. Because of the importance of such a project to the organization proper planning is vital to ensure a successful outcome.

To aide in successful planning consider the following pre-requisites when beginning an Exchange design for deployment on vSphere.

Understand the business and technical requirements

Among the many technical requirements that must be followed when deploying Exchange and vSphere it is important to understand any technical and non-technical requirements placed by the organization. A few of the most common business requirements we encounter when designing a virtualized Exchange environment are listed below.

• High availability – What level of availability needs to be designed into the environment? Is there an SLA in place that requires services to be restored within a certain time period? With Exchange 2010 this is one of the most important decisions to be made at the beginning of the design process. The use of Database Availability Groups will dictate the amount of storage needed to house active and passive databases, as well as how many mailboxes can be supported per mailbox server. Is disaster recovery in scope?
• Supportability of the design – Those of us that have worked for large organizations know the importance of designing a supported solution, and more importantly the frustration of having support calls closed due to an unsupported configuration. When building the design keep support in mind and be sure to consult with your hardware and any other software vendors to make sure they will take your calls when problems arise.
• Scalability – Is the goal of the company to continue to grow or does the nature of the business keep the organization size stable? If this is a large environment do we need to consider deploying fewer larger virtual machines, or is it preferable to scale-out with smaller virtual machines. If this is a volatile environment do we need to have the capability to scale-out or up on demand using templates or hot-add technologies?
• Mailbox Size – Are there currently quotas in place or will they be introduced as part of this new design? Is there a limit to the amount of data that the proposed solution can handle? Does archiving need to be factored into the solution?
• Performance – What bolt-on accessories are in use in the current messaging environment and does their functionality need to be carried over? Many of these solutions will add overhead to the environment and their use needs to be accounted for when it comes time to size.

Analyze the current messaging environment

An Exchange 2010 sizing exercise is mostly based on the assumption that there is an understanding of the current usage of the messaging environment. If this is a greenfield environment it will be necessary to estimate what the usage will be and this can be very difficult. Typically I would recommend beginning with a medium to heavy workload, around 150 messages per day, per mailbox. The beauty of building on vSphere is that if it turns out that the environment was over-provisioned you can easily scale back and regain some compute resources for other projects.

If there is an existing Exchange environment you can download the Exchange Server Profile Analyzer to help understand the current messaging requirements. This tool can look at a single Exchange mailbox database or across an entire organization and report on user activity. Other ways to analyze the messaging activity within an organization include:

• Exchange message tracking logs
• Sendmail or Postfix logs
• Statistics from email anti-virus tools
• Logs from SPAM gateways
• Third-party email statistics tools

Regardless of which method is chosen, the desired outcome is to determine the average number of messages sent and received per mailbox per day. This is the primary method used by Microsoft to determine the amount of processor and storage resources each mailbox uses and the recommended amount of physical RAM that should be allocated for mailbox database cache. The table below from TechNet can be used to determine the amount of database cache, IOPS, and CPU estimates based on user activity.

Table 1. IO Profile Resource Utilization Estimate

Source: TechNet – Mailbox Server Processor Capacity Planning

Analyze the health of the current messaging and vSphere Environment

Before beginning an Exchange migration project, a full health check of the current Exchange environment, the vSphere environment, and any infrastructure dependencies should performed. Often times a new environment can help bring an underlying issue to the surface. Being able to identify these issues and resolve them before going into production can make a migration much smoother for the implementation team as well as the end users.

A number of tools are available to help make sure there are no glaring issues in the current environment.

• VMware HealthAnalyzer – captures data from the vSphere environment including configuration and utilization information to provide a health report card. Ask your VMware representative for more details on obtaining a health check using HealthAnalyzer.

• Exchange Best Practices Analyzer – The ExBPA is installed with the Exchange Management Console and can be used to quickly scan a particular server or the entire organization’s configuration against best practices. The report lists details about the configuration and offers explanations and guidance on how to fix common issues. Running the ExBPA is a must before placing any Exchange server into production and is recommended to run as part of routine maintenance.

Identify support and licensing options

With a business critical application like Exchange it is key to understand support and licensing considerations. Support for virtualizing Exchange has come a long way over the past few years. The Server Virtualization Validation Program provides mainstream support for running Exchange 2007 and 2010 on vSphere. Prior to going down the road of building a design it is a good idea to walk through the Support Policy Wizard on the Windows Server catalog web site to validate that the solution you are putting together is supported.

Figure 1. SVVP Support Policy Wizard

No matter the hypervisor used to virtualize Exchange 2010, the support requirements remain the same. The Exchange team at Microsoft outlines the requirements for virtualizing Exchange very well on the Exchange System Requirements TechNet page. These requirements must be reviewed and understood to be sure that the design meets Microsoft’s support guidance and to help avoid any confusion during a support request.

Exchange 2010 is licensed per server and client-access license, just as it is on physical. This is important to note as it may help determine whether you design using a scale-up or scale-out approach. Another licensing consideration is that of license mobility. Previously application licenses tied to a physical server could only migrate between physical servers once every 90 days. This was updated to allow application licenses to migrate between physical hosts within a server farm as needed. More information can be found in the Application Server License Mobility document. As always, we suggest you consult with your Microsoft representative to obtain the most accurate licensing information for your situation.

Thanks for making it this far. I hope you found the often overlooked pre-requisites for virtualizing Exchange 2010 on vSphere helpful. In Part 2 I will dive into some additional design considerations to keep in mind when virtualizing Exchange 2010 on vSphere. If you’ve missed any of the great resources we have on virtualizing Exchange 2010 on vSphere check out our resources page at the link below.

http://www.vmware.com/solutions/business-critical-apps/exchange/resources.html

-alex