In the event of a cluster partition, the best practice is to allow I/O to continue at only one cluster. Allowing I/O to continue at both clusters result in a condition that is known as a conflicting detach. The resolution of the conflicting detach result in the complete resync of the losing cluster from the winning cluster. All writes at the loser cluster are lost.
About this task
When I/O continues at both clusters:
The data images at the clusters diverge.
Legs of distributed volumes are logically separate.
When the inter-cluster link is restored, the clusters learn that I/O has proceeded independently. I/O continues at both clusters until you pick a winning cluster whose data image will be used as the source to synchronize the data images.
In the following example, I/O resumed at both clusters during an inter-cluster link outage. When the inter-cluster link is restored, the two clusters come back into contact and learn that they have each detached the other and carried on I/O.
Steps
Use the
ls command to display the consistency group’s operational status at both clusters.
Use the
resolve-conflicting-detach command to select cluster-1 as the winner.
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> resolve-conflicting-detach -c cluster-1
This will cause I/O to suspend at clusters in conflict with cluster cluster-1, allowing you to stop applications at those clusters. Continue? (Yes/No) Yes
Cluster-2’s modifications to data on volumes in the consistency group since the link outage started are discarded.
Cluster-2's data image is then synchronized with the image at cluster-1.
I/O gets suspended at cluster-2 if the auto-resume policy is false.
Use the
ls command to verify the change in operation status: