Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Setting Up Local Continuous Replication in Exchange 2007
Enabling Exchange Server 2007 for high availability is a straightforward process
J. Peter Bruzzese
August 27, 2007
11 Min Read
Executive Summary:
Microsoft Exchange Server 2007 provides several built-in features to provide a disaster recovery capability for your Exchange server. One such feature, Local Continuous Replication (LCR), provides for a secondary, passive copy of your mail database on a separate disk. In the event of a disk failure or corrupted mail database on the active disk, you can manually fail over to the passive copy of the database. You can configure LCR on Exchange Server 2007 either via the Exchange Management Console GUI or by using Windows PowerShell commands in Exchange Management Shell. |
Imagine yourself driving down a winding road. Suddenly you notice your brakes aren’t functioning. You start to panic but remember the emergency brake. This example vividly shows how redundancies in systems are lifesavers. Having more than one point of recovery is essential, especially when you’re dealing with machines.
As I discuss in “High Availability in Exchange 2007 Is Well Within Your Reach” ( InstantDoc ID 96495), one high-availability solution that Exchange Server 2007 offers is Local Continuous Replication (LCR). When you enable LCR, a secondary copy of your database is created onto a secondary disk. Transaction logs are shipped over to the secondary disk and replayed to update the passive copy of the database. In the event of a disk failure or corrupted database on the active disk, you need to perform a manual switch to get your email service back up and running. Another benefit of LCR is that you can back up your Exchange databases that have LCR enabled from the passive copy, preserving valuable disk I/O on the active copy to serve clients. Let’s review some things to consider before you set up LCR, then walk through the LCR configuration process step by step.
Prepare for LCR
Before you configure LCR on your Exchange 2007 server, consider these tips to help ensure a smooth LCR configuration.
Microsoft recommends that your secondary disk have a similar capacity and equal performance to the active copy, to ensure that the secondary disk functions similarly to the disk housing the active database.
You enable LCR on an entire storage group (SG). You can have only one database per SG; LCR won’t allow itself to be enabled on an SG that has more than one database. For a larger system with multiple SGs, this means that you’ll create multiple SGs and enable LCR on each one.
LCR works when the database in the SG is a public folder database; however, it doesn’t work if the organization contains more than one public folder database. Thus, you need to ensure you have only one public folder database for your organization.
Make sure your system is powerful enough to handle the extra workload that results when LCR is enabled. You’ll notice an increase in overall processing cost (processor, memory, and disk I/O) of about 20 percent due to the copying and replaying of the logs from the active to the passive disk. You’ll want to consider adding more memory to the system and making sure you have plenty of disk space.
Enable LCR
You can enable LCR on an existing SG or when creating a new SG. You can perform the process through the GUI via Exchange Management Console or through Exchange Management Shell, using Windows PowerShell commands. We’ll start by enabling LCR on an existing SG through the console. (For information about using PowerShell commands to enable LCR, see the sidebar “Using Windows PowerShell to Enable LCR.”) Follow these steps:
Open Exchange Management Console.
Expand Microsoft Exchange, then expand Server Configuration and select Mailbox.
From the result pane, select the Mailbox server with the SG you want to replicate using LCR.
On the Database Management tab for that Mailbox server, you’ll see a listing of your SGs and corresponding databases. You might also note that the Mailbox Database status is Mounted. Now select the SG on which you want to enable LCR. Remember that the SG can only contain one database for LCR to work.
The Actions pane on the right side of Exchange Management Console should now display options specific to your SG. Select Enable local continuous replication, which will start the Enable Storage Group Local Continuous Replication wizard.
On the Introduction page, verify the SG and database name and click Next.
On the Set Paths page, you’ll notice that the replication system files path and log files path are pointing to your local drive by default. Although you might want to leave these settings as is for testing, keep in mind that they afford you absolutely no protection. These settings indicate that you’re essentially replicating from your primary disk to your primary disk. You’ll be better off clicking the Browse button and selecting another disk location for your replication, as Figure 1 shows. Notice that we created specific folders to organize the replicated data. Then select Next.
On the Mailbox Database page, select the Browse option to determine the path for your Mailbox Database.edb database file, as Figure 2 shows. In addition to choosing a different disk for the LCR copy, you might also opt to select a different I/O controller, for additional redundancy. Click Next.
On the Enable page, you can review the Configuration Summary before selecting the Enable button. If you need to change anything, click Back. If all your settings look correct, select Enable. You’ll see the progress of the LCR configuration, as Figure 3 shows.
What’s occurring here is a process called “seeding” the database. Seeding is the creation of the starting point for the LCR version of the database file. This starting point can be an offline copy of the production database or a new empty database into which existing transaction logs will be replayed. Before LCR can work, database seeding must occur. In my experience, the performance impact of the seeding process on your Exchange system is minimal.Finally, on your Completion page, if all has gone well click Finish.
After the LCR setup is finished, you should notice a change in the icon next to your SG from within Exchange Management Console. If you right-click the SG that you’ve enabled for LCR, you’ll notice the options to disable or suspend the LCR. The distinction between the two options is important. Disabling LCR means that you’re essentially turning it off for the SG and will have to re-enable it completely through the wizard process. If you want to pause the LCR process, you should select the Suspend option; if you want, you can enter a comment to explain why you suspended the process. To continue LCR replication, simply select Resume.
Confirm LCR Replication
There are a variety of ways to confirm that LCR is working. (If you’re having difficulty with your LCR replication, consult the Microsoft TechNet article “How to Troubleshoot Local Continuous Replication Issues” at http://technet.microsoft.com/en-us/library/aa996038.aspx.) You can right-click the SG on which LCR is enabled and go to the Properties. Select the Local continuous replication tab, which Figure 4 shows. Notice the status of your LCR. The seeding status should read False (because the seeding process should already be finished), and the copy status should be Healthy. If LCR has been suspended, you can read the comment here as well. To see this information by using a PowerShell command via Exchange Management Shell, type the following at the command prompt (substitute your own server name and SG name, and type the command on one line):
Get-StorageGroupCopyStatus ` -Identity Another way to confirm LCR functionality is to perform a little test. Open the folder for the active location of your transaction logs on the primary disk. Than open the location you provided for the LCR passive copy. Place these two windows side by side so that you can see both clearly. Now, through an email client, send some messages with small attachments (2MB or so) to a mailbox on the Exchange server. These actions will generate some transaction logs. You should see the logs appear on the active side first, then begin to show up on the passive side as well. These actions happen a bit quickly, so you can slow down the test by first suspending (not disabling) LCR. Send the email messages and watch as the active-side transaction logs grow. Then resume LCR and watch as the logs are shipped over to be replayed into the passive database copy.
Recovering When the Active Copy Fails
Nothing is worse than putting effort into preparing for a failure but forgetting the plan when disaster does strike. To avoid this problem, keep on hand a set of instructions for how to manually fail over your LCR should the active copy fail. Keep this information on an index card near your Exchange server so that you or one of your co-workers can perform the necessary steps.
To perform a manual LCR failover, follow these steps:
Dismount the corrupt database by either selecting the database or choosing the Dismount option from the Actions pane (or by right-clicking the database and choosing the Dismount Database option.) From Exchange Management Shell, you can also dismount the database by using the Dismount-Database cmdlet (you’ll need to specify the name of the SG and database to dismount).
At this point, you could try to move the passive-copy files into the production locations, so that the paths are not altered. This option is possible only if the disk itself is still available and only the data became corrupted. If you’re able to do so (able both physically and within a reasonable time frame to meet your high-availability objectives), move the files, then run the following command to restore activation of the database:
Restore-StorageGroupCopy ` -Identity:If you want to quickly move to your passive copy and activate the SG with a new database path, run the following command:
Restore-StorageGroupCopy ` -Identity: ` -ReplaceLocations:$trueNow you’ll need to remount the database again. You can do so through Exchange Management Console by selecting the mailbox and choosing the Mount Database option from the Actions pane.
Whew! That was a close call. But everything is back to normal right? Not quite. Now you have no high-availability solution in place; you’re vulnerable to a single point of failure where your only option would be to restore from a backup. So, while patting yourself on the back for quick thinking and minimal time and data loss, get your system prepared for LCR again. You might need to replace the disk on which the active copy was residing. Or, in the case of a corrupted database, the disk could be fine and you might just need to reconfigure LCR between the two disks. Be sure to make such contingencies part of your preparation list.
Enabling LCR for a New SG and Mailbox Database
The process for enabling LCR while creating a new SG is somewhat simpler than doing so for an existing SG in the sense that you perform the process within one dialog box. To enable LCR for a new SG, perform the following steps:
From Exchange Management Console, expand Microsoft Exchange, then expand Server Configuration and select Mailbox.
Select the server you want to add the new SG to. Then, from the Actions pane, select New Storage Group.
In the New Storage Group dialog box, which Figure 5 shows, enter a name in the Storage group name box.
Use the Browse buttons to specify the location of your active log and system files.
Select the Enable local continuous replication for this storage group check box.
Using the Browse buttons, specify the location of the LCR passive copy system files and log files. Keep in mind that you can’t specify the location of a preexisting LCR copy; that is, the locations must be unique.
Check your information to make sure it’s correct, then click New.
After the SG has been created, click Finish.
Your next step is to add the database. If you select the new SG, then select New Mailbox Database from the Actions pane. You’ll be given the options to determine the location of your mailbox and LCR databases, as Figure 6 shows.
Enter a name in the Mailbox database name text box and determine the paths for your database and LCR replication database. Click New. Then you’ll see the creation process with a progress bar until it reports back to you that the process is completed.
LCR in Perspective
Exchange 2007’s LCR is a tremendously affordable high-availability solution; to implement it, you need only a single server running Windows Server 2003 Standard Edition and Exchange 2007 with an extra disk. But LCR has some limitations. If your server’s power supply dies, the motherboard tweaks out, or something else happens that causes the system to fail, your system’s availability is gone. You might want to consider another of Exchange 2007’s high-availability options, Cluster Continuous Replication (CCR) or Single Copy Cluster (SCC), which are more costly than LCR because of their hardware and software requirements. (An additional high-availability option, Standby Continuous Replication—SCR—will be available in Exchange 2007 SP1. For quick look at this feature, see the sidebar “Standby Continuous Replication in Exchange 2007 SP1.”) Stay tuned for an upcoming article, in which I’ll discuss the steps for configuring CCR.
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
