Your Browser is Out of Date

Nytro.ai uses technology that works best in other browsers.
For a full experience use one of the browsers below
Dell PowerScale SyncIQ: Architecture, Configuration, and Considerations
Executive summary Introduction Deployment topologies Use cases Architecture and processes Data replication Configuring a SyncIQ policy Impacts of modifying SyncIQ policies SyncIQ performance rules SnapshotIQ and SyncIQ SyncIQ design considerations Failover and failback
Introduction
Failover
Target cluster dataset
Failback
Allow-writes compared to break association
Superna Eyeglass DR Edition SyncIQ and CloudPools SyncIQ security SyncIQ bandwidth reservations Monitoring, alerting, reporting, and optimizing performance Administration SyncIQ replication and data reduction 16 TiB large file support and SyncIQ implications OneFS version compatibility SmartLock compatibility Conclusion Appendix A: Failover and failback steps Appendix B: SyncIQ encryption with self-signed certificates Appendix C: Configuring cascaded replication Appendix D: Configuring custom replication Appendix E: Technical support and resources

Failback

Failback

  • Users continue to read and write to the target cluster while the source cluster is repaired. When the source cluster becomes available again, the administrator decides when to revert client I/O back to it. To achieve this, the administrator initiates a SyncIQ failback, which synchronizes any incremental changes made to the target cluster during failover back to the source. When complete, the administrator redirects client I/O back to the original cluster again.

    Failback may occur almost immediately in the event of a functional test, or (more likely) after time elapses and the issue which prompted the failover can be resolved. Updates to the dataset while in the failover state will almost certainly have occurred. Therefore, the failback process must include propagation of these back to the source.

    Failback policy requirements

    Data may be failed back to a source cluster from a target cluster after a failover for any replication policy with the following requirements:

    • The policy has been failed over to the target cluster.
    • The policy is a synchronization policy and not a copy policy.
    • The policy does not exclude any files or directories from replication.

    Failback consists of three phases. Each phase should complete before proceeding.

    Resync-prep

    Run the preparation phase (resync-prep) on the source cluster to prepare it to receive intervening changes from the target cluster. This phase creates a read-only replication domain with the following steps:

    1. The last known good snapshot is restored on the source cluster.
    1. A SyncIQ policy is created on the target policy appended with _mirror. This policy is used to failback the dataset with any modification that has occurred since the last snapshot on the source cluster. During this phase, clients are still connected to the target.

    Mirror policy

    Run the mirror policy created in the previous step to sync the most recent data to the source cluster.

    Verify

    Verify that the failback has completed using the replication policy report, and redirect clients back to the source cluster again. At this time, the target cluster is automatically relegated back to its role as a target.