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

Supported DR Site and Failover Topologies

Introduction​

Eyeglass supports several DR site topologies for PowerScale clusters, covering both simple two-site designs and more advanced multi-site configurations. Each topology allows for one or more DR copies of data at different geographic distances, and each supports a different combination of the failover types — Access Zone, DFS, and per-SyncIQ-policy failover — with varying levels of automation.

Data Center to Data Center​

The simplest and most common topology: a single source cluster replicating to a single target cluster at a different site.

Supported failover types​

  • Access Zone — Fully automated failover to the target site.
  • DFS type — Fully automated failover to the target site.
  • Per SyncIQ policy — Partially automated failover to the target site.

Multi-Site Failover​

A three-site topology where a primary site (Site A) replicates independently to two secondary sites (Site B and Site C). This design supports fully automated failover from the primary site to either secondary site.

Supported failover types​

  • Access Zone — Fully automated failover to either site (A to B or A to C).
  • DFS type — Fully automated failover to either site (A to B or A to C), using three DFS referral targets per folder (source plus two targets) so clients are automatically redirected to whichever site is active — no DNS or SPN changes are required for the DFS-type path.
  • Per SyncIQ policy — Partially automated failover to either site.

Preparing for Multi-Site Failover​

Because Site B and Site C both replicate from Site A, an important ordering rule applies before any multi-site failover:

warning

Before failing over from A to B, confirm there are no existing mirror policies from C to A. Before failing over from A to C, confirm there are no existing mirror policies from B to A. If either exists, delete it first — the resync-prep step of the new failover creates mirror policies with the same target paths as any pre-existing mirror policy from the third site, which makes the new mirror policy unrunnable and causes the Eyeglass failover job to fail. This ordering matters because the domain mark on the source cluster is removed once this cleanup step runs.

It is also recommended to run a manual domain mark job against every SyncIQ policy on the source cluster before a multi-site failover, since no domain mark exists until one is created during the failover process itself — running it in advance keeps the resync-prep step from taking longer than necessary, especially for policies covering a large number of files.

Access Zone Failover and Failback Steps (Multi-Site)​

The following sequence applies to Access Zone failover and failback between any pair of sites in a multi-site design:

  1. Confirm there is no live access to data.
  2. Begin failover (or failback).
  3. Validation.
  4. Synchronize data.
  5. Synchronize configuration (shares, exports, aliases).
  6. Change the SmartConnect Zone on the source so it no longer resolves for clients.
  7. Avoid SPN collision.
  8. Move the SmartConnect Zone to the target.
  9. Update SPN to allow authentication against the target.
  10. Repoint DNS to the target cluster (DNS triple delegation, since three sites are involved).
  11. Record the SyncIQ policy schedule being failed over.
  12. Prevent the SyncIQ policies being failed over from running.
  13. Provide write access to data on the target.
  14. Disable SyncIQ on the source and make it active on the target.
  15. Set the correct SyncIQ schedule on the target.
  16. Synchronize quotas.
  17. Remove quotas on directories that are the target of SyncIQ, per PowerScale best practice.
  18. Refresh the client session to pick up the DNS change (using a post-failover script).
tip

When failing back, be careful to select the correct source cluster in the Failover Wizard — for example, when failing back from Site B to Site A, select Site B (not Site A) as the source, otherwise the wizard directs the operation as a failover from A to C instead.

DFS Type Failover Steps (Multi-Site)​

DFS-type multi-site failover follows a similar sequence, but relies on DFS referral and share-renaming behavior rather than DNS/SPN changes:

  1. Confirm there is no live access to data.
  2. Begin failover (or failback).
  3. Validation.
  4. Synchronize data.
  5. Synchronize configuration (shares, exports, aliases).
  6. Rename shares — the inactive site's share is renamed with an igls-dfs- prefix (or deleted, for the third site not involved in this failover), and the active site's share is renamed to its normal name.
  7. Record the SyncIQ policy schedule being failed over.
  8. Prevent the SyncIQ policies being failed over from running.
  9. Provide write access to data on the target.
  10. Disable SyncIQ on the source and make it active on the target.
  11. Set the correct SyncIQ schedule on the target.
  12. Synchronize quotas.
  13. Remove quotas on directories that are the target of SyncIQ, per PowerScale best practice.
  14. Refresh the SMB session so the client picks up the DFS referral change: the client queries Active Directory for the namespace's root targets, selects the active target from the referral list, and connects to the newly active cluster.
note

After a multi-site DFS failover, it takes two configuration-replication cycles for the SMB share name on the third (uninvolved) cluster to reach its final state — the share name passes through an intermediate igls-dfs-igls-dfs- state before the share is deleted. A failback only takes one configuration-replication cycle to reach its final state.

Configure the DFS target folder with three referrals — one per site — and set target priority ordering per cluster so each site's clients prefer their local, in-region path first. The DR Dashboard's DFS Readiness view shows which source/target pairs are currently in an OK or Warning state and therefore eligible for failover; always confirm the correct source cluster is selected in the Failover Wizard before proceeding, since both source/target pairs may show as ready at the same time.

Data Center DR Fan-In Topology​

Multiple source clusters replicate into a single, shared DR target cluster (or a smaller number of target clusters than sources) — a common design for consolidating DR protection for many remote or branch sites into a central data center.

Supported failover types​

  • Per SyncIQ policy
  • Access Zone
  • DFS type

2-Site DR — Stretch 3rd Site Configuration Sync​

A two-site replication topology (A to B) where Eyeglass configuration data is additionally synced to a third site (C) for safekeeping, but failover to that third site is a manual process rather than a fully automated one.

Supported failover types​

  • Access Zone — Automated failover from A to B; configuration is synced to C, but failover to C is manual.
  • Per SyncIQ policy — Automated failover from A to B; configuration is synced to C, but failover to C is manual.
  • DFS type — Automated failover from A to B; configuration is synced to C, but failover to C is manual.

Choosing a Failover Type

Compare DFS, Access Zone, IP Pool, and per-SyncIQ-policy failover to decide which type fits your topology.

See more

Failover Design

Review the step-by-step mechanics and results of each failover type.

See more