Home Top

3 Site DFS Mode Failover

• Overview
• Video How to - Overview Multi site DFS mode Failover
• Configuration
• DFS Mode Initial Configuration / Before Failover Diagram
• DFS Mode Failover A ⇒ B Diagram
• DFS Mode Failback B ⇒ A Diagram
• DFS Mode Failover A ⇒ C Diagram
• DFS Mode Failback C ⇒ A Diagram
• Eyeglass DFS Mode Failover Steps
• Eyeglass DFS Mode Failback Steps
• DFS Configuration
• DFS Readiness
• DFS Readiness - Initial Configuration / Before Failover
• DFS Readiness - Before Failback B ⇒ A
• DFS Readiness - Before Failback C ⇒ A
• Share Names and DFS Paths
• DFS Mode Failover and Failback Procedures
• DFS Mode Failover from A to B Procedure:
• DFS Mode Failback from B to A Procedure:
• DFS Mode Failover from A to C Procedure:
• DFS Mode Failback from C to A Procedure:

This section will explain the configuration, failover and failback workflows for 3 Sites DFS Mode Failover with Eyeglass for PowerScale.  As explained in the previous sections of this document, there are 3 Sites for this setup: Site A (Source), Site B (Target #1) and Site C (Target #2).

Overview

This solution offers simply 2 site target with clients automatically redirected to the correct site.  

• No DNS change
• No SPN changes
• Quotas follow shares as required to each site on failover and failback
• 3 DFS targets per folder
• Highest availability option for data with zero touch failover between sites

Video How to - Overview Multi site DFS mode Failover

Configuration

For this 3 Sites DFS Mode Failover, we need to configure the DFS Target Folder to have 3 referrals to 3 PowerScale Clusters. Data on the SMB folders referred as the DFS Target Folder is replicated from Site A to Site B, and also from Site A to Site C by using PowerScale SyncIQ replication.

DFS Mode Initial Configuration / Before Failover Diagram

This diagram displays the initial configuration for this 3 Sites DFS Mode Failover.

DFS Mode Failover A ⇒ B Diagram

This diagram shows the Failover workflow from A to B. Take note step P1 (Preparation Step - prior to initiate Eyeglass DFS Mode Failover) - refer to the procedure section for details.

Refer to this table for the list of the numbered steps shown in this diagram.

DFS Mode Failback B ⇒ A Diagram

This diagram shows the Failback workflow from B to A.

Refer to this table for the list of the numbered steps shown in this diagram.

DFS Mode Failover A ⇒ C Diagram

This diagram shows the Failover workflow from A to C. Take note step P1 (Preparation Step - prior to initiate Eyeglass DFS Mode Failover) - refer to the procedure section for details.

Refer to this table for the list of the numbered steps shown in this diagram.

DFS Mode Failback C ⇒ A Diagram

This diagram shows the Failback workflow from C to A.

Refer to this table for the list of the numbered steps shown in this diagram.

Eyeglass DFS Mode Failover Steps  

This table lists the Eyeglass DFS Mode Failover steps with numbers as shown in the above Failover diagrams.

No	Steps
P1	Preparation Step. Failover A ⇒ B: Ensure there is no existing Mirror Policies between C to A. If there is existing Mirror Policies between C to A, delete first, before initiate Failover from A to B. Failover A ⇒ C: Ensure there is no existing Mirror Policies between B to A. If there is existing Mirror Policies between B to A, delete first, before initiate Failover from A to C.
1	Ensure that there is no live access to data
2	Begin Failover
3	Validation
4	Synchronize data
5	Synchronize configuration (shares/export/alias)
6	Renaming Shares
7	Record schedule for SyncIQ policies being failed over
8	Prevent SyncIQ policies being failed over from running
9	Provide write access to data on target
10	Disable SyncIQ on source and make active on target
11	Set proper SyncIQ schedule on target
12	Synchronize quota(s)
13	Remove quotas on directories that are target of SyncIQ (PowerScale best practice)
14	Refresh SMB session to pick up DFS change: SMB Client is accessing a domain-based namespace (e.g. \\ad1.test\dfs01\z02-smb01) . This SMB client computer sends a query to the AD  to discover a list of root targets for the namespace. AD Controller returns a list of root targets defined for the requested namespace. SMB client selects the root target from the referral list  and sends a query to the root server for the requested link. DFS root server constructs a list of folder targets in the referral. Failover A ⇒ B: The SMB Share(s) on Cluster-A is not active (Renamed with igls-dfs- prefix), The SMB Share(s) on Cluster-C is not active. (Deleted). The active path is to the Cluster-B (Renamed to the actual name). DFS root server sends this referral information to the client. Failover A ⇒ C: The SMB Share(s) on Cluster-A is not active (Renamed with igls-dfs- prefix), The SMB Share(s) on Cluster-B is not active. (Deleted). The active path is to the Cluster-C (Renamed to the actual name). DFS root server sends this referral information to the client. SMB client tries to establish a connection to the selected target (the active target  in the list). PowerScale with Active Target responses to this SMB connection.

Eyeglass DFS Mode Failback Steps 

This table lists the Eyeglass DFS Mode Failback steps with numbers as shown in the above Failback diagrams.

No	Steps
1	Ensure that there is no live access to data
2	Begin Failback
3	Validation
4	Synchronize data
5	Synchronize configuration (shares/export/alias)
6	Renaming Shares
7	Record schedule for SyncIQ policies being failed back
8	Prevent SyncIQ policies being failed back from running
9	Provide write access to data on target
10	Disable SyncIQ on source and make active on target
11	Set proper SyncIQ schedule on target
12	Synchronize quota(s)
13	Remove quotas on directories that are target of SyncIQ (PowerScale best practice)
14	Refresh SMB session to pick up DFS change:   SMB Client is accessing a domain-based namespace (e.g. \\ad1.test\dfs01\z02-smb01) . This SMB client computer sends a query to the AD  to discover a list of root targets for the namespace. AD Controller returns a list of root targets defined for the requested namespace. SMB client selects the root target from the referral list  and sends a query to the root server for the requested link. DFS root server constructs a list of folder targets in the referral. Failback B ⇒ A: The SMB Share(s) on Cluster-B is not active (Renamed with the igls-dfs- prefix), The SMB Share(s) on Cluster-C is not active. (Renamed with the igls-dfs- prefix). The active path is to the Cluster-A (Renamed to the actual name). DFS root server sends this referral information to the client. Failback C ⇒ A: The SMB Share(s) on Cluster-C is not active (Renamed with the igls-dfs- prefix), The SMB Share(s) on Cluster-B is not active. (Renamed with the igls-dfs- prefix). The active path is to the Cluster-A (Renamed to the actual name). DFS root server sends this referral information to the client. SMB client tries to establish a connection to the selected target (the active target  in the list). PowerScale with Active Target responses to this SMB connection.

DFS Configuration

Configure the DFS Target Folder to have 3 referrals - Site A, Site B and Site C.

For an example we have configured the DFS Target Folder to have these three referrals:

1. Source (Site A): \\cluster07-z02.ad1.test\z02-smb01
2. Target#1 (Site B):  \\cluster08-z02.ad1.test\z02-smb01
3. Target#2 (Site C): \\cluster06-z02.ad1.test\z02-smb01

We have also configured the following target priority referral ordering:

Source Cluster (Site A)

Target Cluster #1 (Site B)

Target Cluster #2 (Site C)

DFS Readiness

This section  explains the different states of DFS Readiness for this 3 Sites DFS Mode Failover / Failback.

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

Site	Cluster Name
A (Primary / Source)	cluster07
B (Secondary#1 / Target #1)	cluster08
C (Secondary#2 / Target #2)	cluster06

DFS Readiness - Initial Configuration / Before Failover

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

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

DFS Readiness - Before Failback B ⇒ A

This DFS Readiness is for the state before Failback from B to A.

Warning: As shown in this DR Readiness Dashboard that both AB Mirror Policy  and AC  Policy have DR Status OK. During Failback from B to A, we need to carefully select Cluster B as the source. Do not select the Cluster A as the source, as this will direct the process as Failover from A to C.

DFS Readiness - Before Failback C ⇒ A

This DFS Readiness is for the state before Failback from C to A.

Warning: As shown in this DR Readiness Dashboard that both AC Mirror Policy  and AB  Policy have DR Status OK. During Failback from C to A, we need to carefully select Cluster C as the source. Do not select the Cluster A as the source, as this will direct the process as Failover from A to B.

Share Names and DFS Paths

Based on the above example, the following table describes the SMB Share Names and DFS Paths for various states:

Initial Configuration / Before Failover

	Cluster07 (A)	Cluster08 (B)	Cluster06 (C)
Share Name	z02-smb01	igls-dfs-z02-smb01	igls-dfs-z02-smb01
DFS Path Resolves to	\\cluster07-z02.ad1.test\z02-smb01
Access Status	0 ( ACTIVE TARGETSET )	0xc00000cc ( TARGETSET )	0xc00000cc

After Failover / After Failback

		Cluster07 (A)	Cluster08 (B)	Cluster06 (C)
After Failover A => B	Share Name	igls-dfs-z02-smb01	z02-smb01	*1
	DFS Path Resolves to		\\cluster08-z02.ad1.test\z02-smb01
	Access Status	0xc00000cc ( TARGETSET)	0 ( ACTIVE TARGETSET )	0xc00000cc
After Failback B => A	Share Name	z02-smb01	igls-dfs-z02-smb01	igls-dfs-z02-smb01*2
	DFS Path Resolves to	\\cluster07-z02.ad1.test\z02-smb01
	Access Status	0 ( ACTIVE TARGETSET )	0xc00000cc ( TARGETSET )	0xc00000cc
After Failover A => C	Share Name	igls-dfs-z02-smb01	*3	z02-smb01
	DFS Path Resolves to			\\cluster06-z02.ad1.test\z02-smb01
	Access Status	0xc00000cc ( TARGETSET )	0xc00000cc ( TARGETSET )	0 (ACTIVE)
After Failback C => A	Share Name	z02-smb01	igls-dfs-z02-smb01*4	igls-dfs-z02-smb01
	DFS Path Resolves to	\\cluster07-z02.ad1.test\z02-smb01
	Access Status	0 ( ACTIVE TARGETSET )	0xc00000cc ( TARGETSET )	0xc00000cc

Remarks for Intermediate and Final States:

*1: States:

1. After Failover A ⇒ B process has just Completed: igls-dfs-z02-smb01 (Intermediate State)
2. The 1st cycle of Configuration Replication (A ⇒ C) after failover A ⇒ B: igls-dfs-igls-dfs-z02-smb01 (Intermediate State)
3. The 2nd cycle of Configuration Replication (A ⇒ C) after failover A ⇒ B: <empty> SMB shares deleted. (Final state)

*2: States:

1. After Failback B ⇒ A just Completed: <empty> SMB shares is  not created (Intermediate State)
2. The 1st cycle of Configuration Replication (A ⇒ C) after failback B ⇒ A: igls-dfs-z02-smb01 (Final State)

*3: States:

1. After Failover A ⇒ C just Completed: igls-dfs-z02-smb01 (Intermediate State)
2. The 1st cycle of Configuration Replication (A ⇒ B) after failover A ⇒ C: igls-dfs-igls-dfs-z02-smb01 (Intermediate State)
3. The 2nd cycle of Configuration Replication (A ⇒ B) after failover A ⇒ C: <empty> SMB shares deleted. (Final state)

*4: States:

1. After Failback C ⇒ A just Completed: <empty> SMB shares is  not created (Intermediate State)
2. The 1st cycle of Configuration Replication (A ⇒ B) after failback C ⇒ A: igls-dfs-z02-smb01 (Final State).

Based on that table we can see that after failover, it takes 2 cycles of Configuration Replication as waiting time for the SMB share name on the 3rd cluster to have its final state.

For the case of failback, it takes 1 cycle of Configuration Replication process as waiting  time for the SMB share name on the 3rd cluster to have its final state.

DFS Mode 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:

SyncIQ Policy Name	SyncIQ Pairs
AB-synciq-01	A and B
AC-synciq-01	A and C

This name format will help us to identify which SyncIQ Pairs that we want to failover.

DFS Mode Failover from A to B Procedure:

1. Prior to initiate Eyeglass DFS Mode 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 DFS Mode Failover as per normal. In DR Assistant Wizard, after we select the source cluster (Cluster A (for this example: cluster07)) the next wizard screen display the list of available Failover options based on Source-Target pairs (A to B or A to C).

3. 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 the AB Source-Target Pair.
4. The next screen will gives validation whether the failover configuration is valid.

5. Proceed this DFS Mode Failover as per normal. Refer to Eyeglass DFS Mode Failover Guide for details.

DFS Mode Failback from B to A Procedure:

1. We can perform Eyeglass DFS Mode Failback as per normal.
2. In DR Assistant Wizard, ensure we select the correct source cluster B (name: cluster08). At this stage (After Failover A to B and before Failback from B to A), there are 2 available options to perform as also displayed in the DR Dashboard DFS Readiness. Do not select cluster A (name : cluster07) as the source, as this will lead to Failover from A to C instead.
   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.
3. 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.
4. After we select the correct source cluster (Cluster B (for this example: cluster08)) the next wizard screen will only display the Failback option From Cluster B (cluster08)  to Cluster A (cluster07).  

4. Select the AB mirror policy to failback. The next screen will gives validation whether the failover configuration is valid.

5. Proceed this DFS Mode Failback as per normal. Refer to Eyeglass DFS Mode Failover Guide for details.

DFS Mode Failover from A to C Procedure:

1. Prior to initiate Eyeglass DFS Mode 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 DFS Mode Failover as per normal. In DR Assistant Wizard, after we select the source cluster (Cluster A (for this example: cluster07)) the next wizard screen display the list of available Failover options based on Source-Target pairs (A to B or A to C).

3. 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 the AC Source-Target Pair.
4. The next screen will gives validation whether the failover configuration is valid.

5. Proceed this DFS Mode Failover as per normal. Refer to Eyeglass DFS Mode Failover Guide for details.

DFS Mode Failback from C to A Procedure:

1. We can perform Eyeglass DFS Mode Failback as per normal.
2. In DR Assistant Wizard, ensure we select the correct source cluster C (name: cluster06). At this stage (After Failover A to C and before Failback from C to A), there are 2 available options to perform as also displayed in the DR Dashboard DFS Readiness. Do not select cluster A (name : cluster07) as the source, as this will lead to Failover from A to B instead.
   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.
3. 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.
4. After we select the correct source cluster (Cluster C (for this example: cluster06)) the next wizard screen will only display the Failback option From Cluster C (cluster06)  to Cluster A (cluster07).  

4. Select the AC mirror policy to failback. The next screen will gives validation whether the failover configuration is valid.

5. Proceed this DFS Mode Failback as per normal. Refer to Eyeglass DFS Mode Failover Guide for details.

© Superna Inc