Recommendations for enabling a two node Standby Continuous Replication target based on a Single Copy Cluster (Exchange 2007 SP1)

In this blog post I will assume there exists a source cluster that consists of a two node Exchange 2007 SP1 Single Copy Cluster (SCC) hosted on either Windows 2003 or Windows 2008. 

Standby Continuous Replication (SCR) was designed, in this type of deployment, to have a target that is a single node cluster.  Recently I've received several requests on how this could be extended to a two node cluster functioning as the SCR target.

Single copy clusters make having a two node target more complicated because of having to deal with the shared storage.  It is a requirement of SCR that the same drive letters / paths used for databases, logs, and system files on the source also exist on the target.  Also, we must take into consideration the fact that the storage necessary for replication can only be owned by a single node (shared nothing cluster model), and therefore only one node of the target cluster can be subscribed as the SCR target.

If you desire to have a two node SCR target, consider making the following configuration changes to assist in ensuring that the physical disk resources are owned on the correct node.

Windows cluster allows administrators to specify, on the properties of clustered groups, a list of preferred owners.  The preferred owners list on an Exchange cluster is generally cosmetic.  When preferred owners is combined with a Failback Policy, the settings become more then cosmetic.  A preferred owners group allows the administrator to establish the list of nodes, in order, that they prefer the group be hosted on when nodes are available.  When combined with a failback policy, the preferred owners list tells the cluster where and when to move the group automatically when specific nodes are available.  Let's look at a few examples of this as it applies to our SCR target.  The preferred owners list and failback policy will be invoked anytime cluster membership also changes, for example, when rebooting a node that is a member of the cluster.

Example #1:

I have a two node SCR target with a group configured to hold my physical disk resources.  I have set a preferred owners list of NodeA then NodeB and a failback policy of immediate.  The group is currently owned on NodeA.  At patch management time I apply the necessary hotfixes to NodeB and reboot the server.  When NodeB has successfully rejoined the cluster, I then apply the patches to NodeA and reboot.  The disk group automatically moves from NodeA to NodeB.  When NodeA successfully rejoins the cluster, the disk group automatically moves back to NodeA.  Replication can now successfully resume since the underlying storage necessary for replication is present on NodeA, and NodeA is subscribed as the SCR target.  In this instance cluster membership changed during the reboot causing the cluster to evaluate the preferred owners list and failback policy and take actions as defined.

Example #2:

I have a two node SCR target with a group configured to hold my physical disk resources.  I have set a preferred owners list of NodeA then NodeB and a failback policy of immediate.  The group is currently owned on NodeA.  NodeA experiences a blue screen condition due to a faulty storage driver.  The disk group automatically moves from NodeA to NodeB.  When NodeA automatically reboots and successfully rejoins the cluster, the disk group automatically moves back to NodeA.  Replication can now successfully resume since the underlying storage necessary for replication is present on NodeA, and NodeA is subscribed as the SCR target.  In this instance cluster membership changed during the reboot causing the cluster to evaluate the preferred owners list and failback policy and take actions as defined.

Example #3

I have a two node SCR target with a group configured to hold my physical disk resources.  I have set a preferred owners list of NodeA then NodeB and a failback policy of immediate.  At patch management time I apply the necessary hotfixes to NodeB and reboot the server.  When NodeB has successfully rejoined the cluster, I launch failover cluster management and manually move the disk group from NodeA to NodeB.  I then apply the patches to NodeA and reboot the server.  When NodeA successfully rejoins the cluster, the disk group automatically moves back to NodeA.  Replication can now successfully resume since the underlying storage necessary for replication is present on NodeA, and NodeA is subscribed as the SCR target.  In this instance cluster membership changed during the reboot causing the cluster to evaluate the preferred owners list and failback policy and take actions as defined.

Example #4

I have a two node SCR target with a group configured to hold my physical disk resources.  I have set a preferred owners list of NodeA then NodeB and a failback policy of immediate.  An administrator, using failover cluster management, moves the disk group from NodeA to NodeB.  The group is not moved back.  Replication will enter a failed state for all instances since the storage necessary for replication to function is no longer present on the node subscribed to SCR.  Alerting informs the administrator there is an issue.  It is determined that the disk group is owned on the wrong node, and is manually moved back to NodeA.  Soon after replication successfully resumes since the underlying storage necessary for replication is present on NodeA, and NodeA is subscribed as the SCR target.  In this instance cluster membership did NOT change, so the preferred owners list and failback policy was not applied. 

Establishing the disk group, Preferred Owner, and Failback Policy in Windows 2003

Use the following steps to establish the disk group, preferred owners list, and a failback policy in Windows 2003.

• Launch cluster administrator and connect to the SCR target cluster.
• Under groups give in the left hand pane, create a new cluster group. 

• • Name the group as appropriate.
  • By default disks found on a shared bus have physical disk resources created for them in default groups (ie Group0, Group1, Group2).  Move physical disk resources from the default groups into the new group created.
  • If mount points are being used physical disk resources must be created manually.  Please sure that all mountpoint disks are created and made dependant on the lettered volume hosting them (refer to - https://support.microsoft.com/default.aspx?scid=kb;[LN];280297).

• Right click on the new group - select properties.

• On the general tab is the preferred owners list.  Using the modify button, add preferred owners to the list and adjust the order as necessary.  (The server listed first in order will be the node most preferred to own the group).

•  

•  

• After changing preferred owners (if necessary), select the failback tab.

  • Select the radio button allow failback.
  • Select the radio button immediately.

•  

• The configuration of preferred owners and a failback policy can be performed with command line.

• To set the list of preferred owners and configure failback:

•  

• cluster.exe <ClusterFQDN> group <GroupName> /setOwners:<FirstNode>,<SecondNode>

• cluster.exe <ClusterFQDN> group <GroupName> /prop AutoFailbackType=1

  Examples of these commands:

   

• cluster.exe 2003-Cluster3.exchange.msft group SCRTargetDisks /setOwners:2003-Node1,2003-Node2

• cluster.exe 2003-Cluster3.exchange.msft group SCRTargetDisks /pro AutoFailbackType=1

Establishing the disk group, Preferred Owner, and Failback Policy in Windows 2008

• Launch failover cluster management and connect to the SCR target cluster.
• In the left hand pane, under the cluster name, right click on Services and Application, select more actions -> Create Empty Service of Application

• Under services and applications you will now see a group named "New service of application".
• Right click on "New service or application", select rename, and assign an appropriate name.

• Right click on the group, select add storage.  From here, choose the storage that should be added to this group.
  • Note:  By default Windows 2008 adds both lettered volumes and mounted volumes (mount points) to the available storage group at cluster creation.  Mounted volumes must manually be made dependant on their lettered physical disk.  Please update dependencies if necessary.
  • If the desired storage does not appear in the storage picker ensure that it has been added to the available storage group.  Only storage that has first been added to the available storage group is allowed to be added to services and applications.

• Once storage has been added, right click on group and select properties.
• On the general tab, select the checkbox next to each node of the cluster.  Use the up / down buttons to establish the preferred order.  Machines appearing first in the list will have preference over other nodes.

• Select the Failover tab.
  • Under the failback portion, select the radio button next to "Allow Failback".
  • Under "Allow Failback" select the radio button next to "Immediately".

• Apply the changes to complete the configuration.

The configuration of preferred owners and a failback policy can be performed with command line.

To set the list of preferred owners and configure failback:

• cluster.exe <ClusterFQDN> group <GroupName> /setOwners:<FirstNode>,<SecondNode>
• cluster.exe <ClusterFQDN> group <GroupName> /prop AutoFailbackType=1

Examples of these commands:

• cluster.exe 2008-Cluster3.exchange.msft group SCRTargetDisks /setOwners:2008-Node1,2008-Node2
• cluster.exe 2008-Cluster3.exchange.msft group SCRTargetDisks /pro AutoFailbackType=1

Consider reviewing the following references for more information.

https://support.microsoft.com/kb/197047

https://support.microsoft.com/kb/299631

https://support.microsoft.com/kb/823955