Introduction
Superna Disaster Recovery Edition (built on the Eyeglass platform) provides single-button, assisted failover for Dell PowerScale OneFS clusters that replicate data with SyncIQ. It closes the gap between what SyncIQ already does — replicate file system data between clusters — and what a real recovery event actually requires: synchronized configuration, coordinated networking changes, authentication continuity, and a repeatable, auditable failover process.
This page introduces the problem Disaster Recovery solves, the terminology used throughout the DR documentation, an overview of the supported failover modes, and how PowerScale SyncIQ and Superna Eyeglass work together to deliver an orchestrated recovery.
Explore the Documentation
What's New
The latest updates to Disaster Recovery Edition.
Prerequisites
Platform compatibility, system requirements, licensing, and network/port requirements before deploying Disaster Recovery.
Installation Guide
Deploy the Eyeglass virtual appliance, add clusters, and complete initial configuration.
Configuration
Configuration Guide, Failover Guide, Readiness Guide, Integration Guide, and API Guide.
User Help
Use Cases and Troubleshooting for executing, testing, and recovering from a failover.
Reference
Compliance Guide, CLI/UI/compatibility references, technical advisories, and disclaimers.
The Problem Disaster Recovery Solves
SyncIQ replicates file system data from a source PowerScale cluster to a target cluster, but a manual failover involves many additional, order-dependent, and error-prone steps across multiple systems: making the SyncIQ policy target writable, updating DNS and SmartConnect Zone delegations, managing Kerberos Service Principal Names (SPNs) in Active Directory, failing over quotas, and remounting or redirecting clients. Performed manually, a single failover can require more than 100 individual CLI commands across different devices, introducing significant risk to documenting, testing, and executing a recovery under pressure.
Disaster Recovery automates and orchestrates these steps so that:
- Configuration data (shares, exports, quotas, aliases) stays synchronized between clusters automatically, in addition to the file data SyncIQ replicates.
- Failover readiness is continuously monitored and surfaced on a single dashboard, rather than requiring daily manual cluster checks.
- Failover execution is driven from one console (Failover Wizard) instead of scattered manual procedures.
The storage layer is the foundation of an end-to-end disaster recovery plan. A complete DR plan also needs to account for application-level shutdown and startup procedures, which are outside the scope of the storage failover orchestration described here.
Core Solution Capabilities
- Configuration replication — shares, exports, quotas, and aliases are synchronized between clusters automatically and continuously, independent of SyncIQ's file data replication, and in the correct direction even when data flows both ways (hot-hot).
- DR readiness monitoring — a dashboard continuously validates whether each Access Zone, IP Pool, or SyncIQ policy is in a state where failover would succeed, performing over 30 individual readiness conditions, and raises alarms when a condition (a failed SyncIQ job, a configuration sync error, an SPN mismatch, and similar) would block a successful failover.
- Assisted failover execution — the Failover Wizard drives and logs the failover steps for a chosen failover mode, with real-time progress and a detailed failover log for troubleshooting.
- DR rehearsal and continuous testing — failover can be tested without impacting production, either as an on-demand rehearsal or as an automated, recurring test (see Use Cases).
- LiveOps continuous operations monitoring — the LiveOps dashboard tracks ongoing operational health between replicating cluster pairs — reachability, OneFS release/API version, and continuous snapshot/dedupe sync status — complementing the DR Dashboard's failover-readiness view.
- REST API and scripting — advanced integrations and pre/post-failover automation (for example, host-side unmount/remount) are supported through the Eyeglass REST API and script engine.
Key Terminology
| Term | Description |
|---|---|
| CAA (Core Agent Appliance) | The Eyeglass virtual appliance itself — the OVF/VHDX package you download and deploy in the Installation Guide to run Disaster Recovery Edition. All of the orchestration described on this page (configuration replication, readiness monitoring, the Failover Wizard) runs from the CAA. It's distinct from the External Cluster Agent (ECA) used by Data Security features. |
| SyncIQ | Dell PowerScale OneFS's native, snapshot-based asynchronous replication technology. It replicates file system data from a source path to a target path on another cluster. SyncIQ does not, by itself, replicate shares, exports, quotas, aliases, snapshot schedules, or deduplication paths, or orchestrate a failover. |
| Access Zone | A OneFS construct used to logically separate protocols, authentication providers, and data on a cluster. Disaster Recovery can use the Access Zone as the unit of failover, grouping all shares, exports, quotas, aliases, snapshot schedules, deduplication paths, IP Pools, and SyncIQ policies within it so they fail over together. |
| Failover | The process of making a target cluster's replicated data writable and redirecting client access to it, because the source cluster or site is unavailable (or a failover is being tested or planned). |
| Failback | The reverse of a failover: returning production access to the original source cluster once it is available again, after data has been resynchronized. |
| Reverse replication | Once a failover is complete, SyncIQ replication direction is reversed so that the newly-active (target) cluster now replicates back to the original source cluster, keeping the two clusters in sync in preparation for failback. |
| Reprotection | The state after a failover and reverse replication are complete, in which the environment is once again protected by an active replication relationship, ready for a future failover or failback event. |
| Failover Wizard | The Eyeglass console used to initiate, monitor, and log an assisted failover, including full failovers, DR rehearsals, and recovery from a failed step. |
Supported Failover Types (Overview)
Disaster Recovery for Dell PowerScale supports several failover types, each suited to different protocols, environments, and levels of automation. This page provides only a high-level overview — for the detailed workflow, prerequisites, and outcomes of each type, see the Design Guide.
- DFS Type
- Access Zone / IP Pool
- Per-SyncIQ Policy
Microsoft DFS-integrated failover is Superna's recommended type for SMB data protection. It uses DFS UNC targets on both clusters so that clients switch to the writable cluster automatically, without DNS changes, SPN management, or manual remounts.
Access Zone failover treats an entire Access Zone (or, more granularly, an IP Pool within it) as the unit of failover, automating SmartConnect Zone, DNS dual-delegation, and SPN changes for both SMB and NFS data.
Per-policy failover gives the most granular control over what portion of the file system fails over, at the cost of more manual steps (SPN and DNS updates are not automated). It is best suited to NFS exports, smaller host counts, or cases needing pre/post-failover scripting.
Multi-site (3-site) topologies are also supported for Access Zone, IP Pool, and DFS type failover, allowing a fully automated A→B or A→C failover. See the Design Guide for topology guidance.
How PowerScale SyncIQ and Superna Eyeglass Work Together
SyncIQ and Superna Eyeglass operate at different layers of the same problem:
- SyncIQ (native to OneFS) replicates file system data between the source and target paths defined in a replication policy. It does not replicate shares, exports, quotas, aliases, or IP/DNS/SPN configuration, and it has no concept of a coordinated, multi-cluster failover.
- Superna Eyeglass sits above SyncIQ and PowerScale OneFS. It continuously synchronizes the configuration data that SyncIQ does not, monitors both clusters for anything that would prevent a successful failover, and orchestrates the ordered sequence of steps (data sync, configuration sync, networking, authentication, quota handling) needed to complete a failover or failback with a single action in the Failover Wizard.
Because Eyeglass tracks and audits configuration and replication state continuously, daily manual monitoring of the clusters is not required — the DR Dashboard and alarms surface anything that would block a successful failover before it is needed.
See Also
- Prerequisites – Platform compatibility and system requirements before deploying Disaster Recovery.
- Design Guide – Failover modes, supported topologies, and failover planning guidance.