OneFS SyncIQ delivers high-performance, asynchronous replication of unstructured data to address a broad range of recovery point objectives (RPO) and recovery time objectives (RTO). This enables customers to make an optimal tradeoff between infrastructure cost and potential for data loss if a disaster occurs. SyncIQ does not impose a hard limit on the size of a replicated file system so will scale linearly with an organization’s data growth up into the multiple petabyte ranges.
SyncIQ is easily optimized for either LAN or WAN connectivity to replicate over short or long distances, providing protection from both site-specific and regional disasters. Additionally, SyncIQ uses a highly parallel, policy-based replication architecture designed to leverage the performance and efficiency of clustered storage. As such, aggregate throughput scales with capacity and allows a consistent RPO over expanding datasets.
A secondary cluster synchronized with the primary production cluster can afford a substantially improved RTO and RPO than tape backup. Both implementations have their di tinct advantages. And SyncIQ performance is easily tuned to optimize either for network bandwidth efficiency across a WAN or for LAN speed synchronization. Synchronization policies may be configured at the file level, directory level, or entire file-system-level and can either be scheduled to run at regular intervals or performed manually.
Figure 13. SyncIQ change-based replication
OneFS queues any additional jobs until a job execution slot becomes available, and jobs that are queued can be easily canceled. SyncIQ policies also have a priority setting to allow favored policies to preempt others. In addition to chronological scheduling, replication policies can also be configured to start whenever the source is modified (change based replication). If preferred, a delay period can be added to defer the start of a change-based policy.
Bear in mind the following SyncIQ recommendations:
- Highly recommend implementing Superna Eyeglass for failover/failback.
- The recommended limit of running SyncIQ policies is 1000 policies and 50 concurrent jobs per cluster (for a cluster with 4 or more nodes).
- While the maximum number of workers per node per policy is eight, the default and recommended number of workers per node is three.
- The recommended limit of workers per replication policy is 40.
- Recommend having the target cluster running the same or a later version of OneFS as the source cluster.
- After creating a policy and before running the policy for the first time, use the policy assessment option to see how long it takes to scan the source cluster dataset with default settings.
- Increase workers per node in cases where network utilization is low. This can help overcome network latency by having more workers generate I/O on the wire. If adding more workers per node does not improve network utilization, avoid adding more workers because of diminishing returns and worker scheduling overhead.
- Increase workers per node in datasets with many small files to push more files in parallel. Ass more workers are employed, more CPU is consumed, due to other cluster operations.
- Consider using SmartConnect pools to constrain replication to a dedicated set of cluster network interfaces, and to avoid contention with other workflows accessing the cluster through these nodes.
- Use SyncIQ network throttling to control how much network bandwidth SyncIQ can consume.
- Avoid full dataset replications where possible. Changing any of the following parameters will trigger a full baseline sync of the policy:
- Source path or paths: root path, include and exclude paths
- Source file selection criteria: type, time, and regular expressions
- With a policy of type Sync, modifying file attributes comparison options and values causes a re-sync and deletion of any nonmatching files from the target next time the job runs. This does not apply to policies of type Copy.
- Specifying file criteria in a SyncIQ policy will slow down a copy of sync job.
- Full baseline replication takes much longer than incremental synchronizations, so to optimize performance, avoid triggering full synchronizations unless necessary. Changing any of the following parameters will trigger a baseline sync of the policy:
- Source path or paths: root path, include and exclude paths
- Source file selection criteria: type, time, and regular expressions
- Remember that “target aware synchronizations” are much more CPU-intensive than regular baseline replication. However, they potentially generate far less network traffic if both source and target datasets are already seeded with similar data.
- Setting a target cluster password is useful for security and to verify that the source cluster is replicating to the correct target. The target cluster password is different from a cluster’s root password. Do not specify a target password unless you create the required password file on the target cluster.
- If a cluster is running OneFS 8.2 or later, use SyncIQ encryption to protect any replication sessions that traverse WAN or other insecure or untrusted network segments.
For more information, see the PowerScale SyncIQ white paper.