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
- Onefs 8 has CA compatibility mode capability advertised called persistent file handles, This is required for Continuous Availability Mode support with Isilon. 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 Isilon 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.
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
|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
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.|
Copyright Superna LLC