DR Configuration Guides
Access Zone Failover - SyncIQ Configuration for 3 site
Home

Access Zone Failover - SyncIQ Configuration for 3 site



The source cluster SyncIQ policy path must fall inside the Access Zone for Target cluster 1,   a Second SyncIQ policy can use the same source path (recommended).  See the configuration guide below.

Not Recommended

Examples where failover leaves some data behind after failover and moves networking (SmartConnect Zones) to Target cluster.  After Failover both SmartConnect zones would failover together leaving the namespace and data stranded since the SyncIQ policies only failed over a portion of the data.

SyncIQ Policy multi Site support Matrix

Access Zone Path for these examples is /ifs/data/AZ1

Unsupported configuration

 Source Cluster        Target Cluster 1Target Cluster 2
SyncIQ policy 1 /ifs/data/AZ1/datax 
SyncIQ policy 2/ifs/data/AZ1/marketing x
SmartConnect Zone 1data.example.comxx
SmartConnect Zone 2marketing.example.comxx

A supported configuration requires that all data and all DNS name space fails over together to achieve fully automated Access Zone failover.  

Recommended Policy Configuration

 Source ClusterTarget Cluster 1Target Cluster 2
SyncIQ policy 1 /ifs/data/AZ1/datax 
SyncIQ policy 2/ifs/data/AZ1/marketing x
SyncIQ policy 3/ifs/data/AZ1/data x
SyncIQ policy 4/ifs/data/AZ1/marketingx 
SmartConnect Zone 1data.example.comxx
SmartConnect Zone 2marketing.example.comxx

Multi Site Failover and Failback Behaviours

OperationDirectionSupportedRequire Manual Step Prior to Initiate Eyeglass Access Zone Failover
FailoverA ⇒ BYesYes - refer to this diagram and Access Zone Failover - SyncIQ Configuration for 3 site 
FailbackB ⇒ AYesNo - refer to this diagram  and Access Zone Failover - SyncIQ Configuration for 3 site  
FailoverA ⇒ CYesYes - refer to this diagram  and Access Zone Failover - SyncIQ Configuration for 3 site  
FailbackC ⇒ AYesNo - refer to this diagram  and Access Zone Failover - SyncIQ Configuration for 3 site  

Zone Readiness

This section gives example of the Zone Readiness status and Network Mapping between Source-Target#1 and Source-Target#2 pairs.

For the purpose of this example we use the following names:

SiteCluster Name
A (Source)cluster20
B (Target#1)cluster21
C (Target#2)cluster31

There are two Access Zones on all those three clusters: zone01 and zone03

Zone Readiness - Initial Configuration / before Failover / after Failback

This is the  Zone Readiness for Initial Configuration / before Failover / after failback state. As we can see from this figure, that both Source-Target Pairs (A - B and A - C)  are listed in this DR Dashboard’ zone readiness window.

This shows that a failover choice can be made to any target cluster in Green OK state (Warning status also allowed).

 

Network Mapping - Initial Configuration: A B Zone01

Network Mapping - Initial Configuration: A B Zone03

Network Mapping - Initial Configuration: A C Zone01

Network Mapping - Initial Configuration: A C Zone03

This table shows the SmartConnect Zone Name and SmartConnect Alias Name mappings for this Initial Configuration / before failover / after failback states:

Source - Target PairSyncIQ directionZone NameSmartConnect Zone NameSmartConnect Alias Mapping
Source ClusterTarget ClusterSource ClusterTarget Cluster
cluster20 - cluster21A Bzone01cluster20-z01.ad1.testigls-original-cluster20-z01.ad1.testigls-zone01p-cluster20igls-zone01p-cluster21
zone03cluster20-z03.ad1.testigls-original-cluster20-z03.ad1.testigls-zone03p-cluster20igls-zone03p-cluster21
cluster 20 - cluster31A Czone01cluster20-z01.ad1.testigls-original-cluster20-z01.ad1.testigls-zone01p-cluster20igls-zone01p-cluster31
zone03cluster20-z03.ad1.testigls-original-cluster20-z03.ad1.testigls-zone03p-cluster20igls-zone03p-cluster31

Before Failback B A

Zone Readiness

This Zone Readiness is for the state before Failback from B to A. As we can see from this figure, that only TargetB(cluster21))-SourceA(cluster20) pairs are listed as available in this DR Dashboard’s zone readiness window. The other pairs (SourceA(cluster20)-TargetB(cluster21) and SourceA(cluster20)-TargetC(cluster31)) are stated as FAILED-OVER.

[Network Mapping - Before Failback B A]  B A Zone01

[Network Mapping - Before Failback B A]  B A Zone03

This table shows the SmartConnect Zone Name and SmartConnect Alias Name mappings for this Before Failback B A state:

Source - Target PairSyncIQ directionZone NameSmartConnect Zone NameSmartConnect Alias Mappings
Source ClusterTarget ClusterSource ClusterTarget Cluster
cluster20 - cluster21A Bzone01STATUS: FAILED OVER
zone03STATUS: FAILED OVER
cluster20 - cluster31A Czone01STATUS: FAILED OVER
zone03STATUS: FAILED OVER
cluster21 - cluster20B Azone01cluster20-z01.ad1.testigls-original-cluster20-z01.ad1.testigls-zone01p-cluster21igls-zone01p-cluster20
zone03cluster20-z03.ad1.testigls-original-cluster20-z03.ad1.testigls-zone03p-cluster21igls-zone03p-cluster20

Before Failback C A

Zone Readiness

This Zone Readiness is for the state before Failback from C to A. As we can see from this figure, that only TargetC(cluster31))-SourceA(cluster20) pairs are listed as available in this DR Dashboard’s zone readiness window. The other pairs (SourceA(cluster20)-TargetB(cluster21) and SourceA(cluster20)-TargetC(cluster31)) are stated as FAILED-OVER.

[Network Mapping - Before Failback C A]  C A Zone01

[Network Mapping - Before Failback C A]  C A Zone03

This table shows the SmartConnect Zone Name and SmartConnect Zone Alias Name mappings for Before Failback C A state:

Source - Target PairSyncIQ directionZone NameSmartConnect Zone NameSmartConnect Alias Mappings
Source ClusterTarget ClusterSource ClusterTarget Cluster
cluster20 - cluster21A Bzone01STATUS: FAILED OVER
 zone03STATUS: FAILED OVER
cluster20 - cluster31A Czone01STATUS: FAILED OVER
zone03STATUS: FAILED OVER
cluster31 - cluster20C Azone01cluster20-z01.ad1.testigls-original-cluster20-z01.ad1.testigls-zone01p-cluster31igls-zone01p-cluster20
zone03cluster20-z03.ad1.testigls-original-cluster20-z03.ad1.testigls-zone03p-cluster31igls-zone03p-cluster20

Summary of Network Mappings

Based on the above example, the following table summarizes the network mappings with zone names and zone alias names:

Initial Configuration / Before Failover / After Failback:

StateAccess ZoneNameCluster20 (A)Cluster21 (B)Cluster31 (C)
Initial Configzone01Zone Namecluster20-z01.ad1.testigls-original-cluster20-z01.ad1.testigls-original-cluster20-z01.ad1.test
Zone Alias Hintigls-zone01p-cluster20igls-zone01p-cluster21igls-zone01p-cluster31
zone03Zone Namecluster20-z03.ad1.testigls-original-cluster20-z03.ad1.testigls-original-cluster20-z03.ad1.test
Zone Alias Hintigls-zone03p-cluster20igls-zone03p-cluster21igls-zone03p-cluster31

After Failover

This table shows the zone names and zone alias names  after failover A B / after failover A C:

StateAccess ZoneNameCluster20 (A)Cluster21 (B)Cluster31 (C)
After Failover A => Bzone01Zone Nameigls-original-cluster20-z01.ad1.testcluster20-z01.ad1.testigls-original-cluster20-z01.ad1.test
Zone Aliasigls-zone01p-cluster20igls-zone01p-cluster21igls-zone01p-cluster31
zone03Zone Nameigls-original-cluster20-z03.ad1.testcluster20-z03.ad1.testigls-original-cluster20-z03.ad1.test
Zone Aliasigls-zone03p-cluster20igls-zone03p-cluster21igls-zone03p-cluster31
After Failover A => Czone01Zone Nameigls-original-cluster20-z01.ad1.testigls-original-cluster20-z01.ad1.testcluster20-z01.ad1.test
Zone Aliasigls-zone01p-cluster20igls-zone01p-cluster21igls-zone01p-cluster31
zone03Zone Nameigls-original-cluster20-z03.ad1.testigls-original-cluster20-z03.ad1.testcluster20-z03.ad1.test
Zone Aliasigls-zone03p-cluster20igls-zone03p-cluster21igls-zone03p-cluster31

Access Zone Failover and Failback Procedures


It is recommended to create SyncIQ Policies that will be used for multi site replications (e.g. to replicate from Site A to Site B and also from Site A to Site C)  with names that reflect the Source-Target pairs.

The following table is an example for 2 SyncIQ Policies per Source-Target pairs:

SyncIQ Policy NameSyncIQ Pairs

AB-synciq-01

AB-synciq-02

A and B

AC-synciq-01

AC-synciq-02

A and C

This name format will help us to identify which Access Zones that we want to failover.

Failover from A to B Procedure:

  1. Prior to initiating Eyeglass Access Zone Failover from A to B,  we need to ensure that there is no existing SyncIQ Mirror Policies from C to A. The recovery resync prep step of this Failover A to B will create Mirror Policies from B to A with same Mirror Target Paths as the C to A (Mirror Target Paths are overlaps). This will make the Mirror Policies from B to A unrunnable and the Eyeglass Failover Job will fail. If there are existing ones, we need to delete them first. Refer to step P1 in the Failover workflow diagrams.
    1. NOTE: The above step MUST be completed before A to C failover, the order matters since the domain mark will be deleted on cluster A once the step above is completed.
  2. Now run a domain mark job on each SyncIQ policy on cluster A. This is a required step since no domain mark exists and will be created during failover process from A to B. The best practise is to run domain mark before failover to ensure the resync prep step does not take a long time to complete. Domain mark can run longer if a the path has a large number of files. NOTE: During the time while domain mark job is running no failover from A to C should be executed until the domain mark job completes on ALL sync polices involved in the failover. Monitor progress from the PowerScale Cluster jobs UI.

  3. Then we can perform Eyeglass Access Zone Failover as per normal. In DR Assistant Wizard, after we selected the source cluster (Cluster A (for this example: name cluster20)) the next wizard screen display the list of available Failover options based on Source-Target-Zone pairs.

        

  1. We need to be careful to select the correct Target Cluster that we want to Failover (A to B or A to C).  For this case we want to failover from A to B. Select a zone that we want to Failover from cluster20 (source) - cluster21 (target)  pairs.
  2. The next screen will gives warning to highlight that this wizard will only perform Access Zone failover from A to B. The other policy on the same Access Zone (A to C) will not be failed over.

  1. Proceed this Access Zone Failover as per normal. Refer to Eyeglass Access Zone Failover Guide for details.
  2. Repeat the same procedure for failover other Access Zones from A to B.

Failback from B to A Procedure:

  1. We can perform Eyeglass Access Zone Failback as per normal.
  2. In DR Assistant Wizard, after we selected the source cluster (Cluster B (for this example: name cluster21)) the next wizard screen will only display the Failover options From Cluster B (cluster21)  to Cluster A (cluster20).  

  1. Select the Access Zone to be failed back and the next screen will not highlight any warning about other SyncIQ policies that will not failed back.

  1. Proceed this Access Zone Failback as per normal. Refer to Eyeglass Access Zone Failover Guide for details.
  2. Repeat the same procedure for failback other Access Zones from B to A.

Failover from A to C Procedure:

  1. Prior to initiate Eyeglass Access Zone Failover from A to C,  we need to ensure that there is no existing SyncIQ Mirror Policies from B to A. The recovery resync prep step of this Failover A to C will create Mirror Policies from C to A with same Mirror Target Paths as the B to A (Mirror Target Paths are overlaps). This will make the Mirror Policies from C to A unrunnable and the Eyeglass Failover Job will fail. If there are existing ones, we need to delete them first. Refer to step P1 in the Failover workflow diagrams.
    1. NOTE: The above step MUST be completed before A to C failover, the order matters since the domain mark will be deleted on cluster A once the step above is completed.
  2. Now run a domain mark job on each SyncIQ policy on cluster A. This is a required step since no domain mark exists and will be created during failover process from A to B. The best practise is to run domain mark before failover to ensure the resync prep step does not take a long time to complete. Domain mark can run longer if a the path has a large number of files. NOTE: During the time while domain mark job is running no failover from A to C should be executed until the domain mark job completes on ALL sync polices involved in the failover.  Monitor progress from the PowerScale Cluster jobs UI.
  3. Then we can perform Eyeglass Access Zone Failover as per normal. In DR Assistant Wizard, after we selected the source cluster (Cluster A (for this example: name cluster20)) the next wizard screen display the list of available Failover options based on Source-Target-Zone pairs.

  1. We need to be careful to select the correct Target Cluster that we want to Failover (A to B or A to C).  For this case we want to failover from A to C. Select a zone that we want to Failover from cluster20 (source) - cluster31 (target)  pairs.
  2. The next screen will gives warning to highlight that this wizard will only perform Access Zone failover from A to C. The other policy on the same Access Zone (A to B) will not be failed over.

  1. Proceed this Access Zone Failover as per normal. Refer to Eyeglass Access Zone Failover Guide for details.
  2. Repeat the same procedure for failover other Access Zones from A to C.

Failback from C to A Procedure

  1. We can perform Eyeglass Access Zone Failback as per normal.
  2. In DR Assistant Wizard, after we selected the source cluster (Cluster C (for this example: name cluster31)) the next wizard screen will only display the Failover options From Cluster C (cluster31)  to Cluster A (cluster20).  

  1. Select the Access Zone to be failed back and the next screen will not highlight any warning about other SyncIQ policies that will not failed back.

  1. Proceed this Access Zone Failback as per normal. Refer to Eyeglass Access Zone Failover Guide for details.
  2. Repeat the same procedure for failback other Access Zones from C to A.
© Superna LLC