SyncIQ Policy Failover Guide

Eyeglass SyncIQ

Policy Failover Guide

Product Name - Superna Eyeglass

Revised 6/1/2017

 

Contents

  1. 1 Introduction to this Guide
    1. 1.1 Overview
    2. 1.2 Help
    3. 1.3 Prerequisites, Requirements or limits
  2. 2 SyncIQ Policy Failover Procedure with DR Assistant
    1. 2.1 Failover Steps
    2. 2.2 Failback
  3. 3 Requirements for Eyeglass Assisted SyncIQ Policy Failover
    1. 3.1 Cluster Version Requirements
    2. 3.2 SyncIQ Policy Requirements
    3. 3.3 Failover Target Cluster Requirements
    4. 3.4 Eyeglass Quota Job Requirements
    5. 3.5 Service Principal Name Update Requirements
  4. 4 Unsupported Data Replication Topology
  5. 5 Recommendations for Eyeglass Assisted SyncIQ Policy Failover
    1. 5.1 Shares / Exports / NFS Alias Recommendations
    2. 5.2 SyncIQ Policy Recommendations
    3. 5.3 Smartconnect Recommendations
  6. 6 Preparing your System for the Eyeglass Assisted SyncIQ Policy Failover
    1. 6.1 Update Isilon sudoer file for Eyeglass Service Account with Isilon Cluster version 7.1.1.0 or 7.1.1.1
    2. 6.2 Post Failover Automation
    3. 6.3 Failover Planning and Checklist
  7. 7 Runbook Robot (Automate DR Testing on a schedule)
    1. 7.1 Overview
    2. 7.2 Run Book Robot Failover Coverage with Basic Setup
  8. 8 Operational Steps for Eyeglass Assisted SyncIQ Policy Failover
    1. 8.1 Eyeglass DR Assisted Failover SyncIQ policy Workflow Overview:
  9. 9 Monitoring DR Readiness for Eyeglass Assisted Failover
    1. 9.1 Policy DR Readiness Validation
  10. 10 Post SyncIQ Policy Failover Manual Steps
    1. 10.1 Update Networking for Client Access
    2. 10.2 Update SPNs
    3. 10.3 Refreshing SMB connection after Failover completed and DNS updated
    4. 10.4 Refreshing NFS connection after Failover completed and DNS updated
    5. 10.5 Post SyncIQ Policy Failover Checklist
    6. 10.6 File System Updates
    7. 10.7 SyncIQ Policy Updates
    8. 10.8 Quota Updates
  11. 11 APPENDIX 1 - Controlled Failover Option Results Summary

Introduction to this Guide

The purpose of this guide is to assist you with Eyeglass Assisted SyncIQ Policy Failover.  

Overview

Eyeglass Assisted SyncIQ Policy Failover provides users with the tools and information to determine the DR readiness of their configuration. The Eyeglass DR Dashboard Policy Readiness tab provides a per SyncIQ Policy summary of all SyncIQ, OneFS and Eyeglass Configuration replication Job statuses.  The status for each are combined to provide an overall DR Status.

This information provides the best indicator of DR readiness for failover and allows administrators to check status on each component of failover, identify status, errors and correct them to get each SyncIQ Policy configured and ready for failover.

The following document is a guide to help you with the requirements, considerations, system preparation, operational steps, and monitoring for Eyeglass assisted SyncIQ Policy failover.

Help

This document is designed as a guide for Eyeglass Assisted SyncIQ Policy Failover, should you have any issues that are not addressed in this guide, Superna offers support in several forms; on line, voicemail, Email, or live online chat.

  1. The support site provides online ticket submission and case tracking.  Support Site link - support.superna.net 

  2. Leave a voicemail at 1 (855) 336-1580

In order to provide service you must have an account in our system. When calling in leave; customer name, email, description of question or issue, and primary contact for your company. We will  assign the case to primary contact for email followup.

  1. Email eyeglasssupport@superna.net

  2. To download license keys please go to the following  license keys.

  3. You can also raise a case right from in Eyeglass desktop using the help button, search for your issue and if want to raise a case or get a question answered, click the “leave us a message”  with your name, email and appliance ID and a case is opened directly from Eyeglass.

 http://site.superna.net/_/rsrc/1472870726155/support/LeaveUsAMessage.png?height=200&width=167

  1. Or get Support Using Chat M-F 9-5 EDT  (empty box?  we are not online yet)

  2. Eyeglass Live Chat 

  3. You should also review our support agreement here.

Prerequisites, Requirements or limits

 

SyncIQ Policy Failover Procedure with DR Assistant

This is for application failover when host side automation scripts are required.  This is recommended with NFS failover when no SPN or SmartConnect Zone automation is required.

It offers flexibility to design a failover solution customized for an application use case, while using DFS mode or Access Zone failover for standardized failover workflows.

This failover mode can be used with SMB however, manual steps are required for SPN and SmartConnect Zones that are not required with DFS mode or Access Zone modes.

Recommended Use Cases:

  1. NFS failover with post script host automation

  2. Application failover with script engine to assist with application automation steps

  3. Failover without DNS updates using SmartConnect zone names and unmount and remount automation

The diagrams below show the flow and steps of failover.

 

 

Failover Steps

Step 1: Initiate Failover SyncIQ Policy with Eyeglass 

Step 2: Secondary Cluster - Create SmartConnect zone alias name - Manual (automated with Access Zone Failover)

Command:

“isi networks modify pool <subnet>:<zone-name> --add-zone-aliases <zone-alias-name>”

 Example:

“isi network modify pool subnet0:zone01-pool --add-zone-aliases primary.ad1.test”

Step 3: Secondary Cluster - Ignore missing SPN - Manual

Command:

“isi auth ads spn check --domain <domain-name>”

When we run this command on the secondary cluster, we can see missing SPN. As this scenario is using local provider as the authentication provider, we can ignore this missing SPN message.

Step 4: Update Name Resolution – IP Address  Automated by Eyeglass (with script engine)

We can use the Post Failover Eyeglass script to update the name resolution.

Step 5: Re-mount the NFS Mount Automated by Eyeglass (with script engine)

Unmount and remount the NFS mounting folder on the client to refresh the connection to the NFS export (accessed through the secondary cluster).

 Command:

“umount -fl /mnt/z01-nfs01”

and then

For NFSv3: 

“mount -t nfs -o vers=3 primary.ad1.test:/ifs/data/zone01/z01-nfs01 /mnt/z01-nfs01”

For NFSv4:

“mount -t nfs -o vers=4 primary.ad1.test:/ifs/data/zone01/z01-nfs01 /mnt/z01-nfs01” 

Might need to unmount the export with force / force and lazy options  to solve the NFS stale issue

Also for NFSv4, we might need to kill the process that was accessing the export mount before the failover.

Failback

Step 1: Initiate Failback with SyncIQ policy with Eyeglass

 1.a.  Automated by Eyeglass

 1.b. & 1c. Automated by Eyeglass

On Secondary - replicate data to the primary cluster with the mirror policies

1.d. Automated by Eyeglass

On the primary cluster, allow writes to the target directories of the mirror policies 

1.e. & 1f. Automated by Eyeglass

On the secondary cluster, complete the failback process

Step 2: Secondary Cluster - Delete SmartConnect zone alias name (automated with Access Zone Failover)

Command:

“isi networks modify pool <subnet>:<zone-name> --remove-zone-aliases <zone-alias-name>”

 Example:

“isi network modify pool subnet0:zone01-pool --remove-zone-aliases primary.ad1.test”

 Step 3: Update Name Resolution - IP Address Automated by Eyeglass (with script engine)

We can use the Post Failover Eyeglass script to update the name resolution.

Step 4: Re-mount the NFS Mount Automated by Eyeglass (with script engine)

We can use the Post Failover Eyeglass script to update the name resolution.

Unmount and remount the NFS mounting folder on the client to refresh the connection back to the primary cluster’s NFS export.

Command:

“ umount /mnt/z01-nfs01”

and then:

For NFSv3: 

“mount -t nfs -o vers=3 primary.ad1.test:/ifs/data/zone01/z01-nfs01 /mnt/z01-nfs01”

For NFSv4:

“mount -t nfs -o vers=4 primary.ad1.test:/ifs/data/zone01/z01-nfs01 /mnt/z01-nfs01” 

Requirements for Eyeglass Assisted SyncIQ Policy Failover

Following conditions are required for Eyeglass Assisted SyncIQ Policy Failover.

Cluster Version Requirements

Clusters participating in SyncIQ Policy Failover must be running the supported Isilon Cluster version for this feature.  See the Feature Release Compatibility matrix in the “Eyeglass Release Notes” specific to your Eyeglass version found here.

SyncIQ Policy Requirements

For a SyncIQ Policy failover with Eyeglass, it is required that the Eyeglass Configuration Replication Job for that SyncIQ Policy is in the Enabled state.  

Note: If the SyncIQ Policy is disabled in OneFS or the corresponding Eyeglass Configuration Replication Job is disabled in Eyeglass the SyncIQ Policy failover will be blocked.

Failover Target Cluster Requirements

For a SyncIQ Policy failover with Eyeglass, it is required that the Isilon Cluster that is the target of the failover be IP reachable by Eyeglass with the required ports open.

Eyeglass Quota Job Requirements

For a SyncIQ Policy failover with Eyeglass, there are no Eyeglass Quota Job state requirements.  Quotas will be failed over whether Eyeglass Quota Job is in Enabled or Disabled state.

Service Principal Name Update Requirements

DFS mode and Access Zone failover manage SPN updates automatically.  This is only required when SyncIQ policy failover includes direct mount shares.

Eyeglass will allow SyncIQ policy failover. However, Eyeglass  requires the storage administrator to selectively fix SPN values on the source and destination cluster. This will  ensure that data sets that remain on the source cluster still process SPN authentications via Kerberos using the source cluster machine account.  This is the reason the user will be required to manually make the SPN deletes and additions on the target cluster, as the Isilon cluster  does not know which SPN and SmartConnect Zones are related to the SMB Shares.

SPN deletes from the source, followed by SPN add on the target. This must be done manually by reviewing the Smartconnect Zones required for the failover.

Consult the EMC documentation of ISI commands required to add or delete SPN’s on computer accounts.

Unsupported Data Replication Topology

Replication topology with shares or NFS alias with the same name on both clusters and protected by different SyncIQ policies is not supported.  Configuration Replication will overwrite the path on one cluster, as the share / alias can not be distinguished. The failover will not succeed, as it would attempt to have 2 SyncIQ policies on the same cluster with the same source path. Note:  This is an invalid DR configuration.  This configuration means duplicate shares point to different data. Failover will be unsuccessful  with or without Eyeglass.

Recommendations for Eyeglass Assisted SyncIQ Policy Failover

The are important recommendations to ensure that all automated SyncIQ Policy failover steps can be completed.  In some cases if the condition is not met it will result in an Error.

Notes:

  • Errors will not block Eyeglass Assisted SyncIQ Failover from starting.

  • If the recommendations are not followed it may result in an error during failover causing the failover to not complete

    • Potential data loss will be incurred depending on the step that failed

  • Post failover may require additional manual steps to complete the failover with application hosts

  • Post failover scripting should be used to automate custom failover requirements per policy

Shares / Exports / NFS Alias Recommendations

  • Eyeglass Configuration Replication Jobs for the SyncIQ Policies being failed over should have been completed (so not in Pending state) without error before failover is started

    • Impact:

      • Failover will not complete if configuration sync fails during failover

      • Any missing or unsynced  share / export / NFS alias information will block client access to data on the Target cluster.  These configuration items will have to be corrected manually on the Target Cluster.

SyncIQ Policy Recommendations

  • SyncIQ Job in OneFS should have been completed without error and shows green.

    • Impact:

      • Failover will not complete if errors occur during failover

      • Data loss due to unreplicated data

  • Isilon does not support SyncIQ Policy with excludes (or includes) for failover.

    • Impact: Not a supported configuration for failback

  • Isilon best practices recommend that SyncIQ Policies utilize the Restrict Source Nodes option which requires an IP to be created with target smartconnect zone.

    • Impact: Subnet pool used for data replication is not controlled all nodes in the cluster can replicate data from all IP pools.  This is hard to manage bandwidth and requires all nodes to have access to the WAN.

Smartconnect Recommendations

It is recommended to have a dedicated SmartConnect Zone or SmartConnect Zone Alias for data access per SyncIQ Policy instead of sharing SmartConnect Zone/Alias between policies.  This will allow clients to continue to use same SmartConnect Zone for data access post failover and simplify the associated networking updates.

Preparing your System for the Eyeglass Assisted SyncIQ Policy Failover

The following steps described in this section are required to prepare your system for the Eyeglass Assisted SyncIQ Policy Failover:

Update Isilon sudoer file for Eyeglass Service Account with Isilon Cluster version 7.1.1.0 or 7.1.1.1

Eyeglass SyncIQ Policy Failover requires some CLI commands that must run with root level access.  Many customers also run the cluster in STIG or compliance mode for Smartlock WORM features, and the root user account is not allowed to login and run commands.  Updating the Isilon sudoer file allows the Eyeglass service account user to run the command without having root access.

Please refer to the  “Update Isilon sudoer file for Eyeglass service User (Root Level Commands Needed for Failover)” section in the Eyeglass Isilon Edition Tech Notes here for details.

Post Failover Automation

Many failover scenarios depend on extra steps performed on devices, software, infrastructure external to the NAS cluster.  Using the Eyeglass script engine, these tasks can now be automated with output captured and appended to Eyeglass failover logs.  For example:

  • DNS updates post failover for SmartConnect zone CNAME editing

  • NFS host mount and remount automation

  • DNS server cache flushing

  • Application bring up and down logic to start applications post failover

  • Send alerts or emails

  • Run API commands on 3rd party equipment example load balancer, switch, router or firewall

Please refer to the Eyeglass Admin Guide Script Engine Overview for more details.

Failover Planning and Checklist

Failover planning includes extended preparation beyond storage layer failover steps as related to the clients, application owners and any dependent systems such as DNS and Active Directory.  A full Failover Plan is required taking this all into account.  A Failover Planning and Checklist document is provided to help you develop your own Failover plan.

Runbook Robot (Automate DR Testing on a schedule)

Overview

Many organizations schedule DR tests during maintenance windows and weekends, only to find out that the DR procedures did not work or documentation needed to be updated.  Eyeglass Run Book Robot feature automates DR run book procedures that would normally be scheduled in off peak hours, and avoids down time to validate DR procedures, providing Failover and Failback automation tests with reporting.

This level of automation provides high confidence that your Isilon storage is ready for failover with all of the key functions executed on a daily basis.   In addition to automating failover and failback, Eyeglass operates as a cluster witness and mounts storage on both source and destination clusters (the same way the cluster users and machines mount storage externally using access zone mount paths).

Run Book Robot Failover Coverage with Basic Setup

  1. API access to both clusters is functioning - Validated

  2. API access allows creation of export, share, quota - Validated

  3. NFS mount of data external to the cluster functions - Validated

  4. SyncIQ policy replication completes between source and destination cluster when data is written to the source - Validated

  5. Configuration replication of test configuration from source to destination - Validated

  6. SyncIQ failover to target cluster - Validated

  7. Test data access on target cluster post failover - Validated

  8. Verify data integrity of the test data on target cluster - Validated

  9. Configuration Sync of quotas from source to target on failover - Validated

  10. Delete of Quotas on source cluster - Validated

  11. SyncIQ Failback from target to source cluster  - Validated

The above validations are all done daily and the DR dashboard updated along with any failures sent as critical event.  When all the above validations pass on a daily basis, this is the best indicator that your cluster is ready for a failover.

Refer to the RunBookRobot Admin Guide for instructions on setting up and running the Runbook Robot.

Operational Steps for Eyeglass Assisted SyncIQ Policy Failover

Eyeglass DR Assisted Failover SyncIQ policy Workflow Overview:

This workflow has dependencies that require manual steps to avoid data access loss.  These conditions are addressed automatically with Access Zone Failover.

  1. User selection of Isilon Cluster which is being failed over “from” (Source).

  2. User selection of one or more SyncIQ policies for failover.

Note: Quotas failover automatically when they match the SyncIQ policy paths

  1. Eyeglass will update the target cluster SyncIQ policy to make it  writeable and the final sync status is shown to the user when completed.

  2. SmartConnect Manual steps: The user must ensure that SmartConnect Zone Aliases are created manually on the target cluster.  (Note: Make sure the SmartConnect Zone was only in use by the SyncIQ policies selected for failover)

    1. This is because an alias created on the target cluster is required for SmartConnect to answer DNS queries from clients expecting to mount the production cluster SmartConnect Zone or alias name.  In addition, SPN collisions in AD can result in authentication failures if the SPN step is skipped.  (see Admin Guide section on Active Directory Machine Account Service Principal Name (SPN) Delegation).

    2. This can be done from the OneFS CLI and is executed against the SmartConnect Zone on the source and target cluster.

  3. SMB only - SPN Step:  Since SmartConnect Zones and associated SPN entries cannot be deleted on the source cluster with Single policy failover workflow (because this may remove access to any data and mounts that are not failed over), no hints are required and it's up to the administrator to ensure SPN’s that must be deleted at the source cluster are removed from the OneFS CLI and the target cluster SPN’s are created using the OneFS CLI.

  4. Final Step: DNS updates for SmartConnect Zones can done.  The SmartConnect Service IP  is used for delegation from DNS to Isilon.  This step is manual but can be scripted with post failover scripting (requires script able DNS server)

    1. This step is manually implemented in your company's DNS system that delegated the SmartConnect Zones to the Isilon cluster.

  5. Verify clients can connect to existing SmartConnect Zone shares and exports using NSLOOKUP to verify DNS and then test mounting from a client machine.

  6. Failover Complete.

IMPORTANT: Making any changes to the SyncIQ Policies or related Eyeglass Configuration Replication Jobs being failed over during the failover may result in unexpected results.

IMPORTANT: Eyeglass Assisted Failover has a 1 hour timeout on each failover step.  Any step which is not completed within this timeout period will cause the failover to fail.

IMPORTANT: Deleting configuration data (shares, exports, quotas) or modifying Share name or NFS Alias name or NFS Export path on the target cluster before failing over without running Eyeglass Configuration Replication will incorrectly result in the object being deleted on the source cluster after failover.  You must run Eyeglass configuration replication before the failover OR select the Config Sync checkbox on failover to prevent this from happening.

IMPORTANT: More than one SyncIQ Policy can be failed over in a single Failover Job but an error in any one of the SyncIQ Policy failovers will cause failover of all SyncIQ Policies to be halted.

For detailed steps consult the failover guide table here.

For detailed steps on execution and monitoring consult the Failover Design Guide

See below for post failover steps.

Monitoring DR Readiness for Eyeglass Assisted Failover

In addition to the Assisted Failover functionality, Eyeglass also provides the following features to monitor your SyncIQ Policy DR Readiness:

  • Policy DR Readiness Validation from the DR Dashboard

  • Runbook Robot from the DR Dashboard

Policy DR Readiness Validation

The DR Dashboard Policy Readiness tab provides a per SyncIQ Policy summary of all SyncIQ OneFS and Eyeglass Configuration replication Job statuses.  The status for each are combined to provide an overall DR Status.  The Policy Readiness is updated each time the Eyeglass Configuration Replication task runs.

This information provides the best indicator of DR readiness for failover and allows administrators to check status on each component of failover, identify status, errors and correct them to get each SyncIQ Policy configured and ready for failover.

If all of the SyncIQ Policy Failover Recommendations pass validation, the DR Dashboard status for the Policy is green indicating that the Policy is safe to failover.   

If any of the SyncIQ Policy Failover Recommendations do NOT pass validation, the DR Dashboard status for the SyncIQ Policy is red indicating that the SyncIQ Policy is NOT ready to failover. Eyeglass will also issue a System Alarm for any of these conditions.

Additional information can be found in the “Policy Readiness and DFS Readiness” section of the  Eyeglass Admin Guide here.

IMPORTANT:

If you make a change to your environment, the following Eyeglass tasks must run before the Policy Readiness will be updated:

  • Configuration Replication - Job Definitions Icon

Post SyncIQ Policy Failover Manual Steps

Update Networking for Client Access

Make the necessary networking changes required to redirect your clients to the Failover Target Cluster.  This may involve:

  • Isilon SmartConnect Zone or Zone Alias updates

  • DNS Updates

Update SPNs

For the case where SMB shares and Active Directory are being used for client access, any add or delete of SmartConnect Zone or Zone Alias will require an SPN update.

Refreshing SMB connection after Failover completed and DNS updated

This section describes steps to refresh an SMB connection post failover and DNS update.

  1. If client was connected to the share during the failover, unmount the share (disconnect).

  2. Remount the share (connect). Check Kerberos and SPN on the target cluster machine account.

  3. Test read/write against newly mounted shares.

  4. If step 3 fails, the original connection information is likely cached on the client machine.  The data in this case would continue to be available, however it would be Read-Only.  Writes would fail. To remove the cached connection information, open a Window cmd window and type the command:

ipconfig /flushdns

  1. Test read/write against newly mounted share again.

  2. If step 5 fails, it is likely a DNS cache issue and needs to be looked at upstream DNS servers.

Refreshing NFS connection after Failover completed and DNS updated

Please refer to document section steps to refresh an NFS connection post failover and DNS update.

Post SyncIQ Policy Failover Checklist

The following sections outline what can be checked post SyncIQ Policy failover to verify execution of all of the steps.

IMPORTANT: If the failover was done with the Controlled failover option unchecked, then some steps on the failover SOURCE cluster will not have been executed.  This is outlined in Appendix 1 in this document.

File System Updates

On the failover SOURCE cluster (the cluster you failed over FROM), the directories and sub-directories corresponding to the SyncIQ Policies that were failed over are read-only.

On the failover TARGET cluster (the cluster you failed over TO), the directories and sub-directories corresponding to the SyncIQ Policies that were failed over are writeable.

SyncIQ Policy Updates

On the failover SOURCE cluster (the cluster you failed over FROM), for the SyncIQ Policies that were failed over:

  • SyncIQ Policies are Disabled in OneFS

  • Eyeglass configuration replication jobs related to these SyncIQ Policies are in Policy Disabled state

  • SyncIQ Policies in OneFS have their schedule set to manual

On the failover TARGET cluster (the cluster you failed over TO), for the SyncIQ Policies that were failed over:

  • SyncIQ Policies are Enabled in OneFS

  • The corresponding Eyeglass Configuration Replication Jobs are also in Enabled state

  • SyncIQ Policies have same schedule that was originally set for the policy on the failover SOURCE cluster

NOTE: If you have Eyeglass “INITIALSTATE” property set to disabled for AUTO jobs (check this using the “igls adv initialstate show” command in the Eyeglass Admin Guide here), the Eyeglass Configuration Replication job for the mirror SyncIQ Policy created during the first failover will be in User Disabled state.  This job should be enabled following the instructions in the Eyeglass Admin Guide here.

Quota Updates

After the upgrade, there should be no quotas on the failover SOURCE cluster for the SyncIQ Policies that were failed over.  On the failover TARGET cluster you should find all quotas for the SyncIQ Policies that were failed over.

APPENDIX 1 - Controlled Failover Option Results Summary

The following table indicates which failover steps are executed based on whether or not the Controlled failover option was selected when the SyncIQ Policy failover was initiated.

Steps

Description

Executed on

SyncIQ Policy

Controlled Failover selected

Controlled Failover NOT selected

1 - Ensure that there is no live access to data

Check for open files.

If Open files found, decide whether to failover or wait to be closed.

Source

Manual

Not applicable - manual step

Not applicable - manual step

2 - Begin Failover

Initiate Failover from Eyeglass

Eyeglass

Manual

Not applicable - manual step

Not applicable - manual step

3 - Validation

Wait for other Eyeglass Failover jobs to complete

Eyeglass

Automated by Eyeglass

Step Executed

Step Executed

4 - Synchronize data

Run all OneFS SyncIQ policy jobs related to the Access Zone being failed over

Source

Automated by Eyeglass

Step Executed

Step NOT Executed

5 - Synchronize configuration (shares/export/alias)

Run Eyeglass configuration replication 1

Eyeglass

Automated by Eyeglass (configuration exists on source and target)

Step Executed

Step Executed based on last known data in Eyeglass

 

*If you do not want this, uncheck the “Config Sync” option to skip this step

6 - Synchronize quota(s)

Run Eyeglass Quota Jobs related to the SyncIQ Policy or Access Zone being failed over

Eyeglass

Automated by Eyeglass (deleted on source cluster and created on target cluster)

Step Executed

Step Executed based on last known data in Eyeglass

7 - Record schedule for SyncIQ policies being failed over

Get schedule associated with the SyncIQ policies being failed over on OneFS

Source

Automated by Eyeglass

Step Executed

Step NOT Executed

8 - Prevent SyncIQ policies being failed over from running

Set schedule on the SyncIQ policy(s)  to manual  on source cluster

Source

Automated by Eyeglass

Step Executed

Step NOT Executed

9 - Provide write access to data on target

Allow writes to SyncIQ policy(s) related to failover2

Target

Automated by Eyeglass

Step Executed

Step Executed

10 - Disable SyncIQ on source and make active on target

Resync prep SyncIQ policy related to failover (Creates MirrorPolicy on target) from OneFS

Source

Automated by Eyeglass

Step Executed

Step NOT Executed

11 - Set proper SyncIQ schedule on target

Set schedule on MirrorPolicy(Target) using schedule from step 6 from OneFS for policy(s) related to the Failover

Target

Automated by Eyeglass

Step Executed

Step NOT Executed

12 - Remove quotas on directories that are target of SyncIQ (Isilon best practice)

Delete all quotas on the source for all the policies

Source

Automated by Eyeglass

Step Executed

Step NOT Executed

13 - Change SmartConnect Zone on Source so not to resolve by Clients

Rename SmartConnect Zones and Aliases (Source)

Source

Manual

Not applicable - manual step

Not applicable - manual step

14 - Avoid SPN Collision

Sync SPNs in all AD providers to current SmartConnect Zone names and aliases (Source)

Source

Manual (deletes smartconnect SPN from source cluster machine account)

Not applicable - manual step

Not applicable - manual step

15 - Move SmartConnect Zone to Target

Add source SmartConnect Zone(s) as  Aliase(s) on  (Target)

Target

Manual

Not applicable - manual step

Not applicable - manual step

16 - Update SPN to allow for authentication against target

Sync SPNs in all AD providers to current SmartConnect Zone names and aliases (Target)

Target

Manual (adds new SmatrConnect alias SPN’s to target cluster machine account)

Not applicable - manual step

Not applicable - manual step

17 - Repoint DNS to the Target cluster IP address

Update DNS delegations for all SmartConnect Zones that are members of the Access Zone

DNS

Manual

Not applicable - manual step

Not applicable - manual step

18 - Refresh session to pick up DNS change

Remount the SMB share(s)

SMB Client Machines

Manual on clients

Not applicable - manual step

Not applicable - manual step

  1. Initiates Eyeglass Configuration Replication task for all Eyeglass jobs

  2. SyncIQ does NOT modify the ACL (Access control settings on the file system).  It locks the file system.   ls -l   will be identically on both source and target