Creating a Two Node CCR Cluster on Exchange 2007
Introduction
In this article I will cover setting up and configuring
Exchange 2007 in a two node Cluster Continuous Replication (CCR) cluster. CCR clustering
is new to Exchange 2007 and provides the ability to cluster without the
requirement of an
expensive shared storage system.
Exchange 2007 provides support for two different types of
clustering. The first one, Single
Copy Cluster (SCC), requires shared storage and uses a single database file
for each store database. SCC clusters are basically the same as traditional
clusters in early versions of Exchange, with some improvements in Exchange 2007. SCCs still require shared storage in the form of SCSI, iSCSI, SAS, or SAN
storage. The second type of clustering is Cluster
Continuous Replication
(CCR). CCR is similar to Local
Continuous Replication (LCR) clusters where two copies of the Exchange storage
group, and all stores within it, are made. In both LCR & CCR changes are
written to the primary copy and transaction log files are created. Then the
transaction log files are copied, called log shipping, to the location of
the secondary database, in the case of LCR this copy is located on the same
server. With CCR the database and transaction logs files are copied to the
secondary server, passive node, in the two node cluster. On initial setup the
database files are copied, or seeded, to the secondary server. After the
initial settings of the databases only transaction logs are sent to the
secondary server.
In the case of database or storage system failure in LCR the
secondary database can be mounted, assuming the secondary database isn't corrupted
and is on a different storage system. With CCR if the entire server fails the
other server in the CCR cluster becomes the primary node and takes control of
the Exchange Clustered Server, called an Exchange Virtual Server in previous
versions of Exchange, using its local database copy. Unlike LCR, CCR requires
Windows Clustering to be setup and configured, similar to SCC. Where LCR only
requires a few steps to enable the setup process for CCR and SCC is more
complex due to the pre-requisite of Windows clustering. While some documents
and articles have put LCR under clustering it really isn't since it does
not provide redundancy in the case of system failure or planned server downtime.
A comparison of
the different high
availability solutions in Exchange 2007
|
|
LCR
|
CCR
|
SCC
|
|
Failure or planned downtime of one node
|
No Protection
|
Protected
|
Protected
|
|
Database corruption
|
Probable Protection1
|
Probable Protection1
|
No Protection
|
|
Failed local storage system (i.e. SCSI card)
|
Protected2
|
Protected
|
Protected3
|
|
Failed disk subsystem
|
Probable Protected2
|
Protected
|
No Protection
|
|
Data center failure
|
No Protection
|
Probable Protected
4
|
No Protection
|
|
Utilizes
Windows clustering
|
No
|
Yes
|
Yes
|
|
Can use low cost storage systems
|
Yes
|
Yes
|
No
|
|
Storage requirements
|
Double
|
Double
|
Single
|
|
Backup databases without impacting server
|
Partial5
|
Yes
|
No
|
1 If database corruption wasn't replicated to the copy
2 If second copy is on a different storage system
3 If the failure was isolated to one node, i.e. SCSI
card
4 If the 2nd node is located in a second
datacenter and the file share witness is accessible by it
5 If the second copy is located on a different storage
system the impact will be less. With CCR the primary server is not affected at
all.
The three different high available
options in Exchange 2007
|
|
|
|
Figure 1 - Single Copy Clusters
|
Figure 2 - Cluster Continuous Replication
|
Figure 3 - Local Continuous Replication
CCR differs from SCC because it does not require a shared
storage system or any special hardware to provide clustering support. CCR
utilizes a majority node set (MNS) cluster configuration. A MNS cluster keeps
a local copy of the quorum data and replicates all changes to the other nodes
in the MNS cluster over the network.
While this solution provides the ability
to have a low cost cluster it also has a few limitations. The biggest issue is
what happens when one node is unavailable. Since both nodes could be on-line
and the issue might just be network related, neither node could become the
primary and take over the cluster. In order to address this issue a 3rd
"node" or a voter node must be configured. Microsoft added support for a file
share witness that acts as a 3rd vote in a two node MNS cluster.
With a file share witness configured if a node detects that the other node in
unavailable it will attempt to contact the file share witness to check for the
other nodes status and to verify that it is accessible. If the file share
is unavailable the node will not take control over the cluster.
Because of this
architecture the file share becomes a single point of failure in a two node SCC
configuration. Currently in Exchange 2007 only a two node CCR cluster is supported. Thus, it should be understood that a CCR cluster is not as fault
tolerant as a SCC cluster can be.
In a case where one node is down and the
file share witness is also down, a complete failure occurs. In order to
restore service, you could
configure the second node to use a different file share witness and then fail the cluster over to this node. At this time this may
not be an approved way to bring the second node on-line in the case of a failure
of the primary node and normal file share witness, but it does work. The best solution
would be to have a file share witness, at one site, the primary node at another,
and the secondary node at a third. Then all three locations would need to be
connected by fast redundant links and the servers must all be configured to be
in the same AD site. This would provide datacenter failure redundancy with CCR,
but is not feasible for most organizations. In addition, E2k7 doesn't
currently support CCR clusters across subnets. This support will come with
Longhorn server and maybe (based on rumors only) in a SP for Exchange 2007. Another option is to add a 3rd
node to the MNS cluster for voting purposes only, Exchange would not be
installed on the 3rd node.
With the above points covered I
will now go over setting up a CCR cluster. The information covered in this
article should not be used in production since certain steps and configuration
options are skipped to simplify the article.
Environment Configuration
This entire setup was done using
VMWare 5.5 Workstation; guest operating systems were running Windows 2003 x64
Enterprise Edition and all updates from Windows Update.
Below are the reasons why I use VMWare, and will
continue to until Virtual Server or VPC add support for them:
-
x64 guest machine virtualization
-
You don't
even have to be running a x64 host OS. Therefore, I can run Exchange 2007
x64 on my laptop, which has an AMD Turion 64 CPU, while running Windows XP
32-Bit as the host OS.
-
Multiple snapshot support and management
-
Support for more than one CPU
-
Can open VS, VPC, and VMWare images
I am sure there are other reasons
some people prefer VMWare over the Microsoft products but the top 2 reasons above are
the absolute must haves for someone that test multiple operating systems, products, and has
over 50 VM images.
VM\Lab Environment overview
o Windows
2003 R2 x86 (32-bit) Edition
o AD
running in Native 2003 mode
o IP:
192.168.1.60
o Windows
2003 R2 x64 Enterprise Edition
o Roles:
Hub Transport and Client Access
o IP:
192.168.1.61
o Windows
2003 R2 x64 Enterprise Edition
o Roles:
Mailbox Primary Cluster node
o IP:
192.168.1.62
o Single
disk, in a production environment you would want multiple disks
o Windows
2003 R2 x64 Enterprise Edition
o Roles:
Mailbox Secondary Cluster node
o IP:
192.168.1.63
o Single
disk, in a production environment you would want multiple disks
