ONTAP Discussions

Snapvault for MultiStore vFilers through protection manager Problem

storage_ergo
5,299 Views

We have several MultiStore vFilers which are setup for DR using vfiler DR commands. They are replicating to a DR site at a co-location site. We want to also archive the data that is at DR by using a Protection Policy to backup the DR destination volumes using Snapvault. when I tried to set this up I got errors trying to do that backup that the the volume was read only since it is a DR destination and it could not perform the backup. Is there something that I need to change in the protection policy to get this to work ? I've done this exact scenario with volumes outside of vFilers no problem.

Any ideas ? I think it has to do with the classificatoins of the Nodes within the protection policy but I can't seem to pinpoint it.

12 REPLIES 12

scottgelb
5,263 Views

There is no support for vfiler DR in Operations Manager, but what you are trying is outside of this... hopefully Adai or someone can reply with the reason it fails.. I assume all volumes on the target are using Volume SnapMirror (no qtrees assigned to the vFiler forcing QSM instead?).

storage_ergo
5,264 Views

Correct, Volume SnapMirror

storage_ergo
5,264 Views

So I tried a workaround by creating snapvault relationships to each of the vFiler DR volumes to a new volume on the same controller so that I could import them as external relationships in DFM, but I am not able to see them in DFM as external relationships. Anyone have any other ideas ?

adaikkap
5,264 Views

Are these relationship created using the vfiler interface or pfiler(vfiler0) interface.

If its the earlier one then DFM doesnt discover.

storage_ergo
5,264 Views

The sv relationships I created were from vfiler0, not the vfiler interface.

adaikkap
5,264 Views

Can you run the following command on both the VSM destination filer and the SV destination filer ?

dfm host discover <filer name/Id>

storage_ergo
5,263 Views

Do you mean that I should perform the host discover after doing SV from the command line? We let the external SV relationship run over night (24hours) so I though it would have polled by then and seen it in DFM, but I can definately try a manual discover.

adaikkap
5,264 Views

This is because in your case you would have used the same base snapshot on the VSM destination as the source snapshot for the SV.

But when you do it using normal dataset, DFM(PM) will try to create snapshot on this volume which is readonly.

This can be over come by using Application dataset, where PM doesn't take the snapshot rather it propagates the snapshot that is registered with it.

So you will have to create an app dataset using the API or NMSDK and use the base snap shot of the VSM as the base snapshot for the sv.

PM will take care of creating snapshot on the snapvault destination.

storage_ergo
5,264 Views

Thank you for the reply.

Can you expand on the following "create an app dataset using the API or NMSDK and use the base snap shot of the VSM as the base snapshot for the sv" ?

Is this something that is to be scripted outside of DFM ? or is it part of DFM? Or is it a different dataset type? We have only configured our dataset's to contain aggregates, but I am interested in the app dataset, as it might solve the problem for us.

adaikkap
4,660 Views

>Is this something that is to be scripted outside of DFM ? or is it part of DFM?

its part of DFM.

>is it a different dataset type

Yes.The ones in bold makes the difference.

[root@oncommand ]# dfpm dataset list -x app_dataset

Id:                              433

Name:                            app_dataset

Policy:                          Back up

Description:                     test dataset

Owner:                           adai

Contact:                         adai

Volume Qtree Name Prefix:

DR Capable:                      No

Application:                     SDU

Version:                         3.2

Server:                          red hat

Requires Non Disruptive Restore: No

Node details:

   Node Name:           Primary data

   Resource Pools:

   Provisioning Policy:

   Time Zone:

   DR Capable:          No

   vFiler:

   Node Name:           Backup

   Resource Pools:      RP3, RP4

   Provisioning Policy: Dedup-Secondary Provision

   Time Zone:

   DR Capable:          No

   vFiler:

[root@oncommand ]# dfpm dataset list -x ossv_dataset

Id:                              415

Name:                            ossv_dataset

Policy:                          Vaulting of OSSV

Description:

Owner:

Contact:

Volume Qtree Name Prefix:

DR Capable:                      No

Requires Non Disruptive Restore: No

Node details:

   Node Name:           Primary data

   Resource Pools:

   Provisioning Policy:

   Time Zone:

   DR Capable:          No

   vFiler:

   Node Name:           Backup

   Resource Pools:      RP3

   Provisioning Policy:

   Time Zone:

   DR Capable:          No

   vFiler:

[root@oncommand ]#

Btw were you able to discover the relationships created outside in the external relationship tab ?

Regards

adai

chaillotn
4,660 Views

Hello Adai,

We have a similar issue in our environment (attempting snapvault managed by OnCommand 5.0.1, on CLI-made vfiler DR destinations volumes)

We were able to achieve the first part of your solution ("you will have to create an app dataset using the API or NMSDK"), by modifying the sample "dataset.pl" in the NMSDK code with following info:


my $member_application =
      NaElement->new("application-info");
   $member_application->child_add_string( "application-name", "MySnapvault" );
   $member_application->child_add_string( "application-server-name",   "MyServer" );
   $member_application->child_add_string( "application-version", "1.0.0" );
   $member_application->child_add_string( "is-application-responsible-for-primary-backup", "true");
  
   my $datasetcreate = NaElement->new("dataset-create");
   $datasetcreate->child_add_string( "dataset-name", $dfmval);
   $datasetcreate->child_add_string( "provisioning-policy-name-or-id", $provname);
   $datasetcreate->child_add_string( "is-application-data", "true");

$datasetcreate->child_add($member_application);
$output = $server->invoke_elem( $datasetcreate );
   

But we don't have any idea of how to achieve the second step, and manage PM (in fact OnCommand 5.0.1 in our case) to "use the base snap shot of the VSM as the base snapshot for the sv."

Can you give us a hint on this part?

Thank you for your help,

Regards,

Nicolas

amirm
4,656 Views

Hi Nicolas,

In order to modify the base snapshots used by the SV you can use the API "snapvault-secondary-initiate-incremental-transfer". It has a parameter "primary-snapshot" wherein you can specify the snapshot that you would like SV to use. Perl code for the same may look like:

my $api = new NaElement('snapvault-secondary-initiate-incremental-transfer');

$api->child_add_string('primary-snapshot','NEW_BASE');

$api->child_add_string('secondary-path','/vol/sv_test_backup/qtree1');

my $xo = $s->invoke_elem($api);

I tried this by:

1. Created a SV relationship.

2. Created a new snapshot "NEW_BASE" on the primary manually ( equivalent to the base snapshot of the VSM you have) using "snap create" CLI.

3. Using above API initiated incremental transfer and provided primary-snapshot value as "NEW_BASE" i.e. the snapshot created manually in step#2.

4. For now on all SV updates will be with respect to this NEW_BASE that you provided.

For details on how to use these & other APIs and generate code automatically checkout enhanced ZExplorer Developer Interface(ZEDI) in latest NMSDK 5.0 under <NMSDK_INTALL_PATH>\zedi\zexplore.exe. For demo on ZEDI and more info please see.

Hope this helps.

Regards.

-Amir

Public