Exchange 2007 introduces new high availability feature which is the cluster continuous replication (CCR), CCR is a combination of an Active/Passive Exchange cluster and Asynchronous log shipping for replicating the log files contents to the passive node. let’s explain more, In Exchange 2003 we bring high availability on the server/service layer by implementing for example a two nodes cluster where by the passive node will take ownership on the cluster in case of a failure in the Active node thus providing service continuity to our customers however we didn’t provide an out of the box solution to provide resiliency on the database level so if you have a failure on the database level you will lose your messaging services as both nodes will not be able to help you and you have to either recover or restore your databases.
Exchange 2007 CCR brings the HA features of an Exchange cluster plus providing another high availability layer on the database level by seeding another copy of the Exchange databases to the other node which will be on another disks or may be a complete different storage, should you faced a problem in the database on the active node you can switch to the passive node which is having another copy of the database. CCR can be used to provide a complete HA messaging solution in one data center or it can be used in two sites to bring you site resiliency features also. knowing the fact CCR brings you also other benefits such as having your VSS backup from the passive node using the CCR database copy plus you can reduce your backup media overhead and others, there is some requirements and limitations such as you can’t have more than 1 store in the storage group and definitely for hosting the two nodes in different sites you should have a decent bandwidth between the two sites plus stretching the IP subnet’s between both of them and others that you can check this URL for these requirements http://technet.microsoft.com/en-us/library/bb124521.aspx
Looking to the CCR log shipping, what CCR is doing is asynchronously copying using SMB the Exchange transactions logs after being closed “1 MB each” to the other node, the other node do a corruption check on the log file and commit it to the store bringing it to a matching state with the active node. However looking into a situation where by the active node can have a problem and the passive node will take ownership on the CCR while there is few transactions that can be 1 or 2 log files that was not yet replicated or committed to the passive node so the users will actually ends up by having few emails missing or may be 2-3 large emails. Here comes the Transport Dumpster role, by default when you configure the CCR the hub enable the transport dumpster feature on itself where by it will queue & store the last email transactions “settings is configurable such as total size, duration, etc… via power shell”, should the passive node changed to be active the Hub automatically delivers the last transactions in the dumpster to the users mailboxes on that server, mailbox will delete whatever emails exists and commit whatever missing emails so bringing the store to a Sync situation. GREAT
note that dumpster will not bring you the following:
- Drafts folder for Outlook clients in online mode
- Appointments, contact updates, tasks & its updates
- Outgoing mail that is in transit from the client to the Hub where there is a time which e-mail message only exists on the sender’s mailbox server
I like CCR…