Clustered Continuous Replication (CCR) is a high availability Microsoft Exchange Server 2007 solution that adds the new log file shipping and replay features to eliminate the single point of failure that exists in today's standard Windows 2003 active/passive cluster setup. With a Clustered Continuous Replication setup, transaction logs generated on the active node are replicated to the information store on the passive node. In the event of a database corruption, this allows both Exchange 2007 services and databases to fail over to the passive node. CCR can only be deployed in a two-node active/passive cluster.
Excerpted from How to Cheat at Configuring Exchange Server 2007: Including Outlook Web, Mobile, and Voice Access, by Henrik Walther, this tutorial provides an overview of the CCR feature and provides step-by-step instructions on how to configure and manage a Cluster Continuous Replication-based setup in Exchange Server 2007.
Managing an Exchange 2007 Cluster Continuous Replication (CCR) setup
Part 1: Exchange 2007 Cluster Continuous Replication requirements
Part 2: Setting up Cluster Continuous Replication in Exchange 2007
Part 3: Creating a Windows 2003 cluster for an Exchange 2007 CCR setup
Part 4: Using a file share witness with Exchange 2007 CCR
Part 5: Enable the Transport Dumpster on the Hub Transport server
Part 6: Installing Exchange 2007 on the active node and passive node
Part 7: Testing clustered mailbox server functionality in a CCR setup
Part 8: Exchange 2007 Cluster Continuous Replication (CCR) setup overview
Part 1: Exchange 2007 Cluster Continuous Replication (CCR) requirements
Exchange Server 2007 introduces another new high-availability feature called Cluster Continuous Replication (CCR). This feature takes the new Exchange Server 2007 log file shipping and replay mechanisms (known as continuous replication) and combines them with the features that are available in a more traditional two-node Windows 2003 server active/passive cluster setup. A traditional two-node active/passive cluster has its benefits but has also always had one major drawback: You still have a single point of failure when it comes to the information stores. CCR provides redundancy for both Exchange Services and the information stores.
As is the case with traditional Exchange clusters, CCR uses Windows Clustering Services to provide virtual servers (which, in Exchange 2007, are called clustered mailbox servers) and failover capabilities. CCR has one big difference from traditional clusters, though, and that is that functionality doesn't require any kind of shared storage subsystem, because each node contains a local copy of the information stores. This eliminates the dependency on SAN technology in the cluster design, which makes CCR a more cost-efficient solution because you can use a storage option such as Direct Attached Storage (DAS) or Serial Attached SCSI.
With CCR, the transaction logs generated on the active node are replicated to the information store on the passive node using log file shipping. These replicated log files are then posted into the database(s) on the passive node using the log file replay technology. This means that should the active node or a database on this node fail or for some other reason go offline, an automatic failover to the passive node will occur. When the passive node becomes the active node, the replication of log files will happen from the new active node to the passive node.
Another thing worth mentioning about CCR is that the feature supports stretched clustering (called geoclustering), but bear in mind that the nodes must belong to the same subnet. This means that as the cluster is stretched between the locations, the subnet must be stretched, too.
|Tip: When Exchange 2007 supports Longhorn server (which will be provided via a service pack when the Longhorn product has been released), we will be able to take advantage of stretched clustering spanning multiple subnets, both on the public as well as the private network (also called the heartbeat network).|
Last but not least, you can reduce the frequency of backups and restores as well as perform backups of the databases on the passive node, and thereby not impact the performance of the active node. In Figure 8.29 you can see a basic CCR scenario.
To set up a CCR-based cluster, the following are required:
- A Windows 2003 Active Directory forest with at least one domain controller (raised to 2000 or 2003 forest functional level)
- Two Windows 2003 Server R2 Enterprise Editions or Windows 2003 Server SP1 Enterprise Editions
- One Windows File Share Witness, which is recommended to be an Exchange 2007 Hub Transport Server in the existing Exchange 2007 organization; note that CCR-based clusters don't use a shared quorum as traditional clusters do
- A Cluster Service Account in the Active Directory forest (we'll create this one later in this section)
You also need to apply the update mentioned in MS KB article 921181 to both servers that will act as nodes in the Exchange Server 2007 Clustered Mailbox setup. The update adds a new file share witness feature to the current Majority Node Set (MNS) quorum model. The file share witness feature lets you use a file share that is external to the cluster as an additional "vote" to determine the status of the cluster in a two-node MNS quorum cluster deployment, which is a requirement to use the CCR functionality in Exchange Server 2007.
To deploy CCR, the following hardware requirements must be met:
- Two network interface cards (NICs) installed in each node -- one for the public and one for the private cluster network (the heartbeat network)
- Extra sets of disks or a DAS, SAN, or Serial SCSI solution to hold the database and transaction log files
In addition to the software and hardware requirements, you also should be aware of the following general requirements:
- When dealing with CCR environments, you must and can only use one database per storage group.
- You cannot create a public folder database in a CCR environment if you already have more than one public folder database in your organization.
- In a CCR environment, Microsoft recommends that you create no more than 30 storage groups and databases (one database per storage group) on the clustered mailbox server.
- The cluster on which Exchange 2007 is installed cannot contain Exchange Server 2000/2003 or any version of Microsoft SQL Server. Running Exchange 2007 in a cluster with any of these other applications is simply not supported.
|Some Independent Advice: Some of you might wonder whether the licensing rules have changed regarding Exchange 2007 cluster setups. Unfortunately, this isn't the case; you still have to purchase an Exchange 2007 Enterprise Edition CAL for each node in your cluster (also any passive nodes). The reason is that the passive node still runs Exchange code although the node is the passive one.|
Return to table of contents or proceed to part 2 on setting up a Cluster Continuous Replication in Exchange 2007.
This chapter excerpt from How to Cheat at Configuring Exchange Server 2007: Including Outlook Web, Mobile, and Voice Access, by Henrik Walther, is printed with permission from Syngress, a division of Elsevier, Copyright 2007.
Click here for the chapter download.