What is LCR, CCR, SCC and SCR introduced with Exchange 2007 ?
In Exchange Server 2007, we have the high availability option both at the server level and the database level. Exchange 2007 comes up with 4 High Availability Solution, which uses the continuous replication technology (Asynchronous log file shipping) to have duplicate copy of database at the same server and also at different server and they are
LCR (local continuous replication) :-
Local continuous replication (LCR) is a single-server solution that uses built-in asynchronous log shipping and log replay technology to create and maintain a copy of a storage group on a second set of disks that are connected to the same server as the production storage group. The production storage group is referred to as the active copy, and the copy of the storage group maintained on the separate set of disks is referred to as the passive copy. The following figure illustrates a basic deployment of LCR.
Note : In LCR we get Redundancy only at the storage level, the active copy of the database is replicated to the passive copy of the database using log file shipping, replication of log files will takes inside the server, but to a different disk. If the disk goes down, data will be safe at other disk.
This is mainly used for small business who wanted to replicate a copy of their Exchange database to another disk on the same server.
SCC (Single copy cluster) :-
A single copy cluster (SCC) is a clustered mailbox server that uses shared storage in a failover cluster configuration to allow multiple servers to manage a single copy of the storage groups. This feature is similar to the clustering features in previous versions of Microsoft Exchange. However, there are some significant changes and improvements that have been made. The way in which you build, manage, and troubleshoot an SCC is completely different from the way in which previous versions of Exchange clusters were built and managed. In addition, the out-of-box failover behavior has changed significantly in Microsoft Exchange Server 2007.
As illustrated in the following figure, SCCs require the use of a shared-nothing architecture, which includes shared disk storage. In a shared-nothing architecture, although all nodes in the cluster can access shared data, they cannot access it at the same time. For example, if a physical disk resource is assigned to node 1 of a two-node cluster, node 2 cannot access the disk resource until node 1 is taken offline, fails, or the disk resource is moved to node 2 manually.
Basic architecture of an SCC
Note :-Single copy cluster, its just like the legacy version redundancy model, where the nodes on the cluster shared the same storage subsystem. With SCC, we have the redundancy option for server and not the database level.
CCR (cluster continuous replication):-
Cluster continuous replication (CCR) is a high availability feature of Microsoft Exchange Server 2007 that combines the asynchronous log shipping and replay technology built into Exchange 2007 with the failover and management features provided by the Cluster service.
CCR is designed to provide high availability for Exchange 2007 Mailbox servers by providing a solution that:
- Has no single point of failure.
- Has no special hardware requirements.
- Has no shared storage requirements.
- Can be deployed in one or two datacenter configurations.
- Can reduce full backup frequency, reduce total backed up data volume, and shorten the service level agreement (SLA) for recovery time from first failure.
CCR uses the database failure recovery functionality in Exchange 2007 to enable the continuous and asynchronous updating of a second copy of a database with the changes that have been made to the active copy of the database. During installation of the passive node in a CCR environment, each storage group and its database is copied from the active node to the passive node. This operation is called seeding, and it provides a baseline of the database for replication. After the initial seeding is performed, log copying and replay are performed continuously.
In a CCR environment, the replication capabilities are integrated with the Cluster service to deliver a high availability solution. In addition to providing data and service availability, CCR also provides for scheduled outages. When updates need to be installed or when maintenance needs to be performed, an administrator can move a clustered mailbox server (called an Exchange Virtual Server in previous versions of Exchange Server) manually to a passive node. After the move operation is complete, the administrator can then perform the needed maintenance.
The move operation is performed using the Move-ClusteredMailboxServer cmdlet in the Exchange Management Shell. Microsoft Exchange Server 2007 Service Pack 1 (SP1) also includes a new Manage Clustered Mailbox Server wizard in the Exchange Management Console that you can use to move clustered mailbox servers. The logic used by these tasks performs the necessary enforcement to make sure that no mailbox data is lost during the move. The tasks also perform checks before the move to make sure that replication on the passive node is ready to be quickly activated.
Basic deployment of CCR
Note : In CCR we get Redundancy at the hardware level as well as the storage level, Where active cop of the database will be replicated to passive copy on a different server, with the support of Windows failover clustering, redundancy will be achieved both at hardware and database level. Using CCR, there is no single point of failure, But with CCR no site resiliency.
SCR (standby continuous replication) :-
Standby continuous replication (SCR) is a new feature being introduced in Service Pack 1 for Microsoft Exchange Server 2007. As its name implies, SCR is designed for scenarios that use standby recovery servers. SCR extends the existing continuous replication features and enables new data availability scenarios for Exchange 2007 Mailbox servers. SCR uses the same log shipping and replay technology as local continuous replication (LCR) and cluster continuous replication (CCR) to provide added deployment options and configurations. SCR is very similar to LCR and CCR, but it has unique characteristics of its own:
- SCR supports multiple 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 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 admin-configured delay could be used to prevent logical corruption of an SCR target database.
- In the RTM version of Exchange 2007, rules are enforced so that in a continuous replication environment a log file is not deleted unless and until it has been backed up and replayed into the copy of the database. This rule is modified when using SCR. SCR (which introduces the concept of multiple database copies) allows log files to be truncated at the SCR source as soon as they are inspected by all SCR target machines. Log truncation at the SCR source server does not wait till all logs have been replayed into all SCR targets because SCR target copies can configured with large log replay lag times.
- Unlike CCR and LCR, you cannot back up an SCR copy. When using SCR, the database headers for SCR copies are updated, and the log files are truncated, when supported backups are taken against the source storage group (or, in the case of LCR and CCR, when backups are taken against either the active or passive copies of the source storage group).
SCR Deployment Scenarios
Using CCR to replicate storage groups locally and SCR to replicate storage groups to multiple remote locations
Note : Site resiliency achieved using SCR, where SCR ships log file to another mailbox server and there is no need of Windows failover cluster. With SCR, we have the option to specify log reply time.