Protection Manager Import Reinitializes Relationship

[kofchur]

I'm in the process of moving over datasets from one DFM instance to another and all is going well except when I imported the relationships on 2 datasets that do a cascade.  From node A to node B, the import went fine and picked up where it left off, but from point B to point C, it created another volume and reinitalized.  This is not supposed to happen.  I relinquished all the relationships between A and B and between B and C and imported them specifying the correct node.  Is this a bug?  I'm using OpsMgr 4.0.2.

The relinquish and import commands I used were like this:

dfpm dataset relinquish filer:/vol_backup

dfpm dataset relinquish filer:/vol_mirror

dfpm dataset import -N Backup Dataset_1 filer:/vol_backup

dfpm dataset import -N Mirror Dataset_1 filer:/vol_mirror

What did I miss, if anything?  thanks.

[smoot]

When you imported the relationships, the preview results ought to have explained why ProtMgr didn't like the relationship or destination volumes. Did you save that output?

[kofchur]

I did it via CLI and there was nothing to indicate there was anything wrong.  All looked normal.

[smoot]

From the CLI, use the -D flag to get a preview ("-D" for "dry run").

If you don't specify that, you'll only see the actual actions, not the reasons for the actions.

[adaikkap · Accepted solution]

Hi

     First let me give the reason why you faced this. In your case you have a cascade topology of A>B>C. And you tried to import the relationship form A>B. PM created the relationship from B>C, following are the reasons.

This is the way PM's conformance engine is designed to do this. It finds that as per the dataset for any member in the primary of the dataset it needs to have a relationship in the node B and C.So when you import the leg from A>B  conformance kicks in when you finish the import wizard/cli, it finds that there is no relationship from B>C and go heads and  creates it if you have resource  pool or a volume attached to the node C.

I agree that PM should have warned about this so that it can be avoided, if you import the leg from B>C first then PM conformance would have not done this, because there is no member on the primary to check if on the secondary (B) and tertiary (C) relationship needs to be create

Regards

adai

[kofchur]

Ah!  Over looked that.  I tested it in our lab and it worked.  Thanks!

[adaikkap]

Hi Todd,

     Happy to help you.Still I strongly feel this as a bug, as Pete said the conformance should have warned you about the downstream relationship creation when you finished importing the leg A>B. I am filing the bug for the same. Can you add your case to bug594423 ?

Also the same will happen in case of a fan out topology as well. i.e A >B and A> C and  its little tricky as we cant do the same here like the A>B>C by importing B>C first and A>B later. The only way I can think off is by suspending the dataset and importing  either of A>B or A>C and once completed resume the dataset.

Regards

adai

[stevedegroat]

I have encountered something similar.  I have a cascading primary>mirror>backup/vault relationship established on a dataset.  I need to move the volumes in that dataset to another dataset with a similar cascading protection scheme (using the same Protection Policy in fact).  After removing the volume from the dataset (taking the volumes out of the Physical Resources of the Primary, Mirror, and Backup lists) I can see both the snapmirror and snapvault entries in the External Relationships list. 

However, if I try to import using the snapmirror entry, PM wants to create a new vault volume and rebasline/reinitialize.  Which I understand and matches your above explanation.

If I try to import using the snapvault entry, it won't let me select the the volume and add it to the dataset (says it is "Not applicable to the Selected Connection).

If I try to import using both entries (ctrl click to highlight both), I can only add the mirror and not the vault, getting the same error message for the vault.

How so I put the entire cascade into the new dataset?

[adaikkap]

Hi Steve,

     You will have to import as follows. IF your dataset is of type A>B>C then import B>C first and A>B later.

Now let me answer why you get the errors you mentioned.

If I try to import using the snapvault entry, it won't let me select the the volume and add it to the dataset (says it is "Not applicable to the Selected Connection).

The reason is because, you have not changed the selection of the connection to Snapvault instead its still A>B in the upper portion of the import wizard.

Pls select the snapvault connection and then the import the same.

If I try to import using both entries (ctrl click to highlight both), I can only add the mirror and not the vault, getting the same error message for the vault.

You cant import both entries, you can only do one type of relationship at a time. As the import wizard can only highlight snapmirror or snapvault.and not both at the same time.

Regards

adai

[stevedegroat]

Absolutely wonderful!  I wasn't aware you could move the "box" in the upper portion of the import wizard screen.  Tested on a small volume and it worked perfectly.

One note of warning to anyone doing this - there is a process in the background, dfmreaper I believe, that will remove the relationships from the External Relationship window within a certain time frame.  Just make sure to quickly import the relationships to your new dataset. 

[adaikkap]

Hi Steve,

     You are right, the default time for a reaper to kick in and delete or reap a relationship is 90mins. If you want to make sure that reaper shouldn't interfere.

Never remove a member from the dataset without relinquishing the relationship with dfpm dataset relinquish cli.

When done so, reaper never kicks in...

Regards

adai