About nine months ago I promised to blog about the different high availability options available in Exchange Server 2007. I followed up with a post on LCR but then abandoned the project. So, today lets start that series back up. This time around lets cover in detail what CCR is, how to use it and when you should and shouldn’t use it.
What is Cluster Continuous Replication (CCR)?
CCR is similar to LCR in the fact it keeps two copies of the databases on disk, however CCR is different in that it relies on Microsoft Clustering and a pair of servers. CCR has no single point of failure if configured properly, as there are two servers with two sets of everything. To take full advantage of having two copies of the data, on two separate servers, two separate storage systems should be used. Thankfully, Exchange 2007 has a lower disk I/O requirement than previous versions of Exchange, so that inexpensive local storage can often be used to ensure complete separation between nodes. CCR can only have two cluster nodes, an active and a passive node. Just like with LCR, you can only have one database in each storage group.
Configuration considerations
Since you do not need shared disk for a CCR cluster, you will most likely choose to use a file share witness rather than using a quorum disk. It is recommended to use a local Hub Transport server as the file share witness as being a file share witness will not put a substantial load on the server.
When would you use CCR? It is an excellent solution for environments that need local data redundancy and have the experience in working with Microsoft-base clusters.
Pros
- No Single point of failure
- Two copies of data exist at all times
Cons
- Requires Microsoft Clustering Service
- Requires double the disk space to store two copies of logs and data