Tech ONTAP Articles
Tech ONTAP Articles
When you think about running Microsoft® Exchange 2010 on VMware®, it's easy to come up with good reasons for doing so:
Despite these and other advantages, there are several questions that I hear almost every time I talk to people about running Exchange on VMware. In this article, I'm going to try and address the most common concerns and provide some best practices associated with running Exchange in joint VMware and NetApp® environments. Can I Get Support?The question of support comes up a lot, since Microsoft offers competing virtualization products. Microsoft made two recent changes to its licensing and support policies for VMware that address many of the lingering concerns:
In addition to SVVP, you can also qualify for direct support of virtualized Microsoft applications if you contract for the Microsoft Services Premier Support Program. Support might also be available through your server OEM vendor, VMware Global Support Services (GSS), and Technical Support Alliance Network (TSANet). You can learn more about how to get support in the Microsoft Exchange 2010 on VMware Support and Licensing Guide. Will Exchange on VMware Perform?Measured Performance For critical applications such as Exchange, everyone knows what performance to expect from a physical server, but concerns about performance on virtualized servers still linger. The best way to satisfy yourself that you won't have any performance surprises when you virtualize Exchange is to look at the extensive performance testing that has been done by both VMware and NetApp. Most of this work was done with Exchange 2007, but I think-especially given the significant I/O reduction from Exchange 2007 to Exchange 2010-that you can be pretty confident that if performance was fine for Exchange 2007, it will be good for Exchange 2010. Figure 1 provides a summary of Exchange on VMware performance. As you can see, virtual performance is always within 5% of physical performance. Even with 4,000 users, CPU load only reached 25%. The number of heavy users scaled linearly with the addition of CPUs in both the physical and virtual cases. Figure 1) Summary of Exchange 2007 performance in virtual versus physical environments. For more details on performance measurements, you can refer to a recent VMware white paper. VMware Best Practices VMware has developed an extensive body of best practices for using Exchange in VMware environments. These best practices are summarized here. For full details, refer to the Microsoft Exchange 2010 on VMware Best Practices Guide. Best Practices for Virtual CPUS (vCPUs)
Best Practices for Virtual Memory
Best Practices for Networking
Best Practices for Resource Management and DRS
Storage Best Practices
Best Practices for Performance with NetApp Storage NetApp has developed additional best practices for using Exchange 2010 with NetApp storage. These were described in a recent Tech OnTap article as well as a detailed technical report and include the best ways to take advantage of NetApp storage efficiency capabilities. For instance, combining the use of NetApp deduplication and thin provisioning can produce from 40% to 60% storage savings in Exchange 2010 environments. Additional recent work focused on ways to optimize Exchange performance with NetApp storage. In benchmarking with Microsoft Exchange 2010, the addition of Flash Cache doubled the number of IOPs achieved and increased the supported number of mailboxes by 67%. These results will be described in TR-3865: "Using Flash Cache for Exchange 2010," scheduled for publication in September 2010. How Do I Do HA and DR?NOTE: Combining a Hypervisor HA or DR with Exchange DAG is currently not support by Microsoft. See: http://technet.microsoft.com/en-us/library/aa996719.aspx Creating flexible high-availability (HA) and disaster recovery (DR) configurations for Exchange 2010 is actually much simpler and less expensive in a virtualized environment. You have more options and more flexibility for data protection at all levels. In order to configure HA and DR, you first have to understand the significant changes that Microsoft made in its native resiliency options for Exchange 2010. To replace the server and data resiliency options of earlier versions of Exchange, Microsoft implemented the database availability group (DAG). The DAG uses the same log shipping capability that was used in cluster continuous replication (CCR) in Exchange 2007. A DAG consists of 2 to 16 mailbox servers. Each mailbox server can hold one or more active or passive copies of a database. Each database has a separate status, so one server can host copies of multiple databases and only have some of those copies active at one time. The DAG uses a new Exchange component called Active Manager. Active Manager facilitates failover and failback. In the event of a failure (including a failure in underlying storage or storage connectivity), Exchange 2010 "promotes" one of the copies of the database to active status; the mailbox role then takes up the task of serving up the mailboxes on that database. Failover occurs in less than 30 seconds. Protecting Against Localized Failures VMware provides a number of possible mechanisms for protecting Exchange 2010 availability from local failures.
Protecting Against Sitewide Failures To protect against site failures, VMware suggests combining VMware Site Recovery Manager (SRM) with the DAG capability. The DAG provides local site protection, while storage-based replication such as NetApp SnapMirror® is used to keep a DR facility in sync with the main site. NetApp SnapManager® for Exchange can provide application-aware replication to make sure of consistency. If recovery is initiated at the DR facility, SRM automates and accelerates the recovery process. Contributors from both VMware and NetApp discussed the details of DR for Microsoft applications (including Exchange) using SRM in a recent Tech OnTap Roundtable. Figure 2) Replication architecture for SRM with NetApp SnapMirror and SnapManager software. These and other methods for HA and DR are described in detail in Microsoft Exchange 2010 on VMware: Availability and Recovery Options. NetApp Best Practices NetApp has established a number of best practices to keep in mind with Exchange environments that use DAGs:
ConclusionAdoption rates of Exchange 2010 have been high, and a lot of attention is being paid to virtualization. VMware has worked to develop an extensive collection of reference material and other resources to help you succeed when you virtualize Exchange 2010. You can access the full collection here. There's a lot of information there on capacity planning, sizing, and many other topics. VMware has also made significant efforts to test and develop Exchange solutions in conjunction with important partners such as NetApp. Tech OnTap has featured a number of recent articles that focus on virtualization of Exchange and other Microsoft applications. (See sidebar.) You can find the full collection of NetApp resources on the NetApp Exchange page. Got opinions about Exchange 2010 on VMware with NetApp storage? Ask questions, exchange ideas, and share your thoughts online in NetApp Communities. | Explore Highlights from VMworld 2010 This month's issue of Tech OnTap highlights solutions NetApp featured at VMworld 2010, with a special focus on partner integration. More on Virtualizing Exchange In a recent on-demand Webcast, industry experts discussed how you can save up to 35% or more with a more efficient, more robust Exchange infrastructure.
|
All content posted on the NetApp Community is publicly searchable and viewable. Participation in the NetApp Community is voluntary.
In accordance with our Code of Conduct and Community Terms of Use, DO NOT post or attach the following:
Continued non-compliance may result in NetApp Community account restrictions or termination.
Running DAG VMs with HA is now supported with Exchange 2010 SP1.
Read a summary of whats supported and whats not supported below
http://communities.vmware.com/message/1785090One important thing that I've picked up on technet but seems to be missing on most NetApp articles is that the exchange data should be residing on spindles that are SEPERATE from where the OS data reside. This effectively means that you have to create a completely seperate aggregate (with seperate, dedicated spindles) that is different from the aggregate where the VMFS or NFS volumes reside (that stores the Exchange VM's guest OS).
I personally dont see a point because with NetApp, the motto's always been one aggregate with large number of disks and carve multiple volumes out of it to provide better performance due to the increased spindle count and the data being spread amongst all spindles. However Microsoft reckons otherwise and it would be ideal for NetApp to clarify this from their perspective as well
Cheers
Chan