Switchover in an N-Shared x N-Shared Configuration

In a multi-shared storage environment between two sites (as shown in the diagram below), each server in each site has access to the storage being shared between the servers at that site. When a DataKeeper mirror is created, one server in each site will be designated as the mirror endpoints of the mirror.

(Note: N represents a number from 1 to N; e.g. 4×1 represents 4 servers sharing a disk replication to another site with 1 server.)

In the following example (3×3), a DataKeeper mirror has been created to replicate the X: volume from Site A to Site B.

Note that there are three servers sharing storage in Site A. Those servers are:

• S1 – Currently the SOURCE of the mirror

• S2 – Shared Source (locked)

• S3 – Shared Source (locked)

Because S1 is the SOURCE of the mirror, we refer to S2 and S3 as shared source systems. This implies that these servers currently share access to the volume on the SOURCE side of the mirror, but they cannot currently access the volume because they are not defined as the source of the mirror. (Note: A user on S2 will see “access denied.”)

There are three other servers sharing storage in Site B.

• T1 – Currently the TARGET of the mirror (locked as the primary target)

• T2 – Shared Target (locked)

• T3 – Shared Target (locked)

They share access to the Target volume currently defined to T1. T2 and T3 are referred to as shared target systems. File system access to the target volume is locked on all three systems.

All six servers are part of the WSFC cluster, and all of the WSFC protected resources are currently active or “ONLINE” on S1.

Given this initial replicated configuration, it is important to understand which servers are eligible to “take over” and become the ACTIVE server. With a DataKeeper mirror in place, the following rules apply:

1. Switchover to a Shared Source server (S2, S3) is allowed.

2. Switchover to the current Target server (T1) is allowed.

3. Switchover to a Shared Target server (T2, T3) is not allowed; however, there is a two-step process to switch over to these servers.

• First, switch over to the target T1.

• Then you can switch over to either T2 or T3 server.

Switchover to a Shared Source Server

In our example, either S2 or S3 is eligible to become the ACTIVE server and source of the mirror. If we switch the protected resources to S2, S2 will become the new SOURCE of the mirror and T1 will remain the Target of the mirror.

1. Initial Mirror Configuration: S1 → T1

2. Action: Switchover to S2 (Bring resources ONLINE in WSFC)

3. Final Result: S2 → T1

Switchover to the Current Target System

In our example, switching the protected resources to T1 will effectively reverse the mirror direction making T1 the new SOURCE of the mirror and S1 will become the Target of the mirror.

1. Initial Mirror Configuration: S1 → T1

2. Action: Switchover to T1 (Bring resources ONLINE in WSFC)

3. Final Result: T1 → S1

Switchover to a Shared Target System

This is not allowed. The switchover operation will fail, but as noted above, a two-step process can be used.

1. Initial Mirror Configuration: S1 → T1

2. Action: Switchover to T1 (Bring resources ONLINE in WSFC)

3. Intermediate Configuration: T1 → S1

4. Action: Switchover to T2 (Bring resources ONLINE in WSFC)

5. Final Result: T2 → S1

Failover

In a failover scenario where the current source system fails or a resource failure triggers a group failure, Failover Clustering attempts to fail over the resource group to another node in the cluster. Factors affecting the failover include the following:

• Node Failure vs Resource Failure

• Preferred Owner List is set for the Resource Group vs Preferred Owner List is not set

• Possible Owners

The following article describes how Failover Clustering determines which node to fail over to.

http://blogs.msdn.com/b/clustering/archive/2009/08/11/9863688.aspx

Important: In an N x N configuration, DataKeeper supports failover to any one of the shared source systems or to the target system. If Failover Clustering tries to online the group on an ineligible system (one of the shared target systems), that online will fail. Failover Clustering will continue trying to online the group on different nodes and eventually succeeds when a system that is eligible for failover is tried.