Exchange Server 2007 hardware planning for continuous replication

When planning Exchange Server 2007 hardware requirements for continuous replication, consider using a storage area network (SAN). Surprisingly, a SAN may be a more cost-effective storage option for large Exchange deployments than direct attached storage (DAS).

Because Microsoft Exchange Server databases tend to be large, the disaster recovery process can be very time consuming, resulting in lost productivity from extended downtime. In Exchange Server 2007, Microsoft addresses this disaster recovery issue with a new feature called continuous replication. The idea behind continuous replication is that Exchange Server maintains a spare copy of the database and log files in a separate location. If a failure occurs, Exchange will have a copy of the database that is ready to use.

The Exchange Server hardware planning that goes into using continuous replication is critical. At the same time, a simple hard disk failure should not warrant switching to the backup copy of the Exchange database. In this article, I will explain how to properly plan your hardware needs to effectively use continuous replication.

LUNs explained

The term

    Requires Free Membership to View

LUN -- logical unit number -- was originally associated with the SCSI bus. Each device on a SCSI bus is assigned a unique LUN number so that the bus can differentiate one device from another. Originally, a LUN was a way to identify a specific device (usually a disk) within the system.

Many terms that applied to SCSI busses were adopted because the first storage area networks (SANs) were SCSI-based. The term LUN has changed a little over time though. When LUN is used in the context of a SAN, it doesn't necessarily refer to a single disk on a SCSI bus (although it can). Instead, a LUN usually refers to a virtual volume or partition on a RAID array, rather than to a specific and entire disk.

Continuous replication

Exchange 2007 offers three different types of continuous replication: local continuous replication (LCR), cluster continuous replication (CCR), and standby continuous replication (SCR). Each of these replication technologies uses log shipping to copy transaction logs to an alternate location, but these three technologies work differently.

Local continuous replication copies Exchange Server data to another location on the same server that houses the storage group being protected. LCR is the simplest form of continuous replication, but its downfall is that the backup copy of the database resides on the same server as the primary copy. Therefore, the server can become a single point of failure.

Cluster continuous replication works similarly to LCR, but the backup copy of the Exchange Server data resides on a different server than the primary copy. Standby continuous replication is similar to CCR, except the data is replicated to a standby server that must be manually activated if the primary server fails.

The rest of this discussion will focus on LCR. Most of the issues that apply to LCR also apply to the CCR and SCR, but you must take into account the requirement for multiple servers.


When it comes to implementing continuous replication, you have two primary storage options: direct attached storage (DAS) or storage area network (SAN). Both technologies have their advantages and disadvantages.

Direct attached storage uses storage devices that are directly attached to the Exchange server. Typically when you hear someone refer to direct attached storage, they are talking about a SCSI or a SATA-based RAID array. Keep in mind, though, that a physical RAID array can be split into multiple volumes or partitions.

A minimum of four LUNs is required with continuous replication. One LUN stores the primary copy of the Exchange information store. The second LUN stores the primary copy of the transaction logs. The third LUN stores the replica of the information store, and the fourth LUN stores the transaction log replicas. This requirement applies regardless of the type of continuous replication that is being used.

Exchange Server replication occurs at the storage-group level. There is a limit of one database per replicated storage group. Non-replicated storage groups are not subject to this limitation. Although the minimum requirement to use continuous replication is four LUNs, the number of LUNs required grows exponentially as you increase the number of storage groups that you're replicating. You will need four LUNs for each replicated storage group.

Using DAS, you could meet the storage requirements by creating all of the LUNs on a single RAID array. This is not recommended however.

Placing all of the LUNs on a single RAID array can severely affect Exchange Server performance. Having all of the LUNs on a single array constitutes a single point of failure. If something were to happen to the array, both copies of the database would be lost.

More on Exchange storage:
Tutorial: iSCSI SAN storage for Microsoft Exchange Server

Exchange Server 2003 storage management options
For DAS, Microsoft recommends using two separate RAID controller cards, connected to two separate PCI slots. The two arrays will function completely independently of each other.

Exchange Server doesn't require a specified RAID level for an array, but Microsoft recommends using RAID 10 (mirrored stripe sets) for RAID arrays. In this case, you can have the performance of a stripe set, with the fault tolerance of mirroring.

Microsoft cautions against using RAID 5 arrays (striping with parity) with Exchange Server 2007. Due to Exchange 2007's design and architecture, RAID 5 arrays do not deliver the high level of performance that they did in Exchange 2003.

To reiterate, Microsoft recommends that Exchange servers using LCR have at least two RAID 10 arrays, each containing two LUNs. One array is used for the primary data copy, while the other is used for the replica. Ideally, you would want to put each LUN on a separate array for the best possible performance and fault tolerance, but this often is impractical with direct attached storage.

A RAID 10 array requires an absolute minimum of four hard disks, but more disks are generally recommended for performance reasons. When you consider the hardware costs associated with setting up LCR as recommended, it may be better to connect Exchange to a SAN instead. SANs tend to be expensive. However, if you need to set up continuous replication for multiple servers, each of which contain multiple storage groups, then using a SAN ultimately may save you money on hardware and maintenance costs.

Regardless of whether you are using a SAN or DAS, there are a few more points to consider when hardware planning. First, disk controllers must have their own battery backup, because some data may be cached before it is committed to disk. A power failure could cause cached data to be lost, resulting in database corruption.

SANs typically use high-end hardware, so having disk controllers with battery-backed caches is almost a given. Whether you're using a SAN or DAS though, it's important to verify that your disk controllers have a battery.

In addition, Microsoft recommends that primary LUNs and counterpart LUNs on replica arrays are same size. Both SANs and DAS allow you to create LUNs or volumes of a specific size. The difference is that on a SAN, the LUN is created from a pool of available disk space, and the remaining space is available to create additional LUNs. When DAS is used, any remaining space after the necessary LUNs are created often goes to waste.

About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.

Do you have comments on this tip? Let us know.

Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.

This was first published in June 2008

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.