Recommendations for Eyeglass Assisted Access Zone Failover
The conditions outlined in the following section are highly recommended to ensure that all automated Access Zone failover steps can be completed. If anyone of these conditions is not met it will result in a Warning.
- Warnings Will Not block Eyeglass Assisted Access Zone Failover, but potentially post failover will require additional manual steps to complete the failover.
- Errors Will block Eyeglass Assisted Access Zone Failover.
Shares / Exports / NFS Alias Recommendations
- All shares, exports and alias should be created in the Access Zone that is being failed over. It is not supported to have shares, exports and alias with a path that is outside (higher in the file system) than the Access Zone base path.
- Impact - Data Access Outage: The policy will not be selected for Failover based on path matching the Access Zone base path resulting in data that will NOT be failed over with the Access Zone.
- Access Zones Readiness in the DR Dashboard show which policies have been matched to the Access Zone and should be verified to ensure all expected SyncIQ policies are present in the Access Zone Readiness.
Example: Share / Export / NFS Alias Configuration RECOMMENDED
Example #1: Share / Export / NFS Alias Configuration NOT RECOMMENDED
Example #2: Share / Export / NFS Alias Configuration NOT RECOMMENDED
- Eyeglass Configuration Replication Jobs for the SyncIQ Policies in the Access Zone being failed over should have been completed without error.
- Impact - Data Access Outage: Any missing or incorrect share / export / NFS alias information will prevent client access to data on the Target cluster. These configuration items will have to be corrected manually on the Target Cluster.
Service Principal Name Recommendations
For optimal Access Zone failover with Eyeglass where Access Zone contains SMB shares that are directly mounted using SmartConnect Zones, the following is recommended:
- Setup delegation for SPN add and delete to allow Eyeglass to automatically update SPNs based on SmartConnect changes made during failover (How to Configure Delegation of Cluster Machine Accounts with Active Directory Users and Computers Snapin).
- Impact: With no SPN updates, SMB share client authentication may not complete. SPNs will have to be updated manually for both the Source and Target cluster to enable Kerberos authentication again. NTLM fallback authentication should be verified with Active directory.
SyncIQ Policy Recommendations - Does not Block Failover
SyncIQ Policy last run should have been successful:
- OneFS SyncIQ Job(s) should have been run at least once.
- OneFS SyncIQ Job(s) for last run should have been successful.
- OneFS SyncIQ Job(s) should not be in a Paused or Cancelled state.
- Impact: depending on it’s current status SyncIQ Policy MAY NOT be able to be run by Eyeglass assisted failover if the above recommendations have not been met . If it does not run, you will incur data loss during failover.
- Example 1: SyncIQ Policy has an error state. If it cannot be run from the OneFS, it will also not be able to run from Eyeglass.
- Example 2: SyncIQ Policy is paused. Eyeglass failover cannot RESUME a paused SyncIQ Policy - this must be resumed from OneFS.
You must investigate these errors and understand their impact to your failover solution.
PowerScale does not support SyncIQ Policy with excludes (or includes) for failover.
- Impact: Not a supported configuration for failback.
PowerScale best practices recommend that SyncIQ Policies utilize the Restrict Source Nodes option to control which nodes replicate between clusters.
- Impact: Subnet pool used for data replication is not controlled therefore, all nodes in the cluster can replicate data from all IP pools. This makes it hard to manage bandwidth and requires all nodes have access to the WAN.
Eyeglass failover will skip failover for any SyncIQ policies in the Access Zone which are in the disabled state.
- Impact - Data Access Outage: If SyncIQ Policies are disabled, the associated filesystem will be writeable on source and will NOT failover. Data on the source cluster will most likely will not be reachable by clients due to the fact that the networking and SmartConnect Zone required for data access will have been failed over, and the source SmartConnect zone is renamed to ensure clients can not mount it.