Cluster solutions vary from one Exchange Server version to another. In this tip, expert Brien Posey gives an overview of the different clustering options available in Exchange Server 2007.
Client access servers
With Exchange Server 2007, Microsoft replaced the concept of front-end and back-end servers with five distinct Exchange Server roles. Exchange Server 2007's Client Access Server (CAS) role replaced the front-end servers that were in Exchange Server 2003.
A client access server is little more than a Web server, so Microsoft doesn't offer any failover clustering capabilities for it. Your options for clustering client access servers are the same as they were for clustering Exchange 2003 front-end servers. You can create a Network Load Balancing (NLB) cluster or you can distribute the workload using DNS round robin.
Clustered mailbox servers
Mailbox servers are the Exchange Server 2007 equivalent to back-end servers. Mailbox servers host mailbox and/or public folder databases. Microsoft provides you with several different options for clustering mailbox servers.
Single copy clusters
Exchange 2003 mailbox server clusters rely on the use shared storage. This type of clustering exists in Exchange Server 2007 and is known as a single copy cluster (SCC). Single copy clusters are a type of failover cluster in which both cluster nodes are connected to the same storage array.
Local continuous replication
Local continuous replication (LCR) isn't a true clustering solution, but it is similar to some of the other clustering methods. LCR is designed to create a backup copy of the mailbox database on a separate disk within a mailbox server.
As database transactions occur, they are written to transaction log files. As each of these 1 MB log files fills up, Exchange Server uses log shipping to copy the transaction log to an alternate disk within the server. The logs are then replayed into a secondary copy of the database.
LCR does not provide any sort of automatic failover; however, if the hard disk containing the primary copy of the database were to fail, the backup database copy could be used instead of restoring the database from backup. Switching to the backup database is usually a quicker way to recover data than restoring a tape backup. Additionally, the LCR database copy is always current; the backup tape likely is not.
Cluster continuous replication
Cluster continuous replication (CCR) is very similar to LCR in that Exchange Server uses log shipping and replay to create a secondary database copy. The difference between the two is that LCR stores the secondary database locally, while CCR stores the secondary database on a separate server.
CCR is a true clustering solution. But in order to use it, you must create a Majority Node Set Cluster through Windows prior to deploying Exchange Server. The CCR deployment process requires two servers -- one designated as the active cluster node and the other designated as the passive cluster node.
Normally, a majority node set cluster requires a minimum of three cluster nodes because most of the nodes have to remain online in order for the cluster to maintain quorum . It is impossible to have a majority in a two-node cluster.
To get around this issue, CCR uses a majority node set file-share witness. A special file share is created (usually on the hub transport server) and this file share takes the place of the third node. No clustered mailbox server data is stored on the file share. The file share exists solely as a mechanism to allow the cluster to maintain quorum during failover.
Standby continuous replication
Standby continuous replication (SCR) was introduced in Exchange 2007 SP1. SCR uses the same log shipping and replay mechanisms that LCR and CCR use, but also allows for some new database availability scenarios.
In a continuous replication cluster, you have active and passive cluster nodes. In SCR, these nodes are actually called source nodes and target nodes. This is an important distinction because, unlike CCR, an SCR source can have multiple targets. Although there is technically no limit to the number of targets SCR can use, Microsoft recommends using no more than four targets per SCR source.
Having multiple targets allows you to have a copy of an Exchange database onsite and another copy in a separate data center. SCR also enables interesting high-availability scenarios because targets don't have to be standalone mailbox servers as they did in CCR. An SCR target can actually be a failover cluster. Another advantage of SCR is that log-file playback can be delayed on targets. If a log file were to become corrupted, the corrupt file won't instantly be replayed into the database copies.
ABOUT THE AUTHOR:
Brien M. Posey, MCSE, is a seven-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. 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.
This was first published in March 2010