SM Secondary used to Seed Baseline for SV Secondary fails to show in NA Management Console

ASUNDSTROM · ‎2012-09-07

Summary: We are trying to switch from using a SnapMirror Relationship to a SnapVault Relationship without having to rebaseline. We are doing this using a specific interface that is configured in the snapmirror.conf file; vif_lab-14. Snapvault Relationships do show up in the External Relationships tab in the NetApp Management Console, just not the one that was seeded with the SnapMirror Relationships destination volume. Is there any way to manually force the detection of the external relationships. I have used dfpm relationship list on the DFM server and it doesn't see the SMtoSV Relationship either.

Here are the detailed steps that I took.

Lab Test: Primary FAS - lab-fas1

FAS1 Primary Volume - /vol/vol_cifs_01 [100G]

FAS1 Qtree - /vol/vol_cifs_01/qtree_cifs_01

FAS1 Root Subfolder - /vol/vol_cifs_01/FolderInRootOfVolume

DR FAS - lab-fas2

1. Initial SnapMirror Setup Steps on FAS2

a. Create the SnapMirror Volume on FAS2

i. Create a 100GB volume: vol create smvol_cifs_01 aggr_fas2_sata1 100g

ii. Set the Snap Reserve to 0% snap reserve smvol_cifs_01 0

iii. Disable the default Snapshot Schedule snap sched smvol_cifs_01 0 0 0

iv. Restrict the destination volume vol restrict smvol_cifs_01

b. Configure the SnapMirror Relationship for the FAS1 Primary Volume

i. Initialize the snapmirror relationship in the OnCommand System Manager

1. This will fail, stating it cannot connect to the source filer. We have previously set up the snapmirror.conf file with a multi definition so that the snapmirror flows to the source filer will use the VIF designated for the snapmirror traffic:

lab-22fas1 = multi(lab-22fas1-vif_lab-14,lab-22fas2-vif_lab-14)

2. Snapmirror has to be turned off and then back on for the snapmirror relationship to initialize

snapmirror off

snapmirror on

3. Through the OnCommand System Manager, select the SnapMirror Relationship and reinitialize

4. Now the SnapMirror Relationship should register as OK.

c. Verify the Destination Volume contains the same data

i. Root of Destination Volume contained both the Qtree qtree_cifs_01 and the Folder FolderInRootOfVolume and their contents

ii. The snapmirror.conf file contained this line:

lab-22fas1:vol_cifs_01 lab-22fas2:smvol_cifs_01 - - - - -

1. no schedule has been set up as of yet.

2. Setup the SnapVault Relationship on FAS2, with the SnapMirror Destination Volume

a. Quiesce the SnapMirror Relationship snapmirror quiesce smvol_cifs_01

b. Set up the new SnapVault Volume at the size of the SnapMirror volume plus 25% vol create svvol_cifs_01 aggr_fas2_sata1 125g

c. Set the SnapShot Reserve to 0 snap reserve svvol_cifs_01 0

d. Turn off the default SnapShot Schedule snap sched svvol_cifs_01 0 0 0

e. Create the SnapVault Relationship, specifying the destination path with a qtree that does not exist currently. snapvault start -S lab-22fas2:/vol/smvol_cifs_01 lab-22fas2:/vol/svvol_cifs_01/vault01

3. Update the SnapMirror Destination Volume with any changes, then quiesce the SnapMirror Relationship, then update the SnapVualt Destination with any changes on the SnapMirror Destination

a. Copy new data to both the FolderInRootOfVolume and qtree_cifs_01 on the Source SnapMirror Volume

b. Resume the SnapMirror Relationship: snapmirror resume smvol_cifs_01

c. Update the SnapMirror Destination Volume snapmirror update smvol_cifs_01

d. Verified that the new data is in the Destination SnapMirror Dataset

e. Quiesce the SnapMirror Relationship snapmirror quiesce smvol_cifs_01

f. Update the SnapVault Destination volume with any changes to the SnapMirror Secondary snapvault update lab-22fas2:/vol/svvol_cifs_01/vault01

g. Verified that the new data is in the Destination SnapMirror Dataset

4. Update the SnapVault Relationship to point to the SnapMirror Primary on FAS1 snapvault modify -S lab-22fas1-vif_lab-14:/vol/vol_cifs_01 lab-22fas2:/vol/svvol_cifs_01/vault01

5. Update the Primary Dataset on FAS1 with new data

6. Update the SnapVault Destination Datasets with any changes on the FAS1 Datasets snapvault update -w lab-22fas2:/vol/svvol_cifs_01/vault01

7. Verified the new data from step 5 is there

8. Check NetApp Management Console for New External Relationship.

9. No External Relationship is shown for: lab-22fas1-vif_lab-14:/vol/vol_cifs_01 lab-22fas2:/vol/svvol_cifs_01/vault01

10. Refresh Controller Details from Operations Manager, checked Management Console and still no External Relationship for the SnapVault relationship.

ASUNDSTROM · ‎2012-09-10

To follow up with this post.....

I checked the svmon.log file on the DFM server and saw that the primary paths were invalid:

Sep 08 01:00:33 [DFMMonitor:DEBUG]: [2484:0x888]: lab-22fas1.test.lab.net(131): Invalid primary path /vol/vol_cifs_01.

I changed the primary paths to:

lab-22fas1-vif_lab-14:/vol/vol_cifs_01/-

lab-22fas1-vif_lab-14:/vol/vol_cifs_01/qtree_cifs_01

After I had run a refresh on the filers through Protection Manager, the SV's showed up under the External Relationships in the Management Console.

My question now is, if the root of the volume is a valid path using snapvault from the command line, as outlined in the Data OnTap Manual Page Reference Volume 1 for version 8.1, then why wouldn't DFM's modules accept the path?

"The primary_path can be a qtree, represented in a similar way; it can refer to the set of non-qtree data on a volume, represented by a path such as /vol/vol3/-; or it can refer to the contents of the entire volume, including all qtrees, by a path such as /vol/vol3."

You shouldn't have to reconfigure your existing SnapVault Relationships to fit them into a Management feature, the feature should allow for what is defined in the existing operating system. Addionally, having to define SnapVault relationships at the QTree level and separately for the Root Level, before importing them into the Management Console, adds managment overhead to what should be minimizing management overhead.