DR Configuration Guides
Post Access Zone Failover Checklist
Home

Post Access Zone Failover Checklist

The following sections outline what can be checked post Access Zone 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.  

SyncIQ Policy Updates

On the failover SOURCE cluster (the cluster you failed over FROM), for the SyncIQ Policies in the Access Zone 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 in the Access Zone 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 command in the  Eyeglass Administration Guide), 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 Administration Guide.

Quota Updates

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

SPN Updates

After the upgrade, there should be SPNs for all SmartConnect Zones and SmartConnect Zone Aliases related to the subnet pools associated with the Access Zone that was failed over.

Note: SPNs are not created for SmartConnect Zones or SmartConnect Zone Aliases that are prefixed with “igls”.

Note: SPNs are not created for HDFS or NFS.  These will need to be repaired manually.

IMPORTANT:

Due to an PowerScale issue, it may occur that executing the SPN repair step results in an error (both for execution by Eyeglass and from the PowerScale command line directly).  In this case the SPNs will have to be repaired manually after which the SPN repair command will resume as expected.

Use the ADSIedit tool to verify the machine account SPN’s.

SmartConnect Zone Updates

The following changes can be checked post failover for the SmartConnect Zones and aliases related to the subnet pools associated with the Access Zone that was failed over:

  1. Eyeglass creates SmartConnect Zone alias on failover TARGET cluster with the same name as SmartConnect Zone on the failover SOURCE cluster partner IP Pool.
  2. Eyeglass updates failover SOURCE cluster SmartConnect Zone name with the prefix “igls-original” .
  3. Alias for failover TARGET SmartConnect Zone is removed from failover SOURCE cluster.
  4. After Failover completed, DNS Admin or post failover scripting updates DNS entry for the SmartConnect Zone name to use the SmartConnect Service IP address from CLUSTER 2.

Example: SmartConnect Zone Update

Initial Mapping Setup:

FAILOVER from CLUSTER 1 to CLUSTER 2

 Cluster 1Cluster 2
subnet1:ProdEyeglass renames SmartConnect Zone prod.example.com to igls-original-prod.example.com 
subnet1:DR Eyeglass creates SmartConnect Zone alias prod.example.com
subnet0:synciq-prodno changes 

FAILOVER AGAIN - CLUSTER 2 to CLUSTER 1

Subnet and PoolCluster 1Cluster 2
subnet1:Prod

Eyeglass renames SmartConnect Zone igls-original-prod.example.com to prod.example.com

Eyeglass creates SmartConnect Zone alias dr.example.com

 
subnet1:DR 

Eyeglass renames SmartConnect Zone dr.example.com to igls-original-dr.example.com

Eyeglass removes SmartConnect Zone alias prod.example.com created by previous failover

subnet0:synciq-prodno changes 

© Superna LLC