Unsupported Configuration - Fan-in failover - with overlapping Access Zones single shared IP Pool

Unsupported Configuration - Fan-in failover - with overlapping Access Zones

Overview

The following testing was done to document the effect of overlapping access zones on fan in shared target cluster failover.  Note: This is not a production supported configuration.   This was documented with manual steps to show how fan in can work and impacts of this configuration.

It does not block collisions of overlapping share names or NFS alias on the target DR cluster.  Shared IP pool is also required to get this configuration to work without blocking errors in Eyeglass.

This is documented for information purposes only.  No support of this configuration will be offered.


Test Setup Configuration


Source and Target Clusters

3 Clusters (2 Source Clusters and 1 Target Cluster):

  • Cluster20 as the Source01 Cluster

  • Cluster31 as the Source02 Cluster

  • Cluster21 as the Target Cluster

All 3 Clusters are using the same Access Zone for the shares: System access zone

Shares:

  • Share-A (path /ifs/data/source01) is configured on Source01

  • Share-B (path /ifs/data/source02) is configured on Source02


SyncIQ Policies

Configured  2 SyncIQ Policies:

  • synciq-S01  - to replicate from Source01 to Target

  • synciq-S02 - to replicate from Source02 to Target

On Target created the following paths:

  • /ifs/data/target01  as the target for /ifs/data/source01

  • /ifs/data/target02 as the target for /ifs/data/source02


SmartConnect Zone Name and Alias

The following table shows the initial setup:


Source01

Source02

Target

Zone Name

cluster20.ad1.test

cluster31.ad1.test

cluster21.ad1.test

Alias

igls-system-cluster20

igls-system-cluster31

igls-system-cluster21


Eyeglass

Configure the Eyeglass for Access Zone Failover as per this guide: http://documentation.superna.net/eyeglass-isilon-edition/configure/access-zone-failover-guide

Test Scenarios:

  1. Eyeglass Access Zone Failover from Source01 to Target

  2. Eyeglass Access Zone Failover from Source02 to Target

  3. Eyeglass Access Zone Failback from Target to Source01

  4. Eyeglass Access Zone Failback from Target to Source02


Test Results:

Eyeglass Access Zone Failover from Source01 to Target

Eyeglass Access Zone failover was performed as per normal and the failover process can be completed successfully.

The end result of this process:



Source01

Source02

Target

Zone Name

igls-original-cluster20.ad1.test

cluster31.ad1.test

cluster21.ad1.test

Alias

igls-system-cluster20

igls-system-cluster31

Igls-system-cluster21

cluster20.ad1.test


Share-A is redirected to cluster21 (Target)

Eyeglass Access Zone Failover from Source02 to Target

Eyeglass Access Zone failover was performed as per normal and the failover process can be completed successfully.  


The end result of this process:


Source01

Source02

Target

Zone Name

igls-original-cluster20.ad1.test

igls-original-cluster31.ad1.test

cluster21.ad1.test

Alias

igls-system-cluster20

igls-system-cluster31

Igls-system-cluster21

cluster20.ad1.test

cluster31.ad1.test


Share-B is redirected to cluster21 (Target)


Before Failback

The following are the states after failover from Source01 ⇒ Target, failover from Source02 ⇒ Target and prior to failback.


Source01

Source02

Target

Zone Name

igls-original-cluster20.ad1.test

igls-original-cluster31.ad1.test

cluster21.ad1.test

Alias

igls-system-cluster20

igls-system-cluster31

Igls-system-cluster21

cluster20.ad1.test

cluster31.ad1.test


Share-A and Share-B are redirected to cluster21 (Target)

SyncIQ Policies

SyncIQ Mirror Policies are enabled in the following directions:

Target ⇒ Source01

Target ⇒ Source02


Failover Readiness

After configure the Source Restriction settings for Mirror Policies, we can see that the Failover Readiness statuses are in green OK.


Policy Readiness:


Failover Zone Readiness:



Eyeglass Access Zone Failback from Target to Source01

Eyeglass Access Zone failback was performed as per normal and the failover process can be completed successfully.

Share-A is redirected to cluster20 (Source01) successfully.

But Share-B is not accessible.


This Failback from Target to Source01 will configure the smartconnect zone names and aliases like the following table:


Source01

Source02

Target

Zone Name

cluster20.ad1.test

igls-original-cluster31.ad1.test

igls-original-cluster21.ad1.test

Alias

Igls-system-cluster20

cluster21.ad1.test

cluster31.ad1.test

igls-system-cluster31

Igls-system-cluster21

igls-original-cluster31.ad1.test


From that states, it makes Share-B is not accessible and it will prevent the failback from Target to Source02.

The Policy Readiness shows the following state:

But the Zone Failover Readiness is generating the following status as displayed here:

DR Failover Status for Target ⇒ Source02 is Failed Over. It will not allow the Failback from Target to Source02.

The smartconnect zone name for the Source02 is not pointing to the correct cluster as that zone name has been moved to the Source01 cluster. The Share-B becomes unreachable.

Workaround

In order to rectify the error state and to prepare for the Failback from Target to Source02, we need to manually modify the smartconnect zone name and alias.

After modified, the zone names and aliases are shown in the following table:


Source01

Source02

Target

Zone Name

cluster20.ad1.test

igls-original-cluster31.ad1.test

cluster21.ad1.test

Alias

Igls-system-cluster20


igls-system-cluster31

Igls-system-cluster21

cluster31.ad1.test


We also need to update the SPN accordingly (delete additional SPNs on Source01).

With this modification, it will redirect the Source02 smartconnect zone name to the Target Cluster and it makes the Share-B reachable.

The Policy Readiness shows the following status:


And now the Failover Zone Readiness will be updated as shown here:

The readiness status for failback from Target to Source02 is turned to OK.

Note that the status for failback from Target to Source01 is turned to Error, but this can be ignored as currently the direction between Source01 and Target is Source01⇒ Target, which has the readiness status as OK.


Eyeglass Access Zone Failback from Target to Source02

As the Failover Readiness status for Target ⇒ Source02 is OK, now we can perform the Eyeglass Access Zone failback as per normal and this failback process can be completed successfully.

Share-A and Share-B are accessible.

Share-A is accessed from Source01

Share-B is accessed from Source02


The smartconnect zone names and aliases after this failback process has completed:



Source01

Source02

Target

Zone Name

cluster20.ad1.test

cluster31.ad1.test

igls-original-cluster21.ad1.test

Alias

Igls-system-cluster20


Igls-system-cluster31

cluster21.ad1.test

Igls-system-cluster21



The Policy Readiness after this failback will display the following status:

The Failover Zone Readiness status will also shown as OK for both pairs Source01 ⇒ Target and Source02 ⇒ Target :

Warning:  the subsequent Failover and Failback processes might also require additional manual steps to modify the SmartConnect Names and Aliases as well update the SPNs  accordingly.