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

Failover Best Practices

Introduction​

This page collects best practices for designing and operating Eyeglass-assisted failover on Dell PowerScale — covering general recommendations, failover-type design choices, DNS and networking configuration, Kerberos SPN management, data loss risk during failover, and failover step timeouts. Use it alongside Choosing a Failover Type and Failover Planning when designing your DR environment.

General Best Practices​

  • Use DFS type for SMB share protection and DR.
  • Use Access Zone failover when NFS and SMB data need to fail over together, or when multi-protocol support is required within a single Access Zone.
  • Use per-SyncIQ-policy failover for environments with a small number of NFS exports and hosts — it is faster and requires less planning and configuration than Access Zone failover, since you unmount and remount to the new DR SmartConnect Zone name.
  • Access Zone failover is what allows both SMB and NFS protocols to fail over together as a single unit.
  • Create SmartConnect mapping alias hints on all IP subnet pools, and hint the SyncIQ SmartConnect Zone with ignore to ensure it is not failed over.
  • Delegate machine account credentials to cluster machine accounts in Active Directory.
  • Enable phone-home support for faster support response times.
  • Configure Runbook Robot against an Access Zone and set of policies to confirm failover and failback succeed daily.
  • Always use an FQDN for SmartConnect Zone names.
  • Create a SyncIQ Failback Domain (see Domain Mark and Failback Preparation) so failback operations take less time.
  • Create a dedicated IP pool and SmartConnect zone used only for SyncIQ traffic, and configure policies to connect to nodes in the target SmartConnect zone.
  • Do not mount data using the SmartConnect zone reserved for SyncIQ traffic — use separate IP pools and SmartConnect zones for user data mounts.

Best Practices for DFS Type Failover Design​

  • Use domain-based DFS roots rather than server-based DFS roots.
  • Use a DFS referral ordered list that puts the production UNC path first, to speed up referral processing and mount times.
  • Use UNC path targets that point to SmartConnect zones.
  • Name SmartConnect zones differently on the source and target clusters — this makes debugging with dfsutil.exe easier and lets SmartConnect load cluster nodes correctly during normal operation and after failover.
  • Group one or more SyncIQ policies with a shared naming prefix and enable DFS type in Eyeglass to fail over related policies together.
  • Create dedicated IP pools on the source and target clusters for DFS-protected data, and within an Access Zone create igls-ignore hints so those SmartConnect zones are not failed over along with Access Zone failover.

Best Practices for Access Zone and Per-SyncIQ-Policy Failover Design​

A "sub-Access-Zone" design — failing over a single SyncIQ policy within an Access Zone rather than the whole zone — is supported, but has real limitations on how much of the process Eyeglass can automate.

warning

Do not attempt to fail over a single SyncIQ policy within an Access Zone unless you are prepared for the following manual steps:

  • There is no way to map a SyncIQ policy to the SmartConnect zone clients use to mount the data. Failing over a SmartConnect zone using an alias in this scenario risks making the zone's other, non-failed-over clients unable to reach the production cluster. Eyeglass cannot fail over a SmartConnect zone without this risk unless all SmartConnect zones in the Access Zone are failed over to the target cluster together.
  • The storage administrator is responsible for manually failing over the SmartConnect zone in this scenario.
  • SPN deletion on the source and creation on the target is also a manual step the storage administrator must perform.

Recommended (DO) practices:

  • Configure Access Zone failover and design DR so that all policies and SmartConnect zones in the Access Zone fail over together.
  • Keep all SyncIQ policies at the same level as the Access Zone base path, or lower in the file system.
  • Create shares and exports underneath the path of SyncIQ policies so they are automatically protected.
  • Set up subnet-to-pool mappings for Access Zone failover using hints to map pools.
  • Set up Runbook Robot in Advanced mode against an Access Zone configuration and confirm it succeeds before attempting a real Access Zone failover.
  • Use DFS type for SMB within a multi-protocol Access Zone failover design.

Practices to avoid (DON'T) unless the limitations above are understood:

  • Failing over at the per-SyncIQ-policy level within an Access Zone without accepting that any SmartConnect zones involved must be failed over manually with aliases and DNS updates, and that AD SPN creation/deletion is also manual — Eyeglass cannot know which SmartConnect zones and SPNs are still required on the source cluster once only part of an Access Zone has failed over.

DNS Best Practices for Access Zone Failover​

  • The DNS delegation that points NS records at SmartConnect zones is the last step in the failover process, redirecting to the failover SmartConnect Service IP (SSIP) on the target cluster.
  • The NS record is set up to point at the production cluster's SSIP for the SmartConnect zones within the Access Zone that will fail over; SmartConnect zone aliases also need NS records delegating to the SSIP the alias is assigned to.
  • Delegate using an A record for each SSIP, with the NS delegation pointing to a CNAME that resolves to that A record. This makes failover simpler — you only need to update the CNAME to point at the DR cluster's SSIP A record.

General DNS Verification Checklist​

  • Set the DNS time-to-live (TTL) on NS delegations to zero, or as close to zero as possible, so DNS information stays fresh — some clients cache DNS results and may not reconnect to the lowest-load node if they reuse a cached address across multiple connections within its lifetime.
  • Do not create reverse DNS (PTR) records for PowerScale SmartConnect service IPs or SmartConnect zone names — SmartConnect does not provide reverse lookups. If A records are used for PowerScale node IPs and SSIPs instead, make sure forward and reverse lookups match (an nslookup of the IP returns the expected hostname and vice versa) — this is required for TLS connections to validate correctly and resist man-in-the-middle attacks.
  • Delegate to address (A) records, not directly to IP addresses. The SmartConnect service IP on a PowerScale cluster must be created in DNS as an A record. This means that if you ever need to fail over an entire cluster, you only need to change that one A record — no other name server delegations need to change.
  • Use one name server record per SmartConnect zone name or alias. This lets you fail over a single SmartConnect zone's workflow independently, without affecting other zones — useful for DR testing and for moving individual workflows between data centers.
  • Keep NFS mount paths consistent, in the format sczonename.domain.com:/ifs/path, so failover does not require manually editing fstab or automount entries on clients.
  • Use Access Zones to compartmentalize data by importance. On OneFS 7.1.1 or later, define an Access Zone root path (for example, /ifs/clustername/accesszonename/) in addition to the default System Access Zone, to help segment data appropriately.
  • Where possible, recommend that client system administrators disable client-side DNS caching, since SmartConnect requires clients to use the latest DNS entries to connect to the correct zone.
  • Do not create a single DNS delegation per cluster with SmartConnect zones as sub-records of that delegation — delegate per SmartConnect zone name or alias instead.
info

Each cluster only needs one SmartConnect service IP (SSIP), as long as there is no firewall between the infrastructure DNS servers and the SSIP blocking TCP/UDP port 53 — regardless of how many domains or subnets the cluster participates in. SmartConnect answers only for the SmartConnect zone names and aliases configured on it, and the subnet the DNS server itself resides in is irrelevant to which IP address it returns.

Best Practice for PowerScale Networking​

Use fewer IP pools where possible, to simplify DNS and alias creation on failover and reduce the number of DNS updates required. For example, a typical design uses separate SmartConnect zones for:

  • Data access
  • SyncIQ replication traffic
  • Management (Eyeglass and other applications)
  • Backup traffic

Best Practice for Kerberos Service Principal Names (SPNs)​

  • Use Eyeglass DFS type to limit Kerberos authentication issues tied to cluster machine accounts, since DFS type does not require SPN management during failover.
  • Do not rely on NTLM fallback as part of your DR strategy. If NTLM fallback is disabled — whether by your own policy or by a Microsoft OS/patch change — your failover design should not depend on it. Keep SPNs accurate for Kerberos authentication and use Access Zone failover as the failover unit where SPN automation matters.

Data Loss Considerations​

When a SyncIQ policy runs on a schedule or in "run on changes" mode, it's important to understand the data-loss impact if a SyncIQ job happens to be running at the moment a failover starts.

  • By default, when a failover job starts, Eyeglass attempts one final data sync by running the SyncIQ policies included in the job.
  • If a SyncIQ job for one of those policies is already running, Eyeglass will wait up to one hour for it to complete before continuing.
  • If that running SyncIQ job has not completed within the hour, Eyeglass returns an error and aborts the failover.
  • Because SyncIQ replication is snapshot-based, any changes made since the start of the already-running job are lost if that job does not complete in time. Depending on when that job started, this could represent a significant amount of data.
warning

This one-hour wait applies to a SyncIQ job that is already running when failover starts — it is a different mechanism from the configurable per-step failover timeout described below. Do not confuse the two when planning a failover window.

To reduce this risk:

  • Before starting a failover, log in to PowerScale and confirm whether a SyncIQ job is currently running for the policies you are about to fail over.
  • If a job is running, either wait for it to complete before starting the failover, or consider disconnecting client access at that point so no additional data needs to replicate during the job.
  • Set the SyncIQ policy schedule to manual before starting a planned failover — Eyeglass will run the policy itself as part of the failover procedure.
  • For urgent failover requirements where the data-loss window is an acceptable trade-off, you can skip the config-sync and data-sync options in the Failover Wizard UI.

Failover Step Timeouts​

Eyeglass applies a per-step timeout to certain cluster operations it orchestrates during failover — for example, starting resync-prep, running a policy, or making a policy writable. This timeout is configurable.

Very large SyncIQ policies (a large volume of data or a very large number of small files under a single policy) or policies with a high daily change rate and a normal run time of over an hour may need an increased timeout to avoid the operation being cut off before it completes. If your environment has policies that meet this profile, plan to increase the failover step timeout before attempting a failover or failback of those policies, and make sure you have already run Domain Mark against them in advance, since Domain Mark itself can take hours on a large path.

tip

Failover step timeouts, and how to adjust them, are configured through the Eyeglass CLI. Contact Superna Support to confirm the current default timeout for your release and the correct command and value to use for your environment before increasing it.

Domain Mark and Failback Preparation

Create and verify a SyncIQ domain in advance of failover to speed up failback.

See more

Choosing a Failover Type

Compare DFS, Access Zone, IP Pool, and per-SyncIQ-policy failover types.

See more

Failover Planning

Follow the full pre-failover checklist, readiness validation, and quota options.

See more