Home > Blogs > Virtualize Business Critical Applications > Monthly Archives: February 2012

Monthly Archives: February 2012

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

Messages sent or received per mailbox per day

Database cache per mailbox in megabytes (MB)

Single database copy (stand-alone) with estimated IOPS per mailbox

Multiple database copies (mailbox resiliency) with estimated IOPS per mailbox

Megacycles for active mailbox or stand-alone mailbox

Megacycles for passive mailbox

50

3

0.06

0.05

1

0.15

100

6

0.12

0.1

2

0.3

150

9

0.18

0.15

3

0.45

200

12

0.24

0.2

4

0.6

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

This blog is part of a series on Virtualizing Your Business Critical Applications with VMware. To learn more, including how VMware customers have successfully virtualized SAP, Oracle, Exchange, SQL and more, visit vmware.com/go/virtualizeyourapps.

Virtualizing Oracle 11gr2 RAC Databases on vSphere 5

Oracle DBAs considering to virtualize Oracle 11gr2 RAC should check out VMware vSphere 5 platform – VMware® vSphere® is the industry-leading virtualization platform for building cloud infrastructures. It enables users to run business-critical applications like Oracle with confidence and respond to business needs faster by taking advantage on the application and Infrastructure services that vSphere 5 provides.

As you all know, Oracle now provides support (Oracle MySupport ID: 249212.1 – RAC support added as of Nov 8, 2010) for Oracle 11gr2 RAC on VMware. VMware vSphere® 5.0 can handle the intensive workloads of business-critical applications – Let us discuss on a workload characterization study that was conducted on a four node Oracle 11g R2 RAC using VMware vSphere 5 with Cisco UCS servers and EMC VNX5500 Unified storage. See below the architecture that describes and demonstrates how the Oracle RAC deployment can sustain a heavy OLTP load without any degradation to transaction performance.

Below table describes the various components involved in this workload study.

Let us see below the few test result highlights described in this workload characterization study:

  • 24 hour workload Test: The following table summarizes results for 24 hour workload test. The above architecture was tested by subjecting it to a sustained heavy OLTP workload over a 24-hour period and results showed substantial transaction throughput without any degradation in performance.

  • Oracle RAC Node VM vMotion Test: The following SwingBench load generator screenshot shows the results during first and second vMotion. This also shows there is a minimal TPM impact during vMotion and ramps back to where it was before the vMotion, each vMotion took approx 64 seconds.

 

For more detailed read, check out the Oracle Databases on VMware vSphere® 5 – RAC Workload Characterization Study click on the image below

This blog is part of a series on Virtualizing Your Business Critical Applications with VMware.  To learn more, including how VMware customers have successfully virtualized SAP, Oracle, Exchange, SQL and more, visit www.vmware.com/go/virtualizeyourapps

 

Business Continuity and Disaster Recovery for Organizations of All Sizes

Whether you’re a large enterprise or small to midsized business, VMware solutions enable you to reduce costs and simplify your plans for business continuity and disaster recovery (BC/DR). 

For customer sites with up to 75 virtual machines: Save 40 percent off a 75-VM pack of VMware Site Recovery Manager™ Standard and vCenter Operations™ Enterprise.

For customer sites with more than 75 virtual machines: Introducing the Business Production Bundle, a 75-VM pack of Site Recovery Manager Enterprise, vCenter Operations Enterprise, and VMware vShield App. Purchase it now and receive 75 free Training Credits (value $7,500 USD). Training can be instructor-led or webbased and expires after one year.

For more information regarding this promotion, visit: http://www.vmware.com/go/bcdr-promo

The VMware Business Continuity/Disaster Recovery promotion is effective from February 1, 2012 to June 15, 2012.

2012-02-03_120504

This blog is part of a series on Virtualizing Your Business Critical Applications with VMware. To learn more, including how VMware customers have successfully virtualized SAP, Oracle, Exchange, SQL and more, visit vmware.com/go/virtualizeyourapps

Facts about Virtualizing Oracle (part 2 of 2: Oracle Licensing)

by Neal Mueller

Many Oracle products, including the database, are licensed by physical processor. This licensing model works well in a physical world, in which customers typically run one application per host and physical processors are easy to track. But this model is not well-adapted to a virtual world. VMware vSphere® enables you to consolidate multiple workloads in the form of virtual machines on a single host. Additionally, VMware enables you to move these virtual machines across hosts with VMware vMotion®, VMware Distributed Resource Scheduler (DRS) and High Availability (HA). When running products that are licensed by physical processor on vSphere, customers should ensure the following:

  • Virtual machines are running on hosts fully licensed for Oracle.
  • Virtual machine movement within a cluster is restricted to hosts that are fully licensed for Oracle.
  • Virtual machine movements are tracked so that customers are able to demonstrate compliance with Oracle licensing policies.

Many Oracle products are licensed by physical core or socket, and for these products Oracle does not have a virtual CPU-based licensing mechanism. In a vSphere environment, the consequence of Oracle’s licensing policy is that customers must license all physical cores or sockets in the vSphere host (fully licensed host). However, once the host is fully licensed, customers are allowed to run an unlimited number of virtual machines and application instances on that host without additional licenses.

As shown in the below graphic, customers can take advantage of VMware software’s many advanced features, such as Dynamic Resource Scheduler and vSphere HA, to get the highest possible infrastructure utilization and further reduce licensing costs. This this graphic we show consolidation of 16 processors into 4 processors and the resultant licensing savings of 16 licenses to 4 licenses. 

Vmware-vsphere-licensing-example-fig1

Read our technical white paper on Understanding Oracle Certification, Support and Licensing for VMware Environments to learn more.

 

This blog is part of a series on Virtualizing Your Business Critical Applications with VMware. To learn more, including how VMware customers have successfully virtualized SAP, Oracle, Exchange SQL and more, visit vmware.com/go/virtualizeyourapps.