Now that Beta 2 of Exchange Server 2007 is available for public download and preview, I thought I would present a blogcast about one of my favorite features: Cluster Continuous Replication, or CCR for short. CCR is a high availability feature of Exchange 2007 that combines the asynchronous log shipping and replay features built into Exchange 2007 with the failover and management features provided by the Microsoft Cluster service. CCR is a solution that can be deployed within a single data center or between two data centers, with no single point of failure.
To demonstrate how to deploy CCR, I have created a 7-part blogcast that takes you through the process. The blogcast video parts are as follows; please click on video thumbnails below to see the videos:
1. Introduction to CCR
2. Creating the directory and file share for the file share witness
3. Forming a failover cluster with a Majority Node Set (MNS) quorum
4. Configuring the MNS quorum to use the file share witness
5. Installing the active clustered mailbox server role
6. Installing the passive clustered mailbox server role
7. Verifying cluster status, failover, and manageability
These blogcast videos are intended to be watched in full-screen resolution (at least 1024 x 768), and in numbered order. To save time and reduce video size, some of the demos in this blogcast have been compressed or edited without affecting the quality or the results of the demos.
In addition, I ran batch files to accomplish the steps in some of the demos. A couple of the demos involve multiple commands, so to minimize the chance of errors and typos, and to save time, I performed some of the steps using batch files.
A few notes about the blogcast:
- In Part 3 of the blogcast, I mention that there are some expected errors that I encounter during the formation of the cluster. In the demo, these are actually warnings, not errors. The warnings being encountered refer to the lack of shared storage in the cluster. These warnings can be safely ignored because CCR does not require, or use, shared storage. Some of the warnings being encountered also refer to additional networks and local storage that is present on each node. These extra resources are present because I use these systems for a variety of different demos. Rather than remove them, I leave them disabled. When the New Cluster Wizard analyzes the systems to determine their readiness as a cluster, it finds these disabled resources and issues warnings about them. It is these types of warnings that can be safely ignored. When you form your own failover cluster, be sure to fully investigate all warnings and errors that appear, and resolve them if necessary.
- In Part 4 of the blogcast, once the MNS quorum has been configured to use the file share witness, and once the default cluster group has been taken offline and online, the file share witness will be used. Below is a screen shot displaying the contents of the file share witness directory and its sub-directory on the demo system (\\E2K7\MNS_FSQ_EXCLUS). As you can see, there is very little data in the directory. The load on the file share is very light. The presence of the recently created directory (the long GUID with the $ at the end of it) is evidence of the file share witness at work. Once activated, the MNS quorum with file share witness creates a single file in the directory. In order to prevent split brain syndrome, the current MNS resource owner (the node that currently owns the Cluster Group) acquires an exclusive lock on that file when the other node is down or otherwise unavailable. Only the owner of the exclusive lock may survive when nodes lose communication with each other. The current MNS resource owner will also write membership data into that file. When a node starts and forms the cluster, it will use that membership data to determine whether it has the latest cluster state information and can form the cluster without causing split brain syndrome.
Figure 1 - File Share Witness Directory on Hub Transport Server
- In Part 5 of the blogcast, I mention that the cluster needs a "special, unique IP address." I meant to say it needs a "static, unique IP address." In order for a failover cluster to be supported, it must have at least two network interface cards (NICs) in each node. One NIC is typically dedicated to the private network traffic (e.g., cluster heartbeat traffic), and the other NIC is used for both public network traffic (e.g., client, server, and administrator interaction with the clustered mailbox server and the cluster) and private network traffic (only if the dedicated private network fails). When forming the failover cluster, be sure to follow the instructions in the Exchange Server 2007 product documentation:
-Exchange 2007 Product Documentation (Online/Web) - http://go.microsoft.com/fwlink/?LinkId=69434
- Exchange 2007 Product Documentation (Offline/CHM) - http://go.microsoft.com/fwlink/?LinkId=69162
- In Parts 5 and 6 of the blogcast, the clustered mailbox server is installed into the cluster (first the active node, then the passive node). Be aware that any pre-requisite checks that fail when installing the clustered mailbox server are not re-checked on the passive. It is very important that you ensure that the passive node meets all pre-requisites, too.
If you now need a refresher of the LCR (Local Continuous Replication) - please see my earlier video on the subject here.
Of course we welcome your feedback on CCR, the documentation for CCR, and this blogcast. Thanks for reading/watching!