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.
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.
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
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.