Flipping Bits

Option 4: Third Party Replication (Or: How Stella Got Her Single Copy Cluster Back)

This is the fifth and final post in a series about the various options to achieve HA and DR with Exchange 2010.  In the first, I broke the DAG into its basic components (Active Manager and DAG replication).  In the second, I gave a quick overview of Native DAG.  In the third, I covered a hybrid approach that combined DAG replication and Active Manager for local HA, and array/SAN based replication for remote site recovery.  In the fourth, I described an option that deploys Exchange in a standalone configuration and leverages a hypervisor to achieve local high availability.

This one will cover Exchange’s Third Party Replication.  This one definitely has a lot of cool factor in it.  It actually leverages DAG (in the form of Active Manager) with array or SAN-based replication technology.  You get all the automatic failover, live patching, Exchange-aware coolness of DAG, zero data loss, and you only have to deploy one copy of the data at each site.

Although synchronous operation is possible with both Options 2 and 3, this is the only option shown that combines synchronous replication with automatic failover.

This option will use a plugin from EMC to coordinate the replication engine with Active Manager. This would be either Replication Enabler for Exchange 2010 (free!), or AutoStart 5.3 with the Exchange 2010 module. This option can also use a virtualization platform like Hyper-V or VMware, but a hypervisor is not necessary to leverage the benefits of this option.

Here are the cost factors:

• Storage: 2
• Network: 2

Architects and managers will typically consider this option when:

• Lossless, automatic failover is required
• Minimal hardware footprint is desired
• There is minimal latency between the sites
• A hardware VSS protection scheme is available for rapid recovery in the event of database corruption
• Live patching is required

Option 3: Virtualized Host Clustering

This is the fourth in a series of posts about the various options to achieve HA and DR with Exchange 2010.  In the first, I broke the DAG into its basic components (Active Manager and DAG replication).  In the second, I gave a quick overview of Native DAG.  In the third, I covered a hybrid approach that combined DAG replication and Active Manager for local HA, and array/SAN based replication for remote site recovery.

I call this option “Virtualized Host Clustering”, because like the Virtualized Local DAG option, this options leverages a hypervisor, but it leverages the HA capabilities of the hypervisor instead.  The Exchange mailbox role is deployed in a VM as a standalone server.  This is by far the least expensive option from all perspectives: acquisition, operation, complexity, footprint, and power.

As you can see, there are some clear cost benefits to this option. You are replicating only one copy of the database, and since the HA function is handled by the hypervisor, a second copy of the database is unnecessary. It’s also the most flexible option – the full suite of workload management tools provided by the hypervisor can be used, and we add a fourth potential replication engine – VPLEX.

I suppose it’s also worth noting that one does not necessarily need a virtualization layer to accomplish this. With the right operational recovery plan to replace the server and restore from backup, three nines (99.9% availability) could easily be achieved without any HA facility whatsoever (either at the application or hypervisor layer).

This is by far the least expensive option from all perspectives: acquisition, operation, complexity, footprint, and power.

Here are the cost factors broken down:

• Storage: 2
• Network: 2 (SRDF, MirrorView), .5 (RecoverPoint)

Administrators and managers will typically choose this option when want to:

• Minimize complexity of the deployment
• Use advanced virtualization features such as Live Migration/Vmotion, DRS, etc
• Achieve consistency with other line of business applications
• Control failover with scripts or tools like VMware Site Recovery Manager
• Control their RPO from zero data loss to minutes
• Have multiple recovery points at each site
• Control bandwidth utilized by replication
• Meet failover requirements not achievable with native Exchange’s Best Copy Selection

This solution is not without its drawbacks however.  Here are a couple of things to consider:

• This is the only option that where the administrator does not have the ability to do non-disruptive patching.  However, one should consider that boot times are pretty quick on virtual machines.  It’s very possible to achieve four 9’s (99.99% availability) with this solution despite the lack of live patching, and reboots can be scheduled for non-peak hours.
• Since only one copy of the data is available at each site, a rapid recovery mechanism for logical and physical failure modes is well advised.  This is usually achieved through hardware based snapshots or bookmarks at minimal cost.  It’s usually a good idea to have a rapid recovery scheme outside of the context of the application anyway, for a variety of reasons.

Option 2: Virtualized Local DAG

This is the third in a series of posts about the various options to achieve HA and DR with Exchange 2010.  In the first, I broke the DAG into its basic components (Active Manager and DAG replication).  In the second, I gave a quick overview of Native DAG.  In this post, I’m going to cover a pretty popular option for folks who’ve already made the decision to virtualize their Exchange environment.

I call it “Virtualized Local DAG” because it uses DAG replication and Active Manager for local HA, but third party technologies for remote replication and failover.

This configuration utilizes a hypervisor such as Hyper-V or VMware’s. A two member DAG group is created, and then both copies are replicated from one site to the other. It’s important to note that because HA is dealt with by Exchange natively, any HA or workload migration features offered by the hypervisor (such as VMHA, DRS, Live Migration and VMotion) should be disabled for the mailbox VMs (other Exchange roles can utilize those features).

As for the network cost, it’s going to be more expensive operationally – you’re replicating two copies of the databases and two copies of the logs, and the storage cost is identical to Native DAG Replication.  However, this can be mitigated through the use of interesting compression and data reduction techniques made available by products like RecoverPoint.

• Storage: 4
• Network: 4 (SRDF, MirrorView), 1 (RecoverPoint)

Why would anyone choose this option? Well first, the network cost isn’t much more than Native DAG replication when you need to make sure you can reseed your databases in a reasonable amount of time. And if you use a replication appliance like RecoverPoint, you can end up using even less bandwidth than Native DAG replication, owing to the very good compression and data reduction an appliance like that offers.

Basically, for customers who've decided to virtualize Exchange, and already have working replication technologies for other applications, this option offers a lot of flexibility, integration with their data center strategies, and costs nothing in terms of storage footprint when compared to traditional DAG.

Ultimately, people may choose this option when there’s a need for or concern about:

• Uptime while patching
• Simplified and coordinated failover of all Exchange roles and services
• The ability of the WAN to absorb re-seeding operations that will occur more frequently with log-based replication
• Better control of failover operations than what native Exchange’s Best Copy Selection can provide
• Full site failover of multiple applications (such as provided by PowerShell scripting with Hyper-V or VMware Site Recovery Manager)
• Consistency with other line of business applications
• Controllable RPO
• Synchronous replication (loss-less cross-site failover)
• Multiple recovery points are desired at each site
• Controllable bandwidth utilization
• Compliance and inclusion in a DR plan that includes other applications
• Business requirements that can’t be met by DAG replication or Active Manager