The term highly-available tends to be overused in IT; practically every software vendor has introduced some type of high-availability features into their products and others have partnered with those that sell high-availability functionality as an option. Some have added resiliency features that aren’t true high-availability, even if they are marketed as such. This has made high availability a term that’s hard to pin down.
High availability in Exchange Server 2010 is no different. Exchange 2010’s HA features range from a heavy focus on database availability groups and database copies to a lighter focus on client access server arrays and network load balancing.
Mailbox high availability is made possible through the creation of mailbox copies in up to 16 different locations. A critical difference between Exchange Server 2010 and Exchange 2007 is that mailbox databases are no longer tied to their original server. Since the direct link between the mailbox server and mailbox database has been broken, mailboxes can be mounted anywhere.
The problem is that although Exchange 2010 gives administrators more options, they don’t always piece them together correctly. Don’t make these mistakes when creating your own highly-available virtual Exchange Server 2010 environment.
Mistake #1: No mailbox redundancy
Exchange Server 2010 mailbox copies and database availability groups can be extremely easy to use. Creating a new mailbox database copy requires little more than a copy of Exchange Server, ample storage space, the right level of network connectivity between servers and a few mouse clicks. Unfortunately, many organizations still don’t leverage this functionality. Admins commonly fail to plan for mailbox database redundancy.
One of Exchange Server 2010’s primary tenets is modular scalability. In previous versions of Exchange, HA required that you run mailbox servers on top of Windows server failover clustering. Although Windows failover clustering can support numerous applications on a single cluster, it has often suffered from having too many options and hardware requirements. With Exchange Server 2010, mailbox copies can be hosted on any Exchange server.
Combining database extensibility with virtualization creates some compelling options when designing an Exchange infrastructure. For example, if you’re not comfortable with virtualizing your mailbox servers, an alternative might be to virtualize only those servers that host passive databases.
These mailbox database copies are present for resiliency only, providing a secondary location for data to be housed in the event of a server loss. Users in your organization generally won’t interact with these databases, which significantly reduce virtual resource requirements.
Mistake #2: Combining Exchange high availability with virtual platform high availability
Most admins would never believe servers can have too much protection. Unfortunately, attempting to make your Exchange architecture too highly available can often cause supportability problems.
Microsoft’s statement of supportability for Exchange 2010 in a virtualized environment states, “Microsoft doesn't support combining Exchange high availability solutions (database availability groups [DAGs]) with hypervisor-based clustering, high availability or migration solutions. DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn't employ clustered root servers.”
Every production-worthy virtualization platform includes failover features. VMware has HA and its distributed resources scheduler (DRS); Microsoft has Live Migration and Windows failover clustering. These products represent hypervisor-based clustering options that fail over an entire virtual machine when a host dies. These are excellent solutions; however, implementing them on top of DAGs creates unnecessary complexity and eliminates support.
Mistake #3: Using virtual platform high availability instead of Exchange high availability
In most situations, you shouldn’t choose virtual platform HA over Exchange’s built-in high availability, specifically when it comes to mailbox databases. The complexities of Windows server failover clustering no longer contain Exchange 2010 mailboxes or tie them to specific mailbox servers. Therefore, the internal HA model seamlessly redirects users when problems occur.
The continuous replication approach to maintaining database copies has greatly improved in Exchange Server 2010 as well. Log shipping between databases no longer resides on server message block (SMB) and no longer uses a pull model.
Administrators can define specific TCP ports for the replication data stream, which can also be compressed or encrypted. Database caches are immediately available for use after a failover or after a switchover has been invoked.
Mistake #4: Neglecting high availability for client access and edge transport servers
The focus with Exchange often is on preserving mailboxes. It’s an honest effort since the heart of an Exchange organization resides within those mailboxes. But connecting users to their mailboxes requires more than just a mailbox server; forgetting that is another common mistake. The process also requires hub transport servers and client access servers.
If your Exchange organization spreads across multiple sites, you probably already have multiple hub transport servers in place. Those servers generally will fall back on each other in the event of a server loss, automatically creating the necessary HA from within their own communications.
However, client access servers and edge transport servers don’t operate the same way. High availability for client access servers is handled through load balancing using either a hardware load balancer or Windows network load balancing. High availability for edge transport servers can be enabled through DNS round-robin or through the use of multiple, weighted MX records.
ABOUT THE AUTHOR
Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Greg's Jack-of-all-Trades tips and tricks at www.ConcentratedTech.com.