In my last posts I discussed Exchange Server 2007 Single Copy Clusters, which is one of two clustering features available in Exchange.  In this post I will discuss the other type of Exchange Server 2007 clustering, Cluster Continuous Replication

What is Cluster Continuous Replication?

Cluster Continuous Replication (CCR) for Exchange Server 2007 would not be familiar to anyone who only has clustering experience with previous versions of Exchange.  In a CCR cluster two cluster server nodes connect to non-shared resources in an active/passive configuration.  Exchange storage group and mailbox database information is replicated between the active and passive node using asynchronous log shipping.  I explained asynchronous log shipping in the first part of this series on the basic concepts of Exchange Server 2007 high availability.  The same log shipping occurs in Local Continuous Replication.

The two CCR cluster nodes appear to other computers to be a single system, and when one server node fails the clustered resources are able to fail over to the other node and continue operation.

CCR provides high availability for the Mailbox Server by protecting it from the failure of either cluster server node, as well as protecting it from storage failure.  Because each cluster node is connected to its own non-shared storage, the failure of one does not impact the other.  This also means that CCR disk storage can consist of much cheaper hardware alternatives than an enterprise-grade SAN would cost, making Exchange high availability a reality for businesses with smaller budgets.

CCR is available in the Enterprise edition of Exchange Server 2007.  Because it uses an underlying Windows Server failover cluster, the servers that form part of the cluster must also run the Enterprise edition of Windows Server (either 2003 or 2008).

Like LCR a CCR cluster offers high availability as well as performance benefits.  Backup operations can be performed against the passive copy of the database, making it possible to back up the server at any time of day without impacting end user performance.

Another advantage of CCR over SCC is that it increases the maximum recommended mailbox database size from 100Gb to 200Gb, thanks to the additional reliability and recoverability of a CCR cluster.

How to Install a Single Copy Cluster

In this example two Windows Server 2003 Enterprise edition servers have been configured with the basic requirements of a failover cluster:

• A public network interface for normal network operations
• A private network interface for the cluster “heartbeat”
• Matching disk configurations

Because there is no shared disk storage the cluster is installed as a Majority Node Set.

A Majority Node Set cluster needs to be configured with a third node called the File Share Witness.  The FSW acts as a “tie breaker” in the event that one of the cluster nodes fails.  One of the best places to locate the File Share Witness is on the Hub Transport Server in that site.

One the failover cluster has been configured we can install Exchange Server 2007 on the first node.  Run setup as normal, and when selecting the roles to install choose “Active Clustered Mailbox Role” as the server role.  You will notice that a clustered mailbox server cannot co-exist with any other server role.

Choose “Cluster Continuous Replication” as the cluster type, give the cluster a name, and specify a path for the database files.

Finally, give the cluster an IP address.

Exchange setup will configure all of the required cluster groups and resources for the underlying failover cluster automatically.  Once the active node is installed repeat the setup process on the passive cluster node, this time choosing “Passive Clustered Mailbox Role”.

Managing a CCR Cluster

For most Exchange administrative tasks the clustered mailbox server will appear like any other mailbox server.  For example, the storage group will show up as with any other mailbox server, but will have a value of “Clustered” for the Replicated attribute.

[PS] C:>Get-StorageGroup

Name                      Server            Replicated
----                      ------            ----------
First Storage Group       EXCHMAILBOX       None
Second Storage Group      EXCHMAILBOX       None
First Storage Group       exchcms           Clustered

As with Single Copy Clusters a CCR cluster should not be administered using Cluster Admin (cluadmin.exe).  Instead, Exchange cluster operations such as moving the cluster group to another node should be performed in the Exchange Management Shell.

[PS] C:>Move-ClusteredMailboxServer

Supply values for the following parameters:
Identity: exchcms
TargetMachine: exchmailbox2
MoveComment: Testing

Confirm
Are you sure you want to perform this action?
Moving clustered mailbox server "exchcms" to
target node "exchmailbox2" with move
comment "Testing".

[Y] Yes  [A] Yes to All  [N] No  [L] No to All
[S] Suspend  [?] Help
(default is "Y"):y

Similar to Local Continuous Replication the replication health of the CCR cluster should be monitored.

[PS] C:>Get-StorageGroupCopyStatus

Name                SummaryCopy CopyQueue ReplayQueue
                    Status      Length    Length
----                ----------- --------- -----------
First Storage Group Healthy     0         0

The copy and replay queues should remain at zero or very close to it under most circumstances.  An increasing number for either can indicate a problem with replication.

Standby Continuous Replication

In the final post in this series I will demonstrate Exchange Server 2007 Standby Continuous Replication.