Requirements for Eyeglass Assisted Access Zone Failover

The requirements in this section must be met in order to initiate an Eyeglass Access Zone Assisted Failover. Failure to meet some of these conditions may block the Access Zone Failover.

Cluster Version Requirements - May Block Failover

Clusters participating in an Access Zone Failover must be running the supported PowerScale Cluster version for this feature. See the Feature Release Compatibility matrix in the Eyeglass Release notes specific to your Eyeglass version found here.

Access Zone Requirements - Blocks Failover

For an Access Zone failover with Eyeglass, the Access Zone must meet the following requirements:

Release	System Access Zone Failover only Zone on the cluster	System Access Zone and Other non system Access Zones with failover
1.4 update 1 to 1.5.4	Supported	Not supported
1.6.0 >	Supported	Supported

Access Zone must exist on Target Cluster with same name and authentication providers (NOTE: Access Zone Sync Jobs in Eyeglass can be used to create Access Zones automatically)
Access Zone must be associated with at least one subnet IP pool
Access Zone must be associated with one or more SyncIQ policies

SyncIQ policies associated to Access Zone by path - the SyncIQ policy source path must be the same or below the Access Zone base path

In Active-Active data replication topology, there is a dedicated Access Zone for each replication direction.

Failover with Eyeglass of an Access Zone for Active-Active data replication topology that is shared by SyncIQ Policies on both clusters is NOT SUPPORTED as there is no “partial” fail back path to only failback the subset of the SyncIQ policies that were originally failed over.

Example: Unsupported

Example: Supported

SyncIQ Policy Requirements - Blocks Failover

For an Access Zone failover with Eyeglass, it is required that the SyncIQ policy(s) identified as part of the Access Zone (based on Access Zone base path and SyncIQ Policy source path) meet the following requirements:

All OneFS SyncIQ Policy(s) must have the same Target Cluster provisioned (release 1.5.4 and earlier)
In Release 1.6 and later multi site replication allows an Access Zone policy to have a 3rd cluster target for multi site failover requirements. This can be a simple policy based failover, OR fully automated Access Zone Multi site failover policy if configured.
OneFS SyncIQ Policy(s) Target Host SmartConnect Zone must be associated with a pool that is NOT going to be failed over
SyncIQ Policy(s) source root directory must be at or below the Access Zone Base Directory

Example: Unsupported

Example: Supported

DFS Mode Requirements

DFS mode does not require SmartConnect zone names to failover. If you have DFS mode SyncIQ policies that fall within the Access Zone root path, it is required to have a dedicated subnet:pool with SmartConnect Zones that are used for UNC paths for DFS folder targets. Please refer to the Eyeglass Microsoft DFS Mode Failover Guide here for more details on DFS mode setup and requirements.

Note:

DFS enabled policies that also protect NFS exports will require separate SmartConnect Zone for NFS export data access to take advantage of Access Zone automation or manual steps / post failover scripting to update NFS client mounts.

Shares / Exports / NFS Alias Requirements

Exports with multiple paths, where all paths are not associated with the same SyncIQ Policy, are not supported for Access Zone failover. This will result in a “A unique readiness data …” error in Zone Readiness and the Overall Status cannot be displayed.

Eyeglass SmartConnect Requirements - Blocks Failover

For an Access Zone failover with Eyeglass, the SmartConnect Zone FQDN must not exceed 50 characters.
The Pool “SmartConnect service subnet” must be provisioned with the same Subnet that the Pool was created in.

Eyeglass Failover Mapping Hints Requirements - Blocks Failover

For an Access Zone failover with Eyeglass, a mapping between subnet pools on the Source and Target cluster is required to ensure that data is accessed from the correct SmartConnect Zone IP and node pool on the Target cluster after failover.

This mapping is used to failover SmartConnect zones from IP to IP pool and for failback.

The Eyeglass mapping hints have the following requirements: (NOTE: This is a one time setup process but needs to be repeated if new IP pools are created).

Eyeglass Mapping Hints are simple SmartConnect aliases created with ISI or UI to map IP Pools and SmartConnect Name failover mapping between pairs of clusters. See mapping hints examples section.
Every subnet IP pool associated with the Access Zone being failed over is required to have a mapping PER IP pool in the Access Zone. DR Dashboard will raise an error if mapping hints are not found or incorrectly created.
Eyeglass mapping hints on both Source and Target cluster IP pools are created in UNIQUE pairs. See IGLS mapping hints section for syntax and examples.
Incorrectly mapped pools will be alarmed in Access Zone Readiness in the DR Dashboard Access Zone Readiness Tab.
DFS mode does not require SmartConnect zone names to failover. If you have DFS mode SyncIQ policies in the Access Zone, a dedicated subnet:pool with Eyeglass igls-ignore hint applied is required to retain SmartConnect zones on source and target clusters.
The Subnet Pool which is used in the SyncIQ Policy Restrict Source Nodes option must NOT have an Eyeglass mapping hint and must have an igls-Ignore Hint applied (NOTE: If misconfigured the SmartConnect zone used by SyncIQ would failover and would impact failback operations and SyncIQ replication.)
The Subnet Pool which is associated with SyncIQ Policy Target Host property of a SyncIQ policy. This SmartConnect zone must NOT have an Eyeglass mapping hint and must have an Ignore Hint applied. This is the pool on the target cluster used for SyncIQ replication. NOTE: Failure to apply this hint can affect failback operations and SyncIQ replication if the SmartConnect name is failed over by Eyeglass. See mapping hints examples section.
Ignore hints are simply an alias with name of “igls-ignore” NOTE: best practise to ensure unique hints by using a naming format that uses cluster name example igls-ignore-clustername. This allows Eyeglass to match on igls-ignore while allowing the hint to be unique to avoid SPN collision in the Active Directory if the SmartConnect alias is added to AD with check or repair ISI command on the cluster. Since Hints are SmartConnect aliases they can be inserted to AD machine account but are not required for kerberos authentication since they are not used to mount shares. See Active Directory Machine Account Service Principal Name (SPN) Delegation in this document for detail.

Example: Unsupported

Example: Supported

Failover Target Cluster Requirements - Block Failover

For an Access Zone failover with Eyeglass, it is required that the PowerScale Cluster, that is the target of the failover, be IP reachable by Eyeglass with the required ports open.

Eyeglass Quota Job Requirements - Will not Block Failover

For an Access Zone 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.