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
Overview
Asynchronous source-based replication
Source cluster snapshot integration
Processes
Data replication Configuring a SyncIQ policy Impacts of modifying SyncIQ policies SyncIQ performance rules SnapshotIQ and SyncIQ SyncIQ design considerations Failover and failback 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

Source cluster snapshot integration

Source cluster snapshot integration

  • To provide point-in-time data protection, when a SyncIQ job starts, it automatically generates a snapshot of the dataset on the source cluster. After it takes a snapshot, it bases all replication activities (scanning, data transfer) on the snapshot view. Subsequent changes to the file system while the job is in progress will not be propagated; those changes will be picked up the next time the job runs. OneFS creates instantaneous snapshots before the job begins – applications remain online with full data access during the replication operation.

    Note: This source-cluster snapshot does not require a SnapshotIQ module license. Only the SyncIQ license is required.

    Source-cluster snapshots are named SIQ-<policy-id>-[new, latest], where <policy-id> is the unique system-generated policy identifier. SyncIQ compares the newly created snapshot with the one taken during the previous run and determines the changed files and blocks to transfer. Each time a SyncIQ job completes, the associated ‘latest’ snapshot is deleted and the previous ‘new’ snapshot is renamed to ‘latest’.

    Note: A SyncIQ snapshot should never be deleted. Deleting a SyncIQ snapshot breaks a SyncIQ relationship, forcing a resync.

    Regardless of the existence of other inclusion or exclusion directory paths, only one snapshot is created on the source cluster at the beginning of the job based on the policy root directory path.

    Note: Deleting a SyncIQ policy also deletes all snapshots created by that policy.

    Snapshot integration alleviates treewalks

    When a SyncIQ job starts, if a previous source-cluster snapshot is detected, SyncIQ sends to the target only those files that are not present in the previous snapshot, as well as changes to files since the last source-cluster snapshot was taken. Comparing two snapshots to detect these changes is a much more lightweight operation than walking the entire file tree, resulting in significant gains for incremental synchronizations after the initial full replication.

    If there is no previous source-cluster snapshot (for example, if a SyncIQ job is running for the first time), a full replication will be necessary.

    When a SyncIQ job completes, the system deletes the previous source-cluster snapshot, retaining the most recent snapshot to be used as the basis for comparison on the next job iteration.