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 enables a separation of high availability (comprised of service and data availability) and site resilience. For example, SCR can be combined with CCR to replicate storage groups locally in a primary datacenter (using CCR for high availability) and remotely in a secondary or backup datacenter (using SCR for site resilience). The secondary datacenter could contain a passive node in a failover cluster that hosts the SCR targets. This type of cluster would be called a standby cluster because it does not contain any clustered mailbox servers, but it can be quickly provisioned with a replacement clustered mailbox server in a recovery scenario. If the primary datacenter fails or is otherwise lost, the SCR targets hosted in this standby cluster can be quickly activated:
- By using Restore-StorageGroupCopy, which will try to copy any missing log files from the SCR source, or
- By using Setup /RecoverCMS to provision a replacement clustered mailbox server in the standby cluster.
SCR Sources and Targets
As with LCR and CCR, SCR uses the concept of active and passive copies of a storage group, and like CCR, SCR requires that the database and log files paths be the same on the source and the target. Because SCR extends the scenarios supported by LCR and CCR, SCR also introduces the concepts of sources and targets.
The starting point for SCR is called the source, which is any storage group, except a recovery storage group, on any of the following:
- A standalone mailbox server (with or without LCR enabled).
- A clustered mailbox server in a single copy cluster.
- A clustered mailbox server in a CCR environment.
As with LCR and CCR, SCR-enabled storage groups cannot contain more than one database; you cannot enable SCR for a storage group that contains more than one database, and you cannot add a second or subsequent database to an SCR-enabled storage group.
The endpoint for SCR is called the target, and the target can be one of the following:
- A standalone mailbox server (without LCR enabled for any storage groups)
- A node in a failover cluster where the Mailbox role is installed, but no clustered mailbox server has been configured in the cluster.
A source can have multiple targets. For example, a source could have one target that exists in the same datacenter as the source, and a second target that exists in a separate datacenter. There is no limit to the number of targets you can have for each source; however, we recommend using no more than four targets per source. Impact to the source server needs to be verified and planned for accordingly if more than four targets are configured.
Requirements for SCR Targets
Target machines must be in the same Active Directory domain, but they can be located in the same or in different Active Directory Sites.
Each target can have multiple source servers. Both the source and the target system must be running Service Pack 1 for Exchange 2007. The operating system can be any operating system supported by Service Pack 1 for Exchange 2007.The database and log file paths on the source and all of its targets must match for each storage group being replicated with SCR. If both paths, including drive letter(s), do not match, you will not be able to enable SCR.
When a node or a server is configured as an SCR target these capabilities are blocked:
- A target that is a standalone Mailbox server cannot have LCR enabled for any storage groups (the Microsoft Exchange Replication service has not been designed or modified to handle managing local replication and replication from another source when the Mailbox server is also using LCR).
- A target that is a passive node must be a member of a cluster that does not have any clustered mailbox servers.
In my next blog entry, I'll talk about SCR target activation, as well as the cmdlets and processes used to set up, configure, and monitor SCR.
- Scott Schnoll
