SCR
provides a solution that we did not have with the RTM of Exchange and
the initial clustered solutions of CCR and SCC—a combination of site
resilience and high availability.
By
site resilience, what we mean is under a 2003 cluster, both nodes had
to be in the same subnet. There was still a way of placing each node in
different locations or physical sites. However, they needed to be on
the same network, and you might be using a virtual LAN to accomplish
the illusion for the cluster.
However,
with Server 2008 and Exchange 2007 SP1, we have new clustering
abilities and site resilience added to the mix. We can now place our
nodes in two different sites.
The
simplest use of SCR is along the same lines of LCR, but across two
different systems (not just two different disks). You can see how this
can be taken to the next level, and you can place these systems in two
different sites. However, SCR can do much more. It can create secondary
copies of CCR and SCC sources. The source might be a cluster, but the
target of the SCR configuration doesn’t have to be a clustered target.
It can be a single mailbox server or a passive node waiting to spring
into action.
Due to
the complexity of SCR, we do not cover each possible scenario. Rather,
we suggest that you research your specific needs and solutions online.
However, we review the basic requirements and configuration options to
get SCR up and running.
Some of the requirements for an SCR solution include the following:
As with other implementations, there can only be one database per storage group.
Both the source (or active copy) and target (or passive copy) have to be in the same AD domain.
The
source and target have to use the same OS. The target must have the
Mailbox role installed (if a cluster, it must be a passive role).
Either the Enterprise or Standard Editions can be used for SCR.
The database and storage group paths have to be the same for both the source and target.
SCR does not use cluster services—it uses the replication service to perform the continuous replication process.
There is a 50-log lag between the source and target by default. There is also a 24-hour replay time that you can configure.
In
our simple scenario, imagine we have two servers—Ex01 (our source) and
Ex02 (our target)—and each has the typical installation with Hub
Transport, CAS, and Mailbox roles. Both are running Server 2008, and
they are both in the same AD domain.
To
implement SCR in a simple scenario where you wish to have the database
and log files under a storage group called SCR1 on one system
replicated over to another system, perform the following:
Open the Exchange Management Shell and type the following command:
Enable-StorageGroupCopy -Identity SCR1 -StandbyMachine Ex02 -ReplayLagTime 0.0:4:0 -TruncationLagTime 0.0:5:0
What exactly did we type here?
Well, the -StandbyMachine is the location of the target system for the passive copy. The -ReplayLagTime
is a predetermined amount of lag before replaying of the copied log
files occurs. This is to prevent a corrupt database and logs from
continuing. The format is days.hours:minutes:seconds, so we gave this a
4-minute delay (although the default time is 24 hours, with the maximum
being 7 days). There is a predetermined 50-log limit by default, so
that regardless of our settings, there is always a 50-log delay to
prevent corruption of the passive database. Finally, we have the -TruncationLagTime where we specify the amount of time the replayed log files can sit before they are deleted from the target.
There
are several ways of knowing that your SCR procedure worked. The first
is to check the event viewer and look for Event ID 2114, which tells
you that replication has begun.
You can also open an EMS shell and type Get-StorageGroupCopyStatus -StandbyMachine (target server name) and you will be shown if the status is healthy, if logs have replayed, and so on.
You
can also perform the same test we did with LCR, which is to look at the
source transaction log location and the target transaction log folder
and see that copies are being made (taking into consideration that
there is a delay built in).
Note
Remember,
there is no visual confirmation from the EMC that you have succeeded in
your task of enabling SCR. If you look at the target server, you do not
see anything different in the EMC regarding that server. Perhaps SP2
includes a more graphical implementation of SCR, but for now we need to
use the EMS to perform a visual check of the target server to see
whether something is replicating.
You
may wonder: What if your source goes bad and you need to bring the SCR
copy online? There are a few different options for activating SCR
copies. In fact, Microsoft has an excellent article at http://technet.microsoft.com/en-us/library/bb691321.aspx.
