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.

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.

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.

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