Dissecting Database Availability Groups

I wanted to post a good picture of dissection at the beginning of this post, and it brought me back to middle school biology.  I was in eighth or ninth grade.  We are the World was a chart-topper, and the Asian Tiger Mosquito (awesome name for species, eh?) managed to migrate to Houston.  The important thing is that I wore an onion on my belt (which was the style of the time). 

Well, no, I guess that wasn't the most important thing.  The really important thing is that I couldn't find a picture of a real frog dissection that I want to post on this particular blog.  So I'll post this instead:

   

Onto what I'd really like to get at with this post:

DAG is not the only way to achieve high availability or remote site disaster recovery with Exchange 2010.  The reality is that there are quite a few options for replication and HA, and they run the gamut of requirements, from synchronous replication with automatic, lossless failover, to asynchronous replication with selectable recovery points, and from a single copy of the database(s) at each sites to whatever you choose.

So over the next few posts, I'll be going over the options that administrators and managers can consider when deploying Exchange 2010.  Most importantly, I'll be covering the factors that should be included in that consideration.

Before I start, I need to conceptually take Database Availability Groups (or DAG) apart, show a little bit about how the technology works, and define the terminology associated with it.

Most Exchange administrators have a good idea of what DAG is, and know enough about how it works to implement it.  But many administrators don't know that there are two components to DAG.  As with any true remote disaster recovery technology, there are two mechanisms:

1. There's a technology to replicate the data, known as the replication engine.  In native Exchange 2010, we'll call this "DAG Replication." It consists of asynchronous block-level replication of the transaction logs over an IP network between the members of a DAG.
2. There's a technique or technology that manages which copy of the data is "active."  A "technique" would be something a human does to decide which copy is active.  A "technology" is an automated process that determines which copy is active.  In Exchange 2010, this is a technology (in the form of a role) called Active Manager that runs on ALL Exchange mailbox servers (even standalone servers).

I'll take a few bullet points here to describe the various types of replication.  All replication I'll discuss in these posts involve taking the writes to storage or application, duplicating them, and sending them to another location.  If these locations are on the same server, disk, array, or site, it could be generally termed local replication.  If it's sent to another site, it can be called remote replication.  The different replication types are:

• Application replication:  This is where an application determines what is to be replicated at the application level.  In most cases, this is the application itself.  An example would be DAG replication, where writes to the Exchange transaction log are replicated to other members of the DAG.  Other examples would be SQL log shipping, Oracle DataGuard, or Active Directory replication.  An example where a middleware application determines what's to be replicated at the app level would be GoldenGate.
• Host replication:  This is where an agent running on the server, but outside the context of the application is configured to replicate data directed to one or more disks.  Examples of this type of replication would be Replistor, NSI Doubletake, and so forth.
• Array replication:  This is where the storage controller is configured to replicate writes destined for certain LUNs (or logical disks) configured on the array.  Examples of this type of replication would be EMC MirrorView and SRDF, NetApp SnapMirror and the like.
• SAN replication:  This is where the replication is handled by an appliance residing on a storage area network (SAN), but outside of the host or array.  Examples of this would include EMC RecoverPoint, NetApp ReplicatorX, IBM SVC, and technologies of that ilk.

Here's a little cartoon showing the types of replication:

Clearly, this is a simplification, and details differ between the implementation details the various vendors take.  Some third party products include both replication and application failover.  A book could be written on replication schemes, so I apologize for the brief treatment of the topic.  But all replication technologies I'm aware of can fit fairly comfortably in one of those four buckets, and it should suffice for this series of blog posts.

<whew>

Getting back to the topic at hand:

How can you replicate and fail over Exchange (other than DAG)?  Turns out there are a lot of possibilities.  The rules are pretty simple:

• You can't use DAG replication without Active Manager
• You should only use one high availability technique at a time

But you CAN use Active Manager without DAG replication.  This bears repeating:  You can get Exchange high availability without having multiple copies of your database.  And believe it or not, you don't have to use Active Manager at all.

I'm going to cover four different options for Exchange 2010 HA and replication, and this is not intended to be an exhaustive list: there are variants on each, and there might even be different methods.  Stay tuned for more...