ONTAP Discussions
ONTAP Discussions
I'm looking for a little clarification regarding SM and SV using PM. I've configured my PM policy as 'Back up' and have added the Protection policy to a number of my datasets...what i'm seeing is that all my replications are snapmirror qsm... I understand that SV uses qsm under the hood but, all the relationships created are SM. I was under the impression that if I use PM policy 'Back up' policy that SV would be used not SM.
- If sv_ontap_pri and sv_ontap_sec are licensed across the filers as required and snapvault.access is set correctly, why was SV not used?
- if SM and SV are licensed, which one wins when secondary storage is provisioned and replications started (it would appear that SM wins)
- should SV not be used as SV is more used for backups than SM?
- is there a way to convert a SM to a SV (will 'snapvault convert' work the other way)?
Any help on the above would be appreciated.
Thanks,
Scott
Solved! See The Solution
The problem was due to scheduled dedupe being enabled in the secondary provisioning policy that was being used in the backup node.
Bug 406552 to add this to our existing FAQ of when is SV and QSM chosen when both are licensed, to the existing FAQ.
Regards
adai
My assumption is that any newly protected data would us SV is this change is made; what happen with the existing SM qsm's?
Could i do a SM quiesce//break...then a 'snapvault update -S ' to resync using the most common snapshot?
My assumption is that any newly protected data would us SV is this change is made;
Yes. your assumptions is correct.
what happen with the existing SM qsm's?
They stay as it is.
Could i do a SM quiesce//break...then a 'snapvault update -S ' to resync using the most common snapshot?
Don’t know if this would work, give it a try.
Regards
adai
Hi Scott --
There are other things we take into account:
o If you select a DR-enabled backup, that's always QSM
o If you create the dataset through SME or SMSQL, we always use SV (SV can restore LUNs without disrupting Windows clustering, but QSM cannot).
o If you have a schedule which updates more frequently than once an hour, we use QSM
We do look at licenses but do not double check the snapmirror.access or snapvault.access options. I think that's the whole list.
Adai is right, if you change the preference option, we don't convert QSM relationships to SV. If you convert that by hand, you'll have to import the resulting SV relationship (because we won't think we own the relationship).
-- Pete
I ran the 'dfm options set pmQSMBackupPreferred=yes' as directed by Adai however, nothing changed in the way that the Backup policy ran...I was still using SM over SV. Looking at the command, it really only specify QSM, not specific to SM or SV. After making the change, I created a new dataset, added a volume and gave it a ‘Back up’ protection policy.... I even went as far as turning snapmirror off.... when conformance ran, I was erroring out because Snapmirror was off. No joy, SV wasn't even mentioned.
Is there anywhere else I need to make a change to get this to start using SV?
Also, I was able to go into priv set diag and use 'snapvault convert' to change the SM qsm to SV qsm but, DFM was not able to recognize the change and I ran into issue updating the SV... so, once i can get SV to work, I’m going to rebaseline.
Thanks for the info fellas.
Hi Scott,
You must make this option
dfm options set pmQSMBackupPreferred=no and not yes to make SV.
Also after converting your relationships from QSM to SV how long did you wait ?
Did the snapvault monitor run to discover the new SV relationship ?
Regards
adai
The DFM option was originally set to 'dfm options set pmQSMBackupPreferred=no'. I assumed that because it was NO and it was not working, that i had to change this to YES.
I had waited about 45minutes to see what was happening with SV's .. and again checked this morning...about 20hrs later. Were can I manually kick off 'snapvault monitor' ??
When I check out the Job status, I'm erroring out at step 'Relationship Create Progress'....Event Descriptions: type=mirror, Error Message=filername Snapmirror is off.
I don't understand why it's trying to use SM...
Thanks Adai!
Ok.Let me give you all the possiblity of how PM decides to create SV/QSM relationships.Based on this check where you are.
To create SV relationship using backup policy dataset (Not DR Backup policy as they always create QSM relationships irrespective of the below items.)
1.The options pmQSMBackupPreferred=no
2.The Source Filer must have sv_ontap_pri license.
3.The Destination fielr must have sv_ontap_sec license.
4.The Schedule should not be more frequent than an hour
F all the above 4 condition are satisfied you dataset with Backup Policy will create SV.
Even if one of them fails and SnapMirror was licensed it will create QSM.
Also check this FAQ.
http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel40/html/faq/index.shtml#_16.1
Now coming to your second question.
you can manually kickoff the monitors by running the below command.
dfm host discover <filer name/id>
Run this command on both source and destination.
BTW what is the version of dfm you are running ?
Regards
adai.
All 4 conditions you mentioned have been met...I've double checked. The schedule running is the default from the 'Back up' policy..I just changed retention periods to meet my Corp. requirements. I would assume that the schedule predefined by NetApp should work without me having to make any chnages.
I'm currently running DFM3.8....I have a change scheduled for Monday night to upgrade to DFM3.8.1.
Can you try to create one more dataset and just send us the dry run results?
Can you also get us the output details of the below command from Primary and Secondary filers ?
# dfm detail 98 | grep -i svPrimaryIsLicensed
svPrimaryIsLicensed Yes
# dfm detail 101 | grep -i svSecondaryIsLicensed
svSecondaryIsLicensed Yes
Regards
adai
A Correction to my last reply...
I did verify that all 4 conditions has been met however; my Primary Data was set 'Local Backup Schedule' to 'Sunday at midnight with daily and hourly' and my Primary data to Backup was set 'Sunday at midnight with daily and hourly'. I've since changed the schedule on both to Sunday at 8:00pm plus daily'.... I’ve created a test dataset, applied this newly changed policy but, I’m still getting Snapmirror relationships.
No clue what else to try...any suggestions?
Thanks.
Hi Scott --
I'm running out of simple ideas. You might need to open a case with NGS to turn on some extra debugging logs.
Grasping at straws here, did you by chance use the "DR Backup" policy instead of "Backup"?
You haven't mentioned what DFM release you're using. By chance, do your storage systems have both the SV primary and secondary licenses? If so, you need the just releases 4.0 code.
Try running the host diagnostic wizard for both your hosts. Verify that SnapVault is enabled and that ProtMgr knows about the licenses.
You can also try creating SV relationships using the old BCO code. Either go to the main "Backup" tab in Operations Manager, or use the "dfbm" ("b" as in "Easter Bunny", not "p" as in "Passover") command. The sequence should be:
dfbm primary host add primary-filer-name
dfbm secondary host add secondary-filer-name
dfbm secondary volume add secondary-volume-name
dfbm primary dir add secondary-volume-name primary-qtree-name
-- Pete
Oh, I forgot to clarify one thing. I'm hoping at least one of the dfbm commands will fail with an explaintory error message. That should help us figure out why you're not getting SV relationships.
Thanks Pete... i'm running 3.8 and have a change scheduled for tonight to upgrade to 3.8.1. OM4.0 is still a while away...i'm waiting for my TGA to give the thumbs up for that upgrade. Though, i may be forced if we can'te resolve this wiht 3.8.1.
I'm in he process of cleaning up the environment...I havea WebEx in a couple hours with Adai...
Thanks.
The problem was due to scheduled dedupe being enabled in the secondary provisioning policy that was being used in the backup node.
Bug 406552 to add this to our existing FAQ of when is SV and QSM chosen when both are licensed, to the existing FAQ.
Regards
adai