When a SyncIQ policy is configured between a source and target cluster, an association is formed between the two clusters. OneFS associates a policy with its specified target directory by placing a cookie on the source cluster when the job runs for the first time. The cookie allows the association to persist, even if the target cluster’s name or IP address is modified. SyncIQ provides two options for making a target cluster writable after a policy is configured between the two clusters. The first option is to ‘Allow-Writes’, as stated previously in this section. The second option to make the target cluster writeable is to break a target association.
If the target association is broken, the target dataset will become writable, and the policy must be reset before the policy can run again. A full or differential replication will occur the next time the policy runs. During this full resynchronization, SyncIQ creates a new association between the source and its specified target.
In order to perform a Break Association, from the target cluster’s CLI, run the following command:
isi sync target break –policy=[Policy Name]
Note: Practice caution prior to issuing a policy break command. Ensure that the repercussions are understood as explained in this section.
To perform this from the target cluster’s web interface, select Data Protection > SyncIQ and select the “Local Targets” tab. Then click “More” under the “Actions” column for the appropriate policy, and click “Break Association”, as displayed in the following figure.
Figure 29. Break association from web interface
On the contrary, the ‘Allow-Writes’ option does not result in a full or differential replication to occur after the policy is active again, as the policy is not reset.
Typically, breaking an association is useful to temporary test scenarios or if a policy has become obsolete for various reasons. Allowing writes is useful for failover and failback scenarios. Typical applications of both options are listed in the following table.
Table 1. Allow-writes compared to break association scenarios
Allow-writes | Break association |
Failover and failback | Temporary test environments |
Temporarily allowing writes on a target cluster, while the source is restored | Obsolete SyncIQ policies |
When the source cluster is brought up, it does not require a full or differential replication, depending on the policy | Data migrations |
When the source cluster is brought up, it requires a full or differential replication |
As with any major IT implementation, it is recommended to test all functions in a lab environment, rather than a production environment to understand how each function performs.