High-availability mistakes to avoid when virtualizing Exchange 2010
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
When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by Exchange professionals today working with Exchange, Outlook and other related technologies.
Margie Semilof, Editorial Director
Premium Access
Register now for unlimited access to our premium content across our network of over 70 information Technology web sites.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy
Dig Deeper
-
People who read this also read...
-
This was first published in October 2010
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.
Disclaimer:
Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
