Manage Learn to apply best practices and optimize your operations.

Using Exchange 2007 Cluster Continuous Replication on a SAN

Use Exchange 2007 Cluster Continuous Replication on a storage area network (SAN) to implement high availability server resiliency and failover protection.

Cluster Continuous Replication (CCR) is another method of high availability in Exchange Server 2007. CCR is the only new replication and clustering feature that offers an automatic failover; however, the decision to implement that level of server resilience comes at a price.

If CCR is in a networked storage environment, associated cost includes handing over some bandwidth on the user network to Exchange transaction log replication, instead of block-level replication on the SAN network or Fibre Channel fabric that the SAN controls. When organizations choose CCR on Windows Server 2008, leveraging its multi-location (subnet) capabilities of Exchange data replication at the bit level over the network might not be desired.

Using a CCR environment on a SAN allows Volume Shadow Copy Service (VSS) backups to run on active nodes, passive nodes or both. Running the backup on the passive node enables either a larger maintenance window on the primary node or an extended period of time in which the active node fully performs for users. This is particularly important if one server provides email services to customers in several time zones.

Backing up the passive node, however, doesn't mean that transaction logs on the active node grow infinitely. Once a backup has run successfully on the passive node, a message is sent to the active node -- resetting the backup indicator. This then purges the logs in order, moving from active nodes to passive nodes.

There is another advantage to backing up the passive node. Because the passive node of a CCR cluster will be used when the active node fails, the number of SAN snapshots that can be taken and stored on the standby storage without affecting performance increases. If a failover occurs, it takes a few clicks to remove the oldest snapshot backups and return the storage array to desired performance levels.

Although using CCR is a good idea on networked storage, less-experienced Exchange Server administrators would benefit from reducing complexity by removing clustering.

Having a SAN, even an iSCSI SAN, when using software from a third-party provider such as emBoot, Inc., for example, allows administrators to remove all local disks from a server and switch to a boot-from-SAN model. While this might sound like it would increase complexity, it actually reduces complexity on the Exchange server side.

If a server fails, the LUN holding the operating system can be switched to a spare server. That server will then be brought online with minimal Exchange Server recovery time. You should never perform a boot from a SAN in isolation, unless it's part of an enterprise strategy. Otherwise, your storage team should handle that.

From the perspective of the Exchange team, the server has rebooted and isn't in the same location in the rack as it was earlier. Local recovery has been managed, but what about replication and remote recovery? Because Exchange Server's operating system is stored on the SAN, the operating system, databases and transaction log storage can be replicated to a remote SAN. After this, standby servers located in the remote data center are brought online. The overall time-lag between failure and recovery shouldn't take any longer than a CCR node-to-node failover.

A fourth high availability offering in the form of conventional clustering is Single Copy Cluster (SCC). However, this solution involves only a single shared copy of the Exchange databases and, in terms of data replication, is no different than a standalone server. The rationale for substituting LCR and SCR with storage area network (SAN) replication or snapshots in Exchange Server 2007 has the same validity for SCC-based clusters.


 Home: Introduction
 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

Mark Arnold
Mark Arnold, MCSE+M
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.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.