Moving Secondary Volumes Managed by Protection Manager

[berks]

Hi Community,

I have filer1 as source and filer2 as destination.  I'm using Protection Manager to mirror the data from filer1 to filer2.

I want to move the volumes from filer2 (filer2 is being decommissioned) to filer3 but keep the existing snapmirror relationships so that I do not have to rebaseline them (I don't want to do a level 0 backup).

How can I move the volumes so that I keep the snapmirror relationships and also keep Protection Manager managing the volumes and relationships.

Thanks

Jeff

[adaikkap]

Currenlty( untill DFM 3.8) this is not possible,Migrate from filer2----->filer3

with out rebaselining the relationship from filer1.

But soon you would be able to do.

We are working on  to automate moving secondary volumes.  If all goes well, it will be in the next release.

Regards

adai

[nagendrk]

This is an interesting situation.. Will it be possible to completely mirror data from filer2 to filer3 and then rename[modify IP] filer3 as filer2?  Will this work?

[tfuchs]

No, it won't work since the new volume will get a new "SID" and Protection Manager will recognize it.

I did a secondary volume migration in another aggreagte the following way:

- Manually VSM the destination volume to the new aggregate

- SM quiesce and break

- Manually resync the SM relationship with the primary controller

- remove the old seconfdary volumes/qtrees from the dataset

- import the manually resynced SM relationships as external relationship into the dataset

- remove old SnapMirror snapshots on primary and secondary

- try a "protect now"

In my case I had SnapVault relationships between the primary and the secondary controller. But it should also work with QSM or VSM.

If you have QSM or VSM Protection Manager is no longer aware of the backup history on the secondary volumes. So you have to delete the old snapshots manually until they are out-of-date. The new snapshots will be managed again from Protection Manager.

Hope this helps

Thorsten

[adaikkap]

But you would loose your backup version, on protection manger even though those snapshots exits on the volume.

As protection manger does not recognize or import older snapshots of a imported relationships as backup versions.

Regards

adai

[tfuchs]

That's what I ment. Thanks Adai for clarifying.

But it is still possible to do the restore with snapmirror commands from the filer cli.

Thorsten

[adaikkap]

Yes.Restore is still possilble from snapshots, using filer cli.

Regards

adai

[smoot]

Thorsten's procedure should work fine.

Every time Protection Manager mirrors the volume from filer1 to filer3, we copy all the backup versions present on the source volume to the destination volume (now on filer3).  When we detect that the volume on filer2 is deleted, we'll also delete all notion of backup versions on that volume.  This works because we know the VSM destination is a carbon copy of the source volume.

This does not work for SnapVault and Qtree SnapMirror destinations, so if you move a backup destination, you need to manually manage the snapshots.  We intend to fix that in an upcoming release.

So, we should retain and delete snapshots and backup versions properly.  If it doesn't work, let us know (prefereably through NGS) and we'll fix it as a bug.

-- Pete

[pascalduk]

Is protection manager really worth all this trouble?

I have been using VSM/QSM/Snapvault for years using the CLI and I am happy with it. But moving to PM seems like giving away control and lost of freedom and will cause a lot of trouble in the short term.

[tfuchs]

PM is good because you have a centralized configuration, monitoring and alerting, which you don't have with cli commands.

But I agree with your question because PM still has a lot of "features" that don't make life easier. One of those is the base question of this thread. Hopefully there will be much improvement in a short time frame. I was in contact with Product Management and there will be some improvement with 4.0 which should come at the end of this year.

Thorsten

[smoot]

Thank you Thorsten, youe $20 is in the mail ;-).

To Pascal's point, yes you give up some amount of control when using ProtMgr versus the CLI.  That's either a bug or a feature, depending on what you value.  We take away some level of fine-grain control, but also relieve you of the necessesity of making fine-grain control decisions at every stage.  That's what automation is all about, make a decision once and we ensure that decision gets applied consistently.

On the other hand, we try to accomodate users who want the fine-grain control as much as we reasonably can.  In order to keep the main workflows simple, we try not to clutter them up with options that most users will not use.  Over time, we get compl^H^H^H^Hfeedback about where people really need to be able to influence what ProtMgr is doing and we try to incorporate that feedback.

<defensive-mode>

Clearly, ProtMgr is not perfect -- no piece of software is.  We spend a huge amount of time each release reacting to situations where if you do operation X and the filer has hiccup Y, bad side effect Z happens.  We also spend huge amounts of time tuning the behavior so that everyone gets what they want.  If we get things wrong, well, that's why I participate in this community, so that we can make it better next release.

</defensive-mode>

[pascalduk]

I have been reading a bit more about PM and I can see the added value, especially for new netapp users.

The main things that I am worried about in my environment, with a few thousand snapvault relationships, are:

* The OM server needs to start every single snapvault transfer instead of the snapvault schedule we currently have on the destination filer. Having the OM server as a single point of failure for my world wide backups does not make me happy. And then I am not even considering  the load on the single server.

What OM should do is set, monitor and manage  the snapvault schedules on snapvault destination volumes.

* No control over the naming conventions for your destination volumes / qtrees and snapshot names is an absolute no go in my environment. Not only for myself, but also my endusers, who can access the snapvault history and restore data themselves, are after 5 years used to it.

If this is fixed, I will definitely seriously consider PM.

And please correct me if am wrong in my quick analysis

[sprakash]

Pascal,

     Can you give more specifics on the kind of control you wish to have over the naming conventions?

Regards,

Prakash.

[pascalduk]

I want to be able to do exactly the same as I can do now with the CLI.

[sprakash]

And what naming conventions do you use for volumes, luns and snapshots?

-Prakash.

[smoot]

Hi Pascal --

No, you have correctly identified two issues with the current product.

Scalability and reliability are concerns which we try to address each release.  We recognize that pushing schedules to ONTAP would improve the situation, but there are some drawbacks we haven't been able to work around (plus, other feature enhancements and bug fixes get proritized higher, so this doesn't make the cut).  We think we have a pretty good reliability story, what with DFM's built-in clustering and DR capabilities, but perhaps that's not enough to make you comfortable.

Regarding naming conventions, yes I understand that too.  Another customer was asking about that yesterday, so I tried a quick experiment.  It turns out you can let Protection Manager create volumes using our naming conventions, then go in an rename the volume from the ONTAP CLI afterwards.  We discover the new name, patch up our tables to match, and everything works fine.  That's not the best answer, but seems like a reasonable workaround until we can implement better automated naming.

As Prakash asked, if you can tell us your naming conventions, we'll keep that in mind when we re-work the code.

-- Pete

[efrietsch_AIS]

I am PM 4.0.1d2 and also have problems with the way a PM names the Volume. I have tried what you suggested by renaming the Volume at the DOT cmd line, and the name gets updated within PM. Everything looks like it is fine, but when I go to protect now on my dataset which contains an OSSV relationship I get the below error. I then have to rebase and recreate my OSSV to get things working again. I like PM but do not like that you can not name a Volume what you want with the secondary migration tool that is now in 4.0 (great migration tool though)

Everything works up until I rename the Volume name at the command line and then it breaks.

Error Messages

FAS1:/ossvtest/ossvtest_ossvdemo_H__: Could not configure ossvdemo as the transfer interface for ossvdemo:H:/: NDMP communication error: NDMP_SVS_MODIFY_RELATIONSHIP: 0x20500306 (SV NO RELATIONSHIP)

[adaikkap]

Can you give the output of the entire job list ?

dfpm job detail <jobid> for the job that threw this error.

Also what is the version of OSSV you are using ?

Was the relationship created using PM or was it imported ?

Regards

adai