As the overall architecture of SyncIQ Policies is designed, other factors to consider are the number of policies running together. Depending on how policies are configured, the cluster may have many policies running at once. If many policies are running together, cluster resources and network bandwidth must be considered. Under standard running conditions, the cluster resources are also providing client connectivity with an array of services running. It is imperative to consider the cluster and network utilization when the policies are running.
Given the number of policies running at the same time, administrators may consider staggering the policies to run a certain number of policies in a specific time period. Policy schedules can be updated to stagger policy requirements and run times, matching policies with the administration requirements.
While considering the number of policies running in a specified time period, the permitted system and network resources may also be tuned to meet administration requirements. OneFS provides options for tuning SyncIQ performance based on CPU utilization, bandwidth, file count, and the number of workers, as discussed in SyncIQ performance rules. A higher level of granularity is possible by only allowing certain nodes to participate in data replication, as discussed in Restricting SyncIQ source nodes. Administrators may also consider assigning a priority to each policy, as discussed in Priority. As policies run, it is crucial to monitor cluster resources through the many available tools, as stated in Monitoring, alerting, reporting, and optimizing performance.
During the design phase, consider the node types on the source and target cluster impacting the overall data replication performance. When a performance node on the source cluster is replicating to archive nodes on the target cluster, this causes the overall data replication performance to be compromised based on the limited performance of the target cluster’s nodes. For example, if a source cluster is composed of F800 nodes and the target cluster is composed of A200 nodes, the replication performance reaches a threshold, as the A200 CPUs cannot perform at the same level as the F800 CPUs.
Depending on the workflow and replication requirements, the longer replication times may not be a concern. However, if replication performance is time sensitive, consider the node types and associated CPUs on the source and target clusters, as this could bottleneck the overall data replication times.