DFS Failover Configuration Prerequisites
Introduction
This article covers all of the requirements for performing a DFS (Distributed File System) Failover with Superna DR. It's important to review this guide before attempting to execute a DFS Failover.
Requirements
Cluster Version Requirements
Clusters participating in a Microsoft DFS Type Failover must be running the supported PowerScale OneFS Cluster version for this feature. See Platform Support for the appliance version you are running.
SyncIQ Policy Requirements - Blocks Failover
For a successful Microsoft DFS Type failover, the Configuration Replication Job linked to the associated SyncIQ Policy must be enabled.
The failover will be blocked if either the SyncIQ Policy is disabled in PowerScale OneFS or the associated Configuration Replication Job is disabled.
Failover Target Cluster Requirements - Blocks Failover
For a successful Microsoft DFS Type failover with Superna DR Edition, ensure that the Eyeglass appliance has IP network access to the target PowerScale OneFS Cluster, with all necessary ports open.
Eyeglass Quota Job Requirements
For a Microsoft DFS Type failover with Superna DR Edition, there are no Quota Job state requirements. Quotas will be failed over whether Quota Job is in Enabled or Disabled state.
Active Directory
- AD clients must have both paths of the folder target cached after the failover
- AD clients must be able to contact a Domain Controller
- UNC paths to mount the DFS folder must use the DFS UNC syntax:
\domain_name\dfsrootname\dfs_folder_name - SmartConnect zone names in the UNC targets must be delegated and resolvable by clients
- SmartConnect zone name SPNs for folder target UNC paths must be correctly registered in Active Directory (AD)
Windows OS Compatibility
The following list of Windows OS clients has all been tested for compatibility:
| Windows Client OS | Server OS | Samba Version |
|---|---|---|
| Windows 7, 8.x, 10 | Windows Server 2008, 2012, 2012 R2, 2016 | Samba version 4.8.3 (configured for Microsoft DFS mounts and dual referral paths) |
Automated SMB Client Switch Testing Matrix
Access Zone and IP Pool SMB Client Testing Matrix
| Operating System Version | SMB Protocol | OneFS Version |
|---|---|---|
| Windows 7 Enterprise | SMB2, DFS mounted with only 1 referral path | 8.1.x.x |
| Windows 10 Enterprise | SMB 2, SMB 3, DFS mounted with only 1 referral path | 8.0.0.x, 8.1.x.x |
| Windows Server 2016 Essentials | SMB 2, SMB 3 | 8.0.0.x, 8.1.x.x |
| Windows Server 2012 R2 | SMB 2, SMB 3 | 8.0.0.x, 8.1.x.x |
| CentOS Linux release 7.6.1810 (Core), Samba version 4.8.3 configured for Microsoft DFS mounts and dual referral paths | SMB2, basic support for SMB3 is included in Samba 4.0.0 and later | 8.0.0.x, 8.1.x.x |
Access Zone Mixed DFS and Non-DFS Client Testing Matrix
| Operating System Version | SMB Protocol | OneFS Version |
|---|---|---|
| Windows 10 Pro or Enterprise | SMB3 | 8.1.x.x |
If an operating system or protocol combination is not listed, it has not been tested. Test specific combinations not listed in the tables above. Support cannot test customer configurations.
Release Note
PowerScale OneFS 8 includes a CA (Continuous Availability) compatibility mode feature known as persistent file handles, which is required for Continuous Availability Mode support with PowerScale OneFS. Windows servers in cluster mode will only advertise this capability when using CA mode.
An issue arises in PowerScale OneFS 8 where this capability is still advertised to clients even when not using CA mode. This can trigger the issue described in the KB article linked below:
"The computer can take more time to determine whether a shared folder is available if there is a failover of the shared folder."
This issue only affects client machines with no active connection to PowerScale OneFS shares mounted over DFS. A delay (up to one minute) was observed when mounting the DFS root. However, actively mounted shares or those mapped directly to DFS folders did not experience this delay.
Resolution:
- Windows 10 and Windows Server 2012 have a registry setting described in the Microsoft KB article about shared folder access delays to correct this behavior.
- Windows 8 and Windows Server 2012 require a hotfix to be applied.
DFS Feature Changes and Share names used on DFS synced Shares
To streamline DFS type with normal configuration sync, the feature has been enhanced as shown in the table below. This change introduces new options for customers requiring access to DR cluster data in a read-only state, while preserving DFS-type functionality. It also reduces the risk of issues during failover.
A new feature to hide shares on the DR cluster or read-only cluster is now available. After switching the tag, the next configuration sync cycle will apply the changes to the DR cluster share names.
| Eyeglass Version | DFS Type Sync Behavior | DFS Type Failover Behavior | Prefix on Shares | Post-fix on Shares for Security (DR Cluster) |
|---|---|---|---|---|
| 1.4.x and earlier | Delete shares of the same name on the DR cluster | Create shares on the DR cluster and delete on the source cluster | N/A | N/A |
| 1.5 and beyond | Create shares on the DR cluster with a renamed prefix added to the share name | Rename share on the DR cluster and rename source cluster with a prefix added to the share name | Default Prefix: igls-dfs You can change this by editing the tag in /opt/superna/sca/data/system.xml: <dfsshareprefix>igls-dfs-</dfsshareprefix> WARNING: Changing this tag will NOT automatically clean up shares with the old prefix. You must manually delete old shares, and new shares will be created with the updated tag. | N/A |
| 1.6 and beyond | Same as 1.5 | Same as 1.5 | N/A | New Feature: The source active cluster share can remain visible. A post-fix $ can be applied to hide the share on the DR cluster after failover. To enable, edit the /opt/superna/sca/data/system.xml file and change the tag <dfssharesuffix> to $. Note: Manual deletion of old DFS renamed shares is required. |
When 1.5 DFS type is enabled, all shares found on the source will be created on the target cluster with the prefix applied to the share name. If upgrading from 1.4.x DFS type, no action is required and shares will be created using 1.5 logic.
DFS Fast Failover Mode - Superna Eyeglass 1.5.2 and beyond
| Release | Speed Improvement |
|---|---|
| 1.5.2 > | For DFS Failover (Microsoft DFS Type or DFS enabled job in an Access Zone Failover), the Renaming shares step occurs after Data sync and before the Policy Failover step (Allow Writes, Resync Prep). This ensures that the amount of time that DFS clients are directed to the failover source cluster is minimized once the failover has started and that the DFS clients are already directed to the target cluster when the filesystem becomes writeable. |
| 1.6.0 > | Parallelized Rename - Now the rename process can use up to 10 threads at once to rename 10 shares in parallel across all policies in a failover job. This will provide a 10x speed improvement to redirect DFS clients faster under all failover conditions. Large share or policy count failovers will be accelerated by a factor of 10. |
During failover, clients with open files will now receive a read-only error message if they attempt to save data once redirection has occurred but before the target is writeable. This is expected and provides user feedback that writes will not be successful. Each application may return a read-only error differently.
DFS Failover Enhancements
| Release | Enhancement |
|---|---|
| 1.9 > | For DFS Failover (Microsoft DFS Type or DFS enabled job in an Access Zone Failover), the following Share Rename Step Enhancement has been made:
|
This enhancement eliminates the possibility of data access outage from the share rename step. It ensures that if some shares are renamed successfully, the failover will continue.
Failover Rules When Errors Occur During Failover
- If some of the share renames for a SyncIQ policy succeed (and some fail), the failover steps continue and the Client Redirection phase is marked as a Warning in the failover log.
- If all of the share renames for a SyncIQ policy fail, the failover is aborted in a FAILED state and the cluster is not failed over.
- In releases earlier than 2.5.6, share renaming is not rolled back and must be corrected manually.
- In releases later than 2.5.6, the shares are automatically rolled back to their original state on the source cluster. This ensures users can access data again without any manual steps. The rollback is logged in the failover log.
- A share rename failure is declared when Eyeglass fails to rename all shares on the source cluster, or fails to rename all shares on the target cluster.
- For a multi-policy DFS failover (multiple policies selected to fail over at the same time), if all share renames fail for one of the policies, the failover is aborted for that policy and continues for the other policies. The cluster is not failed over for the policy where all share renaming failed, and the same rollback behavior described above applies.
DFS Mode Preparation Checklist
DFS mode requires the following prerequisites:
- Windows 2008 or 2012 Domain Controller.
- DNS role installed.
- DFS file services role.
- Two PowerScale clusters with SyncIQ.
- Eyeglass appliance.
- DFS-enabled clients: Windows 7, 8, 10, and Server 2008, 2012, 2016.
DFS Mode Compatibility
- DFS mode is not compatible with the Runbook Robot feature, since NFS is used for data access.
- DFS mode is compatible with Hot/Hot and Hot/Cold configurations.
- DFS mode is compatible with Access Zone and Access Zone and IP pool failover mode, but requires a dedicated subnet:pool with the Eyeglass
igls-ignorehint applied to retain SmartConnect zones on the source and target clusters. DFS mode does not require SmartConnect zone names to fail over.
DFS Type Mode Compared with Default Configuration Sync Mode
- The default Eyeglass job mode is Configuration Sync job mode, which places configuration data on both the source and target cluster and treats the configuration data the same as SyncIQ, meaning it is maintained in full sync on both clusters.
- Eyeglass SyncIQ DFS mode can be enabled. It renames share objects from the target cluster referenced in the policy and fails over shares. Quotas are also failed over during share failover.
Unsupported Data Replication Topology
Replication topologies where shares or NFS aliases have the same name on both clusters but are protected by different SyncIQ policies are not supported for any failover type, including Microsoft DFS Type. This configuration leads to the following issues:
- Path Overwriting: Configuration replication will overwrite the share/alias path on one cluster because the share or alias cannot be distinguished across clusters.
- Failover Failure: During failover, the system will attempt to apply two SyncIQ policies on the same cluster with identical source paths, resulting in failure.
- Invalid Disaster Recovery (DR) Configuration: This setup leads to duplicate shares pointing to different data, which is an invalid DR configuration.
info
This configuration will cause failover to be unsuccessful, with or without Superna Eyeglass.
Recommendations for Configuration
The following are highly recommended to ensure that all automated Eyeglass Microsoft DFS Type failover steps can be completed.
SyncIQ Policy Recommendations
- The SyncIQ Job in PowerScale OneFS should be completed without errors and display a green status.
Failover will be blocked if SyncIQ policies are in an error state on the cluster. Eyeglass will attempt to run the policy, which will fail. Correct this on the PowerScale OneFS cluster. Data loss may occur due to unreplicated data.
- PowerScale OneFS does not support SyncIQ Policies with exclude (or include) settings for failover.
This configuration is not supported for failback.
- PowerScale OneFS best practices recommend that SyncIQ Policies use the Restrict Source Nodes option, which requires an IP created with the target SmartConnect zone.
The subnet pool used for data replication is not controlled, meaning that all nodes in the cluster can replicate data from all IP pools. This complicates bandwidth management and requires all nodes to have WAN access.
Next Steps
From this point you may go to the DFS Failover Configuration Procedures article, to begin the Configuration.