Difference between CCR and SCR
This is not a checklist of differences between CCR and SCR in Exchange 2007, but a main one I thought all should be aware.
Why do you think we should not implement 2 nodes in 2 different sites with CCR and forget SCR ? Just read through…
Standby Continuous Replication (SCR) in a nutshell is a type of clustering which allows you to replicate your production databases to a standby server that can be brought online if the active site/server goes down.
What’s different in CCR then ??? CCR offers high availability and site resilience too, but its best achieved via SCR. The main reason being, its complicated to implement CCR across datacenters that have different IP subnets, as the members of the CCR cluster must be in the same subnet with W2K3 OS. I wont say its impossible, but many organizations are looking at implementing SCR in a backup datacenter and then manually initialize the SCR servers for DR pupose for the production datacenter.
So, I would call this a main notable difference between CCR and SCR.
Ratish Nair
MVP Exchange
Team @MSExchangeGuru
August 4th, 2011 at 2:58 am
Hi
You are correct to a point but with 2003 R2 or sp2 removed this need to have CCR nodes on the same IP subnet. In my mind SCR offers other features which differentiate it from ccr.
1 SCR TARGET can be a standalone maibox server
2 SCR offers a capability to replicate one database to multiple target servers.
3 A administrative delay can be configured for raplay of log files into target database in addition to the dafault delay.
September 30th, 2011 at 4:02 am
What is the difference between LCR, CCR and SCR?
TweetThe following tables list the difference between LCR, CCR and SCC in Exchange 2007.
LCR
CCR
SCC
Failure or planned downtime of one node
No protection
Protected
Protected
Database corruption
Probable protected if database corruption is not replicated to the copy
Probable protected if database corruption is not replicated to the copy
No protection
Failed local storage system
Protected if second copy is on a different storage system
Protected
Protected if the failure is isolated to one node
Failed disk subsystem
Probable protected if second copy is on a different storage system
Protected
No protection
Data center failure
No protection
Probable protected if the second node is located in a second datacenter and the file share witness is accessible by it
No protection
Utilizes Windows clustering
No
Yes
Yes
Can use low cost storage systems
Yes
Yes
No
Storage requirements
Double
Double
Single
Backup databases without impacting server
Partial if the second copy is located on a different storage system the impact will be less. With CCR the primary server is not affected at all.
Yes
No
LCR
CCR
SCR
Support only one target passive copy
Support only one target passive copy
Supports multiple targets per storage groups
Can backup LCR Copy
Can backup CCR copy
Cannot backup SCR copy
Log shipping is Continuous and uses a PULL model
Log shipping is Continuous and uses a PULL model
Log shipping is Continuous and uses a PULL model
Does no use Windows Clustering
Uses Windows Clustering
Uses Windows Clustering
Double Storage requirements
Double Storage requirements
Single Storage requirements
SCR is similar to LCR and CCR, but it has unique characteristics of its own:
■SCR supports multiple replication targets per storage group. LCR and CCR support only one replication target per storage group (the passive copy).
■SCR includes a built-in delay for replay activity, and it enables an administrator to specify an additional delay. This is useful in a variety of scenarios. For example, in the event of logical corruption of an active database, the built-in and additional administrator-configured delay could be used to prevent logical corruption of an SCR target database. LCR and CCR have no such delays.
■SCR is completely managed using the Exchange Management Shell. The Exchange Management Console can be used to manage many aspects of LCR and CCR, but it cannot be used to enable or manage any aspects of SCR.
April 13th, 2012 at 5:46 am
Cluster Continuous Replication
CCR is one of the high availability feature introduced in Exchange Server 2007 to provide availability service at the server level and database level. If we look at LCR, we can achieve high availability at the database level only, if the server goes down the data won’t be accessible until the server is built again. Most the exchange server administrator will prefer to go for CCR because of the following features
1. High Availability at the Database and Server level
2. Automatic failover, if any problem with active server database
3. Failover occurs with in less than 3 minutes time
4. Reduce the frequency of full back up on regular basis
5. No single point of failure
Here in this post, basic information on the cluster continuous replication is discussed and the following topics…
• How CCR works
• How to check the storage group copy status
• What is Copy Queue length and Replay Queue length?
• Seeding Reseeding of the CCR database
• When failover will occurs
How CCR works…
Like LCR, CCR uses the same asynchronous log file shipping and replaying technology to update the passive copy same like active copy. Once the second node is added to the CCR, the current active database will be copied to the passive database and this process in called seeding. Once seeding got completed the log file created in the active server will be shipped to the passive one and it will replay to passive node.
By default, a hidden shared folder on the storage group where the active database copy will be created, where in, the passive node find the shared folder and using SMB the changes in the log file will be copied to the passive node and replayed to the passive database using the replication service.
Once the log file got committed in the active database, then the log file will be shipped to passive node. Monitoring the committed logs on the active database will be monitored by inspector component.
The sever level failover and the database level high availability is achieved using windows cluster service and the log file shipping and replaying process are controlled by MS Exchange Replication service.
How to check the storage group copy status
To view the storage group copy status use the below shell command
Get-StorageGroupCopyStatus –Server “Cluster Name”
To view the Mailbox Database status in CCR use the below shell command
Get-MailboxDatabase –Server “Cluster Name” –Status | FT Name, Mounted
To view the replication health
Test-ReplicationHealth –Identity “Server name”
What is Copy Queue length and Replay Queue length?
If you run the Get-StorageGroupCopyStatus it will provide the details of storage group health status and the copy queue length and replay queue length status.
Copy Queue Length: It’s the log file count, where the transactional logs that are in the queue to be transferred from active node to passive node
Replay Queue Length: These are the log file that are transferred from active server to passive server and are waiting to be replayed into the passive database.
SeedingReseeding of the CCR database
Seeding:
When passive node is added to the cluster, the current database will be copied as a passive copy in the passive node; this process of duplicating the active database to passive server is seeding. We can perform seeding using
Update-StorageGroupCopy –Identity “Server NameStorage Group Name”
Reseeding:
If active database got corrupted and its inaccessible to users, we can bring the active copy to live from the passive copy, the process of duplicating the active database copy same like passive database copy is reseeding, we can perform reseeding using
Restore-storageGroupCopy –Identity “Server NameStorage Group Name”
Also, we can use the below commands to suspend and resume the log file replication process.
Suspend-StorageGroupCopy –identity “Storage Group Name”
Resume-StorageGroupCopy –identity “Storage Group Name”
When failover will occurs
In CCR, if any problem with a store or server, the failover will occur automatically. If we deeply look into when this automatic failover occur from passive to active node, following are the ways…
1. If active node shutdown for any reason
2. NIC card problem and result in connectivity problem between both the nodes
3. If there is failure in achieving the Majority node in the quorum, failover will occur.
Lets us look into the resources in the CCR; we can have once instance of storage group, information store service and system attendant will be functioning for the entire CCR. Even though who have two servers in CCR functioning as a active node and passive node, the mailbox database in the active node will active and the system attendant and the information store service on the active node will be functioning only in active node. If failover occur, the information store service and the system attendant service in the passive node will continue to function.
Failover: failover is the process of changing the passive node to active node because of some problem in the active node. In CCR failover is automatic
Switch over: Switch over is the same process of making the active node to passive node but the failover is manual. If any more information is need in CCR please inform us, we will post you with full detail.
July 7th, 2013 at 2:47 pm
Whoaa..Pretty much explained.