MSExchangeGuru.com

Learn Exchange the Guru way !!!

 

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

4 Responses to “Difference between CCR and SCR”

  1. Bhalchandra Gokhale Says:

    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.

  2. Selva from EMC Says:

    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.

  3. selva Says:

    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.

  4. Nithin Says:

    Whoaa..Pretty much explained.

Leave a Reply

migrate exchange to office 365

Categories

Archives