Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

Choosing a Failover Type

Introduction​

Eyeglass supports several failover types for Dell PowerScale: Microsoft DFS, Access Zone failover, IP Pool failover, and per-SyncIQ-policy failover. These are not tiers of the same product — each type automates a different amount of the failover process and fits different combinations of protocol (SMB/NFS), multi-site topology, and administrative effort.

A word about "mode"

DFS, Access Zone, IP Pool, and per-policy are failover types — that's the sense used throughout this page and in the failover type dropdown on step 2 of the Failover Wizard. The wizard's own failover mode field is a separate axis: it selects the kind of operation you're running against a chosen type — Failover/Failback, Enable Rehearsal, or Revert Rehearsal. Planned versus Emergency is a third axis again. When someone asks "what type is it?" or "what mode is it in?", check which of the three they mean.

This page helps you choose the right type for your environment by comparing when to use each type, why Superna recommends it (or not), what you need to know before committing to it, and the estimated knowledge and effort required to configure it. For the technical mechanics of each type — the exact steps Eyeglass automates and the results after failover — see Failover Design. For day-of-failover checklists and readiness validation, see Failover Planning.

The Big Picture: A, B, and C​

Failing over an application requires many moving parts. DR with Eyeglass means making a decision for each of three areas, referred to here as A, B, and C. Each area needs a plan based on the choices below, or your DR failover will not succeed. You cannot skip an area: a gap in any one of them means failover will not succeed unless that area has been implemented and tested. This page focuses on PowerScale, Eyeglass, and file-based DR planning and implementation.

  • A - Data replication: SyncIQ replicates the data and Eyeglass syncs the configuration data (shares, exports, quotas) automatically, with no user actions required. If the source configuration data is not available, you will not be successful at failing over. Replication can run in one direction, where only one cluster is writeable, or in both directions, where both clusters are writeable. Eyeglass detects the direction of replication and matches it when configuration data is synced. After Eyeglass is deployed, all protected data has its configuration protected automatically, including new, modified, or deleted configuration, which is audited at the attribute level for shares, exports, quotas, and aliases.
  • B - Failover solutions: A manual failover is made of many order-dependent, error-prone steps that can easily exceed 100 CLI commands on different devices, which introduces risk when documenting, testing, and executing them. With Eyeglass automated failover, each of these steps is automated, logged, and monitored continuously for readiness. The DR Dashboard shows status and alerts on anything that would block a successful failover. The failover types compared in the matrix below are the choices for this area.
  • C - Client-side failover (zero-touch): The goal is zero steps on clients after the storage-layer failover and the smallest possible data-loss window. See Client-Side Failover Experience.

Failover Type Decision Matrix​

Multi-site support: Fully automated A-to-B or A-to-C failover is supported.

When to use it​

  • For SMB data protection when zero-touch client failover is required.
  • When all steps, including the client side, need to be fully automated.

Why use it​

  • Superna highly recommends DFS-integrated failover for all customers. If you are not using DFS today, the effort to switch mounts to DFS is worth it for the reduction in manual steps.
  • Does not require DNS updates and avoids DNS/IP mount caching issues on clients and servers.
  • Does not require SPN management during failover.
  • Does not require unmount or re-authentication after failover.
  • Allows SmartConnect Zone names to differ between source and destination clusters.
  • Supports active-active cluster replication with SyncIQ.

What you need to know​

  • DFS type can be used with SyncIQ policies that also protect NFS exports, but in that case manual steps or post-failover scripting are needed to update NFS client mounts.

Estimated knowledge and effort to configure​

  • Basic Active Directory DFS knowledge.
  • Share creation on PowerScale.
  • SyncIQ setup on PowerScale.
  • Overall effort: Low.
info

An Access Zone can also contain a mix of DFS and non-DFS clients. DFS clients auto-remount during failover, while non-DFS clients still require a manual remount. This configuration gives up granular per-policy failover in exchange for simpler configuration, since it avoids maintaining separate pools for DFS and non-DFS mounts. For the configuration steps, see Mixed DFS and Non-DFS Clients.

Data Migration with Access Zone Migration​

Access Zone Migration moves data together with its shares, exports, and quotas between Access Zones on the same cluster or on different clusters. It simplifies data migration and updates the configuration data paths to match the destination. For the procedure, see Data and Config Migration.

When to use it​

  • To migrate data and its shares, exports, and quotas between Access Zones on the same cluster or on different clusters.

Why use it​

  • To move application data and configuration between Access Zones or clusters, to balance applications across clusters or isolate them in an Access Zone.
  • To get better failover granularity by creating Access Zones for business units and migrating data into the new Access Zones.

What you need to know​

  • During the SyncIQ copy step, where Eyeglass creates a SyncIQ policy to copy the data, changes made to the source path must be re-synced to catch up. The old configuration data is left behind and must be cleaned up manually.
warning

Users must still remount using the new SmartConnect name in the new Access Zone or cluster. This information is not migrated.

Estimated knowledge and effort to configure​

  • PowerScale networking.
  • SMB and NFS mounting on clients after migration.
  • Overall effort: Medium.

Client-Side Failover Experience​

The type you choose directly affects what a client machine experiences during and after a storage-layer failover. The goal is zero manual steps on the client and the smallest possible data-loss window. The options below are ordered from least to most client impact.

Eyeglass Integrated Microsoft DFS Type​

  • No DNS change required.
  • No re-authentication required.
  • No unmount or remount required.
  • No SPN management required.
  • No SmartConnect Zone changes required.
  • Available with DFS type in Eyeglass; supports SMB shares only.
  • Least steps, smallest data-loss window of the available options.

Eyeglass Automated Configuration Sync with Access Zone Failover (Automatic DNS Failover)​

  • Available with per-SyncIQ-policy failover or Access Zone failover; supports SMB and NFS exports.
  • Requires remounting SMB and NFS exports to resolve the SmartConnect name to the target cluster, including reauthentication.
  • Requires SPN management during failover so Kerberos tickets are issued against the target cluster's AD machine account (Access Zone failover automates this step).
  • Requires IP Pool-to-IP Pool failover planning and mapping when used with Access Zone failover.
  • Higher data-loss window exposure than DFS type, due to the remount requirement.

Networking Solution: Layer-2 Failover and SmartConnect Zone Aliasing​

Some environments have a Layer-2 network path between data centers, which allows an alternative design that moves the Subnet Service IP from the source cluster to the target cluster during failover by editing networking on the target cluster.

Potential benefits​

  • Preserves DNS entries on failover, so no CNAME updates are needed (this is also solved more simply by dual delegation).
  • Eyeglass Access Zone failover can still assist with SmartConnect Zone failover automation, including DNS.

Drawbacks​

  • Only suitable for NFS. SMB is a poor fit because of Kerberos SPN failover issues — SmartConnect names and their SPNs still need to be failed over to the other cluster's computer object in Active Directory, which moves the problem from DNS to Active Directory rather than solving it.
  • Not supported by the Eyeglass workflow to move the Subnet Service IP from the source cluster to the target cluster — this remains a manual step.
  • SmartConnect Access Zones cannot be pre-created on the target, since doing so creates SPN conflicts in Active Directory.
  • Does not solve SPN management at failover, and still requires the Eyeglass Access Zone failover feature.
  • NFS clients using the same FQDN will not auto-remount exports after a Layer-2 failover — stale mounts require a manual remount.
  • Differences between clusters can also cause stale NFS mounts, requiring a remount to complete the failover.
  • If Layer-2 connectivity extends to the DNS server IP address, ARP cache entries on clients and switches can impact name resolution, and may require an ARP cache flush on network switches.
warning

Recommendation: Not Recommended. This approach eliminates a DNS/IP delegation update that dual delegation already solves without manual effort. It does not avoid client-side unmount and remount, does not simplify the number of steps, and introduces additional manual steps (adding the subnet IP on the target and removing it from the source cluster during failover).

NFS Host-Side Unmount and Remount Automation​

For NFS clients that do require a remount, the unmount command can be issued with the force option to avoid stale mounts during either a controlled or uncontrolled failover. Hosts with open files need to unmount and remount against the new cluster. Eyeglass's post-failover script engine can automate this: it runs host-side scripts to unmount and remount PowerScale storage by policy, targeting only the hosts that use the data being failed over.

tip

For details on setting this up, see the Script Engine content referenced from the SyncIQ Type with Eyeglass section of Failover Planning.

DR Readiness​

Eyeglass syncs configuration data, tracks configuration changes, and executes automated failover. It also provides a dashboard that monitors DR status and raises alarms on any change that would affect the ability to fail over. With Eyeglass acting as a cluster witness, monitoring key cluster events and running audits against the clusters, daily manual monitoring of the clusters is no longer required.

Key functions to monitor for DR readiness:

  • SyncIQ jobs monitoring: Eyeglass monitors all SyncIQ jobs and raises an alarm if any are in a failed state.
  • Configuration data sync and audits: Eyeglass syncs shares and exports and stores quotas for failover. If a sync job fails for this metadata, an alarm is raised against the DR state of the data being shared.
  • RPO summary reports: Eyeglass tracks SyncIQ averages over time, flags any SyncIQ job operating outside its normal 30-day range, and reports on the current data-loss window (RPO) per cluster. See RPO Trending and Reporting.
  • Cluster witness and DR testing: Eyeglass can set up a test Access Zone, create test data on the cluster to test failover and failback operations, and test the data path to the cluster while orchestrating failover and failback daily, without impacting production Access Zones. See Runbook Robot.
  • LiveOps dashboard: Syncing snapshot schedules and dedupe settings allows Eyeglass to sync the cluster configuration needed to manage recovery points on either cluster. After failover, snapshots are available as recovery points and data is already deduped, without any waiting. The dashboard shows whether a planned failover can be scheduled with all snapshots and dedupe settings synced in advance. See LiveOps Continuous Operations Dashboard.

Advanced Topics​

Failover Design

Review the step-by-step mechanics, prerequisites, and results for each failover type.

See more

Failover Planning

Follow the pre-failover checklist and readiness validation steps before executing any of these types.

See more