DR Design Guides

Planning and Procedures for Eyeglass SyncIQ DFS Mode Failover

Home


DFS Mode Preparation Checklist

DFS mode requires the following prerequisites:

  1. Windows 2008 or 2012 Domain Controller.
  2. DNS role installed.
  3. DFS files services role.
  4. 2 x PowerScale clusters with SyncIQ.
  5. Eyeglass appliance.
  6. DFS enabled clients Windows 7, 8, 10, Server 2008, 2012, 2016.

DFS Mode Compatibility

  1. Not compatible with RunBook Robot feature, since NFS is used for data access.
  2. Hot\Hot and Hot\Cold compatible.
  3. Compatible with Access Zones and Access Zone and IP pool Failover mode but requires dedicated subnet:pool with Eyeglass igls-ignore hint applied to retain SmartConnect zones on source and target clusters.  DFS mode does not require SmartConnect Zone names to failover.

Considerations for Eyeglass SyncIQ DFS mode vs Default Configuration Sync job mode in Eyeglass

  1. Default Eyeglass Job mode is Configuration Sync job mode which places configuration data on both source and target cluster treating the configuration data the same as SyncIQ, meaning it's maintained in full sync on both clusters.
  2. Eyeglass SyncIQ DFS mode can be enabled and will rename share objects from the target cluster referenced in the policy, and fails over shares.  Quotas are also failed over during share failover.

Procedure to Enable Eyeglass SyncIQ DFS mode

  1. Select policy with shares to be protected and then Select a bulk action option Enable/Disable Microsoft DFS.

  1. Run the DFS Enabled job.
  2. Verify its green before configuring DFS in Active Directory.


Failover Rules for DFS when errors occur during failover

This section covers scenario's when failures occur and how Eyeglass will behave.

  1. It is expected that if SOME of the share renames for a SyncIQ policy succeed (meaning SOME failed as well), failover steps will continue.
    1. Client Redirection phase marked as Warning in the failover log .
  2. It is expected that if ALL of the share renames for a SyncIQ policy fail, the failover is aborted in FAILED state
    1. Note: in this case
      1. cluster is not failed over
      2. < 2.5.6 release the share renaming is not rolled back - must be done manually by customer
      3. In > 2.5.6 release the shares will automatically be rolled back to the original state on the source cluster. This ensures users can access data again without any manual steps.   This step will be logged in the failover log. 
  3. How is share rename step declared a failure status:
    1. A share rename failure is considered to be:
      1. Failure to rename ALL shares on the SOURCE cluster
      2. OR
      3. Failure to rename ALL shares on the TARGET cluster.
  4. For a multi-policy DFS failover (selecting multiple policies to failover at the same time), if a share rename failure occurs for any 1 of the policies then failover is aborted for that policy and continues for other policies.
    1. Note: in this case:
      1. cluster is not failed over for the policy where all share renaming failed.
      2. < 2.5.6 release the share renaming is not rolled back - must be done manually by customer.
      3. In > 2.5.6 release the shares will automatically be rolled back to the original state on the source cluster. This ensures users can access data again without any manual steps.   This step will be logged in the failover log. 

Detailed DFS Mode Configuration, Operating procedures and Design guidelines

See Microsoft DFS Mode Failover Guide

© Superna Inc