In my last post I explained the basic concepts of Exchange Server 2007 high availability.  In this post I will demonstrate one of the Exchange Server 2007 HA features that is called Local Continuous Replication.

What is Local Continuous Replication?

Local Continuous Replication (LCR) uses asynchronous log shipping technology to maintain a copy of a mailbox database on another locally connected disk volume.

For example, the mailbox database and transaction logs may reside on fast, expensive SAN disks, but the LCR copy is kept on slower, cheaper SATA disks.

LCR provides high availability for the Mailbox Server by protecting it from a storage failure.  If the SAN disks failed or became disconnected for some reason the server could continue serving end users via the replica database, possibly at a degraded performance level if the slower disks were not able to handle the required I/O load.

Because LCR is available in both Standard and Enterprise editions of Exchange Server 2007 it is a fairly easy way to achieve some high availability for the server.Another advantage of LCR is that Exchange streaming backups can be performed off the replica database, which means backup I/O load does not slow down the production database.  This permits backups to be run any time of day with no fear of end user impact.

How to Enable Local Continuous Replication

In this example a mailbox server has been configured with a storage group containing a single mailbox database.  An additional disk volume has been mounted on the server, and we can now enable replication of this storage group to the second volume using LCR.

To enable LCR right-click on the storage group and choose Enable Local Continuous Replication.

Proceed through the wizard and set the storage group system file and log file paths.  These should be on a disk volume that is separate to the volume that holds the live database.  It should also be a volume of equal or greater disk capacity so that it can hold an entire replica of the production data.

Continue through the wizard and choose a replica path for the mailbox database as well.

When you are happy with your choices complete the wizard to enable LCR.

Depending on the size of the database and the number of transaction logs to be shipped and replayed this operation may take some time.  You can monitor the progress in the Exchange Management Shell.

As you can see, the storage group’s “Replicated” attribute has changed to “Local”.

[PS] C:>Get-StorageGroup

Name                      Server            Replicated
----                      ------            ----------
First Storage Group       EXCHMAILBOX       Local
Second Storage Group      EXCHMAILBOX       None

We can also view the progress of the log shipping. Each transaction log is first placed into the copy queue to be shipped to the replica folder.  Once it has been shipped it is placed into the replay queue, and then replayed into the database.

[PS] C:>Get-StorageGroupCopyStatus
Name                 SummaryCopy CopyQueue ReplayQueue
                     Status      Length    Length
----                 ----------- --------- -----------
First Storage Group  Healthy     2750      0
Second Storage Group Disabled    0         0

Under normal conditions once the initial replication has occured the copy and replay queues should be quite low.  A high number of log files waiting to be copied or replayed may indicate a problem with LCR.

Switching to the Replica Database

In this demonstration the production database has become corrupt and will not mount, and so the decision is made to activate the passive copy.  To bring the LCR replica database online right-click on the storage group and choose Restore Storage Group Copy.

Complete the wizard to enable the passive copy.  This process checks that the replica log files have been brought completely up to date and replayed into the replica database so that it is ready to be mounted.  Before the passive copy can be brought online it must be placed in the location of the original production database.  For a large database file copying it from one location to the other would be very time consuming.  Instead you should modify the drive letter and folder path of the passive copy so that it matches the original active copy.  For example, if the passive copy was in F:SG1Data-LCR, use Disk Manager to re-assign that volume to the drive letter E: and then rename the path to SG1Data.

Note that this is not necessary if during the Restore Storage Group Copy wizard you ticked the box to update the database paths to match the passive copy location.  This method means that you can immediately mount the database without having to remap any volumes, however it may cause confusion for administrators later on when they encounter an active database in what they thought was a passive replica location.

The activation of the passive copy is completed by simply mounting the database.  Once the database is back online you then need to re-enable LCR to protect it from future failure situations by using the same process as demonstrated earlier in this blog post.

Summary

As you can see Local Continuous Replication is a simple high availability feature to implement for an Exchange Server 2007 mailbox server and can be used to quickly recover from some database failure scenarios.  LCR also carries some additional benefits such as offloading backup I/O onto a passive copy.

In the next post in this series I will demonstrate Exchange Server 2007 clustering with Single Copy Clusters.