DR Configuration Guides

Windows OS Compatibility

Home

Windows DFS Client OS Compatibility and Release Notes

The following list of Windows OS clients have all been tested.

Windows 7, 8.x, 10
Windows Server 2008, 2012, 2012 R2, 2016
Samba version: Samba version 4.8.3 Configured for Microsoft DFS mounts and dual referral paths

Release Note

Onefs 8 has CA compatibility mode capability advertised called persistent file handles, This is required for Continuous Availability Mode support with PowerScale. Windows servers in cluster mode only advertise this capability when using CA mode.

An issue arise from Onefs 8 when NOT using CA mode this capability is still advertised to clients.
This can trigger the issue described in KB article below “The computer can have more time to determine whether a shared folder is available if there is a failover of the shared folder.”
NOTE: This issue only affected client machines with no active connection to PowerScale shares mounted over DFS. A delay was seen when mounting the DFS root that would complete within one minute. NOTE: Actively mounted shares or mapped to DFS folders directly did not see this delay.

Windows 10 and 2012 server have a registry setting described in the link below to correct this behavior. Windows 8 and 2012 server require a hotfix to be applied.
1. https://support.microsoft.com/en-us/help/2820470/delayed-error-message-when-you-try-to-access-a-shared-folder-that-no-l

DFS Feature Changes and Share names used on DFS synced Shares

To streamline how DFS mode with normal configuration sync, the feature has been enhanced as per the table below. This change allows new options for customers that require access to DR cluster data in read-only state, and preserves DFS mode functionality. It also reduces risk of issues during failover.

New feature to hide shares on the DR cluster or read only cluster are now available. After switching the tag, the next configuration sync cycle will apply the changes to the DR cluster share names.

Eyeglass Version	DFS Mode Sync Mode	DFS mode failover Behavior	Prefix on Shares	Post fix on shares for Security on DR Cluster
1.4.x and earlier	Delete shares of the same name on DR cluster	Create shares on DR cluster and delete on source cluster
1.5 and beyond	Create shares on DR cluster with a renamed prefix added to the share name	Rename share on DR cluster and rename source cluster with a prefix added to the share name	igls-dfs (this default can be changed and be changed to another string by editing the tag <dfsshareprefix>igls-dfs-</dfsshareprefix> in /opt/superna/sca/data/system.xml ) WARNING: If DFS is enabled, changing this tag will NOT clean up shares with the previous name. Clean up is manual and new shares will be created with the new tag.
1.6 and beyond				New feature to allow the source active cluster share to be visible BUT a $ post fix can be applied on the Synced igl-dfs-sharename$ to hide the share on the DR cluster. After failover the share names will flip and hide it on the Source cluster. This can be enabled by editing /opt/superna/sca/data/system.xml file. Change the tag to include $ as shown below <dfssharesuffix>$</dfssharesuffix> NOTE: on an existing installation the old DFS renamed share will need to be manually deleted

NOTE: When 1.5 DFS mode is enabled, all shares found on source will be created on the target cluster with the prefix applied to the share name. If upgrading from 1.4.x DFS mode, 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	Notes
1.5.2 >	For DFS Failover (Microsoft DFS Mode 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.	NOTE: 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 gives the user feedback that writes will not be successful. Each application has different behaviour in how it returns a read-only file system error to the user.
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. With large share or policy count failovers getting accelerated by a factor of 10

DFS Failover Enhancements

Release

Enhancement

Notes

1.9 >

For DFS Failover (Microsoft DFS Mode or DFS enabled Job in an Access Zone Failover), following Share Rename Step Enhancement has been made:

If share renaming is failed for all the shares for a cluster, then failover status is error and failover is stopped. This aborts the failover and leaves the data accessible on the source cluster.
If share renaming is failed only for some shares for a cluster, then failover status is warning and manual recovery on the shares that failed to rename is required.

Summary: This eliminates the possibility of data access outage from share rename step and ensures if some shares rename the failover will continue.