Published: 18 Apr 2012
Email is a tier-one application because end users depend on it. And users expect the Exchange infrastructure to provide email and collaboration 24/7. So how can administrators keep Exchange running without downtime? The answer: take advantage of high-availability and performance features -- in Exchange Server 2010, and in virtualization platforms like VMware vSphere or Microsoft Hyper-V.
But how? Here are six areas to focus on:
- hardware performance and availability
- Exchange performance and availability
- hypervisor performance features
- hypervisor high-availability features
- best practices
- third-party tools
Hardware performance and availability
No matter which tier-one applications your company runs, hardware and infrastructure design choices affect performance and availability. This selection and design work may have been done long ago by a predecessor or a consultant you don't know.
The factors that undercut performance may seem obvious. But some may blame a virtualization platform's hypervisor for poor Exchange performance when, in fact, old hardware is the problem. In addition, server and storage area network (SAN) hardware bottlenecks can cause performance problems just as easily as a hypervisor can.
Achieving availability and performance is always a balancing act between the amount of money you want to spend and the expected return. First, try to achieve solid performance for end users. Second, ensure that you have the capacity to meet future performance needs. Third, move on to availability, and ensure that your company is satisfied with the level of availability you have configured for the level of investment made in the infrastructure.
Also, since Exchange is a tier-one application, use tier-one servers, storage and data center infrastructure.
Here are a few more considerations related to hardware performance and availability:
- If you aren't familiar with the capacity and performance status of your servers and storage, it's important to get up to speed on these metrics. How much RAM do they have, and how many cores do the CPUs offer? What is the speed of your SAN fabric, and how many virtual machines (VMs) are on each logical unit number? What about utilization of servers and SANs? Do bottlenecks need to be addressed immediately?
- If the current infrastructure suffers from bottlenecks, what can you do to relieve them? Can you reposition VMs -- virtualization makes that easy -- to better balance the load? Can you consolidate tier-one apps on the highest-performance storage? Can you upgrade your servers or SAN -- or even replace them? Can you move to solid-state drives for storage of tier-one VMs?
- Other than performance, hardware availability needs to be investigated. What level of availability do your servers offer today? Do they have redundant power supplies that go to redundant battery backups, such as redundant generators? What about network paths? Do you have redundant core switches that servers can connect to? For storage paths, does your Fibre Channel infrastructure have redundant switches, and do you use redundant host bus adapters?
Exchange performance and availability features
Whether or not you have virtualized Exchange, you should always take advantage of the performance and availability features already built into it. It's worth investigating these Exchange 2010 performance and availability features:
- Exchange database availability groups (DAGs): Database availability groups are a hybrid of Exchange Server 2007's cluster continuous replication (CCR) and standby continuous replication (SCR). DAGs allow Exchange Server to seamlessly handle on-site and off-site data replication scenarios.
- Client access server (CAS) arrays: In Exchange 2010, clients no longer connect to a mailbox server but instead connect to a client access server. For this reason, organizations should create an array of client access servers in case their primary CAS arrays become unavailable.
- Network load balancing (NLB): This Windows Server feature allows a group of machines to take turns responding to requests, providing high availability (HA) in the event of a server failure.
- Mailbox database redundancy/mailbox copies: This feature allows you to create copies of databases on other servers.
Hypervisor performance features
Whether you use vSphere or Hyper-V to virtualize Exchange, don't just throw Exchange virtual machines in with all other VMs (like end-user desktops) and hope that everything works out.
Here are some hypervisor performance features to investigate:
- Resource controls: In vSphere, you can set resource reservations or limits on individual virtual machines (see Figure 1). For Exchange Server, you want to reserve memory for Exchange VMs to ensure that memory is always available -- and that other VMs don't take it away. You can also set the "shares" for Exchange VMs higher for memory, CPU and storage.
Figure 1: You can change resource controls for an individual Exchange VM.
- Resource pools: Just as you can place settings on a single VM, you can also create a resource pool inside a host or cluster and then create these allocations for all VMs in the pool. Thus, you can place all VMs in a resource pool in a cluster across multiple hosts and ensure that those Exchange VMs get the resources they need.
- Load-balanced clusters: Let's say that all Exchange VMs are in a cluster and that some aren't getting the resources they need. With Distributed Resource Scheduler (DRS), you can use vMotion to move a VM to another host where it will get those resources.
Performance and Resource Optimization (PRO) in Microsoft's Hyper-V uses System Center Virtual Machine Manager and System Center Operations Manager to identify overutilized VMs and take action. Consider using load-balanced clusters, which are already built into the virtualization hypervisor, to maintain consistent Exchange VM performance.
- Network load balancing: To avoid overloading network connections on a particular host, consider network load balancing (NLB) from the Windows OS or vSphere's network interface card teaming. You should consider the former if you run VMs with NLB in vSphere.
- Storage I/O Control (SIOC): VMware's SIOC prevents a host from overloading the storage path of a shared SAN to which all hosts are connected. It also looks at the storage shares assigned to each VM to ensure that each one gets the storage bandwidth (IOPS) that you specified.
- Network I/O Control (NIOC): Similar to SIOC, VMware's Network I/O Control provides quality of service (QoS) on the virtual network to ensure that critical traffic such as iSCSI traffic gets the bandwidth (IOPS) it needs. New in vSphere 5, you can configure custom traffic types, so you can define some as Exchange traffic (Figure 2).
Figure 2: You can monitor and tweak resource allocation for a vSphere resource pool.
While performance is not a hypervisor "feature," watch the performance of your virtual infrastructure to ensure that no resource area is overloaded. You can overcommit configured memory in vSphere and still be OK.
When active memory in use exceeds the memory of the physical host, however, memory optimization techniques like ballooning, compression and paging (the worst) will take effect. These techniques can slow performance, so keep Exchange "happy" by giving it the memory it needs.
Hypervisor high-availability features
In addition to protecting Exchange VMs with backup and disaster recovery options, focus on short-term availability solutions. What if a single virtualization host server fails? How can you get that VM back up and running as quickly as possible?
VMware's vSphere High Availability does exactly that. If a host server fails, VMs on that host are automatically restarted on another host in the cluster to minimize downtime. If you don't use DAGs, vSphere HA gets Exchange VMs back up. VMware says that it has tested this process and that vSphere HA and Microsoft DAGs can coexist to get Exchange VMs running faster in the event of a host failure.
But Microsoft doesn't support using vSphere HA for Exchange. Instead, the company recommends database availability groups. Exchange 2010 servers that use database availability groups no longer use traditional Microsoft Windows failover clustering.
Best practices for virtualized Exchange Server 2010
Just as with designing the infrastructure, you need to ensure that administrators have followed best practices for guaranteeing high performance with virtualized Exchange 2010.
For example, if Exchange VMs are configured with too many virtual CPUs, it can cause performance problems. In addition, are you configuring memory reservations for Exchange VMs to prevent memory shortages? Are you trying to use Windows 2008 R2 Dynamic Memory with Exchange 2010 (unsupported)?
You'll find answers on the proper ways to design virtualized Exchange in the following best practices guides:
- Best Practices for Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper-V
- Best Practices for Virtualizing Exchange Server 2010 using VMware vSphere
Third-party performance and availability tools
Once you’ve reviewed everything that your hypervisor and Exchange have to offer concerning performance and availability, what's next? Review third-party tools.
Third-party tools have their own pros and cons. The pros include the ability to select the best of breed for the task at hand, possibly getting more value for your investment, and the chance to get features you just can't get anywhere else.
On the flip side, these tools can become outdated with a vendor's latest release, they cost a premium compared with the tools built into the hypervisor and they sometimes have a narrow focus and short lifespan.
Examples of third-party performance monitoring and alerting tools include the following:
Luckily, for IT shops that use multiple hypervisors -- or those that are considering a switch -- more vendors now offer performance and availability tools with multi-hypervisor options. Most were only vSphere tools, though now they also support Hyper-V and XenServer.
I would check out performance tools that proactively monitor the virtual infrastructure and predict performance (and thus availability) problems before they happen. An example of one tool that is multi-hypervisor and predicts potential performance problems is vKernel's vOPS.
When it comes to performance and availability of virtualized Exchange servers, first ensure that tier-one applications like Exchange have the hardware infrastructure to perform well today and in the future. You can use third-party capacity bottleneck-identification tools and what-if capacity analysis tools to do that.
Next, ensure that all the best practices for your hypervisor have been fulfilled, where they make sense. That way, you will avoid running into some gotchas.
Third, check that your organization's expectations of availability are being met. Try to put all VMs under vSphere availability, but use Exchange-specific features for Exchange, and combine hypervisor and Exchange features when possible.
No matter your company's business, if it runs its own Exchange infrastructure, you have to ensure that it performs well around the clock. That is what users now expect. If you run Exchange virtually, consider hardware, Exchange features, hypervisor performance features, hypervisor availability features, best practices and third-party tools to keep Exchange humming along. Your reputation (and maybe your job) depends on it.
ABOUT THE AUTHOR
David Davis is the author of the best-selling 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.