Active IQ Unified Manager Discussions

WFA 4.2, OCUM 7.3, and SVMDR 1.2.0 Failback not working

MatthewSecaur
2,058 Views

Hello, everyone,

 

I am running the configuration in the subject line on ONTAP 9.3 with a vserver in SVM DR relationship.  I am able to use WFA to perform a failover from CLA (source vserver = vserver1) to CLB (destination vserver = vserver1_dr).  However, when I attempt to run the Workflow called "Failback to Source Storage Virtual Machine" (from the "Storage Virtual Machine Disaster Recovery" pack, v 1.2.0), the workflow fails with the error:

 

ERROR  [Create Storage Virtual Machine SnapMirror] Command failed for Workflow 'Failback to Source Storage Virtual Machine' with error : Unable to create snapmirror: Relationship with destination Vserver "vserver1_dr" already exists.

 

But of course it exists, because Snapmirror is merely broken off (CLA -> CLB).  Since this is a lab and not a production environment, I commented out the code that tries to re-establish an existing Snapmirror relationship and ran the workflow again. This time, it proceeded beyond that step, but much to my surprise, it was updating CLA -> CLB again, and not CLA <- CLB! (The workflow still failed later on, but one issue at a time!).

 

With Snapmirror of individual volumes (i.e. not SVM DR), there is a way to incrementally reverse-resync the Snapmirror relationship; I've done it before.  Is this not possible with SVM DR?  Is there something else that I'm missing here?

2 REPLIES 2

cbauernf
1,998 Views

Matthew,

 

when running the failback workflow, which cluster did you specify as the source and destination?  Even though you are failing back from CLB to CLA, CLA is still the source cluster and CLB the destination in the protection relationship. That designation never changes with the SMVDR workflows.

 

Regards,

 

Christian

MatthewSecaur
1,996 Views

Hi, Christian,

 

Thanks for your response.

 

In fact, I was only presented with one choice for failback, which was just as you said: CLB is the destination cluster, vserver1_dr is the destination SVM, and CLA is the source.

 

When I have some time, I will recreate the environment to ensure I didn't make a mistake somewhere, but I had initialized SVM DR using WFA, so I should hope there was not a configuration problem.

 

Public