Pros and Cons of Exchange CCR for Disaster Recovery

Exchange 2007 Cluster Continuous Replication (CCR) technology is an excellent improvement in Microsoft clustering technology. It removes the need to have both nodes of the cluster connected to SAN for shared storage access.

However, there are three major points that restrict CCR’s high-availability/disaster-recovery value:

  • CCR requires both nodes to be in close physical proximity because both nodes need to be on the same IP subnet, in the same AD site, and have high-bandwidth/low-latency connectivity between each other and with the majority quorum node.
  • It does not work with the standard Exchange license, only with the more expensive Enterprise Edition license.
  • It requires 2x the hardware (one for active, one for passive node), with both nodes having to be new 64-bit capable platforms.

What’s missing, from the disaster recovery standpoint, is:

  • Multisite, cross-subnet replication; in other words, no geo-diverse locations for true DR.
  • Tolerance of WAN-quality connectivity.
  • Mailbox-level granularity.

Microsoft was motivated to deliver CCR to achieve the following purposes:

  • Remove the need for a SAN back end, and enable lower-cost storage.
  • Deliver "out-of-the-box" replication – through log shipping.
  • Enable offline operations (tape backup, journaling) from the passive Exchange server to deal with the larger scalability of Exchange 2007 implementations.

The impact on customer choices for replication solutions is that file- and block-level replication products are no longer necessary if a customer were to select CCR.

For an example of a thoroughgoing disaster recovery system for Exchange, check out Cemaphore’s MailShadow.

David Ferris, with thanks to Cemaphore’s Marty Hollander

One Comment

  1. Ajesh
    Posted August 19, 2007 at 8:03 PM | Permalink

    You have mentioned that the hardware requirement is 2X , but since hubtransport role cannot be on a clustered mailbox , is not the reuirement 3X and wont we require to buy 3 exchange licenses.

  2. Posted January 16, 2008 at 1:01 AM | Permalink

    Actually the hub transport role can be on any server and does not need to be an exchange server as it is part of the cluster. So only the two exchange licenses would be required.

    Some good videos on how CCR and Majority node set works:
    http://msexchangeteam.com/videos/9/drandha/entry428628.aspx

    The company I work for, Double-Take, resolves two of the issues but not the Mailbox-Level Granularity mentioned. Not sure why you would need that either. You are protecting the entire server. So if the active node goes down then you would bring up the passive node bringing up all of the databases.

    Maybe you could go into more detail why the Mailbox-level granularity would be important in a DR or HA configuration?

  3. Posted July 18, 2008 at 12:27 PM | Permalink

    Ajesh is correct. A Hub Transport absolutely needs to be an Exchange server. Additionally, only the mailbox role can reside on the clustered nodes.

Post a comment

You must be logged in to post a comment. To comment, first join our community.