Exchange Server 2007 also allows for a shared-nothing approach, in which the two nodes in a cluster do not access the same information. Cluster Continuous Replication (CCR) transfers replicated log files from the active node to the passive nodes using log file shipping, and replays the replicated log files into the copy of the database on the passive node.
Standby Continuous Replication (SCR) sources are plain mailbox servers -- standalone, SCC or CCR nodes -- that send transaction logs to their SCR targets. These targets may be mailbox servers and located remotely, where they're played into the copy of the information store running on that server. Failovers to the SCR target are initiated manually, instead of achieved automatically, as is the case with SCC and CCR clusters.
While an Exchange administrator may be confident that there is a server at that remote location with the necessary data on it, he or she may not be sure of the bandwidth being consumed by transferring that data to the remote data center. Storage administrators most likely can achieve tasks that are sent to the data center more efficiently. Additionally, you only have one set of data to deal with, while the storage administrators must deal with the remainder -- file data, databases, Exchange information stores, backups, clones, etc. If you have a SAN, then SCR probably isn't a necessary resiliency solution.
The SCR source transmits information one log file at a time (i.e., at the file level). Storage is replicated at the disk-block level; only changed blocks on the disk are transmitted to the second storage array. Likely, storage administrators have transferred this information to the other storage array more efficiently.
A Standby Continuous Replication target has a single recovery point. There is an in-built transaction log lag of 50 logs. This allows the SCR target to be brought up in an earlier state if there's a problem running stores on the original Exchange server. However, your SCR target can only be brought back to a single point in time. Storage administrators can present the Exchange server with snapshots of the production database.
When taken at regular intervals, these snapshots allow an Exchange administrator to choose when to recover to. If the database doesn't mount properly, an administrator can select an earlier snapshot and watch the logs play forward from that point. The Exchange administrator also can see which snapshots are viable since SAN management uses the ESEUTIL tool on the snapshot backup either before copying the blocks to the new location or after the blocks arrive.
Before worrying about how much data this consumes, consider that the initial snapshot represents 100% of the original data. Subsequent backups represent no more than the changed blocks, or deltas, rather than the entire store or sum total of log files generated since the last backup.
The destination server should still be configured and activated. However, it's less complex to have a replicated copy of the System State backup ready to restore onto prepared hardware than it is to configure and monitor an SCR environment.
The remote server assumes the identity of the failed server and obtains access to the appropriate Exchange databases. This would occur as part of an organization's disaster recovery (DR) scenario; no additional administrator tasks must be performed.
As you can see, Standby Continuous Replication has its place. It makes sense as an application-level solution in situations where remote locations store data on direct-attached storage (DAS) disks or when a completely incompatible storage area network (SAN) is being used. However, in situations in which similar, compatible or connected SAN technologies are utilized across the enterprise, SCR isn't the only option for an Exchange administrator. In such cases, it's best to let someone with more appropriate skills handle storage.
EXCHANGE SERVER 2007 HIGH AVAILABILITY STRATEGIES AND SANS
Part 1: SAN vs. SCR -- which is the best Exchange high availability solution?
Part 2: Replacing Local Continuous Replication with SAN storage technology
Part 3: Using Exchange 2007 Cluster Continuous Replication on a SAN
|ABOUT THE AUTHOR:|
Mark Arnold, MCSE+M, Microsoft MVP, is a technical architect for Posetiv, a UK based storage integrator. He is responsible for the design of Microsoft Exchange and other Microsoft Server solutions for Posetiv's client base in terms of the SAN and NAS storage on which those technologies reside. Mark has been a Microsoft MVP in the Exchange discipline since 2001, contributes to the Microsoft U.K. "Industry Insiders" TechNet program and can be found in the Exchange newsgroups and other Microsoft Exchange forums.
This was first published in June 2008