Exchange Server 2007's new Cluster Continuous Replication (CCR) feature promises higher availability and improved failover capabilities. But implementing CCR as part of a disaster recovery (DR) scenario could be prohibitively expensive for many companies setting up remote DR sites.
CCR, in addition to Exchange's other new replication feature, Local Continuous Replication (LCR), asynchronously creates copies of storage groups and updates them via log shipping and replay functionality. Whereas LCR continuously replicates data across multiple disks within the same server, CCR replicates within a cluster from an active server to a passive one. Because Exchange 2007 allows each server to have its own storage rather than sharing within a cluster, they can be separated, theoretically, over long distances.
But to deploy CCR, several requirements must be met, including having all cluster nodes on the same IP subnet. While it's possible to set up virtual LANs, Microsoft requires, at minimum, a point-to-point, roundtrip latency of less than half a second. That level of WAN performance isn't common to most storage environments, and many users will have to invest heavily in additional bandwidth to meet that criteria.
"Half a second is fairly demanding for a typical WAN," says Colin Bush, an analyst at Ferris Research in San Francisco. "Unless you have the bandwidth to make sure you can consistently get a half-second roundtrip between the two servers, then it still won't work or it won't be as optimal."
"If this [half-second] latency requirement can't be met over the WAN, then a 'stretched' CCR approach is not ideal," notes Ed Banti, technical product manager, Exchange Server, Microsoft Unified Communications Group, in an email.
Another issue is that CCR is available only in the enterprise edition, which at an estimated price of $3,999 is approximately five times as expensive as the standard edition. Tack on bandwidth and licensing expenses to the requisite investment in 64-bit equipment, and using CCR for long-distance replication could wind up a tough sell.
Microsoft generally anticipates that users will deploy CCR and LCR locally; for example, by using CCR for failover within the same campus or between two servers, and by using LCR for failover between two storage controllers on the same server. For DR efforts, Banti suggests using the Standby Continuous Replication (SCR) feature, which will be available starting with Exchange Server 2007 Service Pack 1. According to Banti, users can implement CCR within their primary data center for high availability "along with SCR over the WAN to keep a remote copy up to date." SCR can replicate data to a standby server, which can be located locally or in a remote data center. That standby server can then be activated manually in the event of an active server failure.
Users who want to keep infrastructure and licensing costs down, do synchronous replication or prefer more granular mailbox replication will want to consider third-party products. For example, Mimosa Systems' NearPoint uses logging technology similar to Microsoft's log shipping to perform asynchronous replication, and Cemaphore Systems' MailShadow allows Exchange users to pick and choose which mailboxes must be replicated on a scheduled basis for DR.
"You need to figure out how big a priority [messaging recovery] is for you and how much money you're willing to spend on it," says Ferris Research's Bush. "No matter how you implement disaster recovery, there's a cost involved."