SnapVault update failed after first try

[marcel_juhnke]

Hi,

I noticed that if a SnapVault update is not initially successful (due to intermittent Network Errors for example) the SnapCreator job immediately fails, regardless of how many tries are configured for the SnapVault relationship.

In our exact case it comes out the following way sometimes:

• SC triggers SnapVault update after Snapshot creation
• First update try is not successful (secondary says 'could not read from socket' due to flaky network connection)
• SC job fails because of that
• In the meantime, SnapVault secondary automatically starts a second try to update, which is successful this time.
• SnapVault update runs through without problems now
• But no Snapshot on the Secondary is created afterwards because SC job already failed

Is there a possibility to configure SnapCreator to repeatedly query the snapvault status despite of being unsuccessful at the first try? Can this be added in a future version of SnapCreator?

Thanks

Marcel

[ktenzer · Accepted solution]

Hi Marcel,

Yeah this is working as designed, although I totally agree with you we need to add retires and in-fact that is what we are looking it. The idea we are thinking about is not just do something for snapvault but all ZAPIs we do should have a retry that could be configured. In addition we would like to add separate retries for snapvault and snapmirror. I think now that we are seeing some folks like yourself in field ask for this that the priority will get higher.

If you have any other ideas on how this should be implemented please share them.

workarounds:

1) use protection manager with SC to do vaulting

2) disable snapvault and do it through a post script called from SC

3) use snapvault snapshots which the storage system would vault using built in schedules, SC can create snapvault scheduler compliant snapshot NTAP_SNAPVAULT_SNAPSHOT=Y

Regards,

Keith

Keith

[marcel_juhnke]

Hi Keith,

thanks for your answer. The retry options for all ZAPIs would be very good.

As for the workarounds, we don't necessarily want to use Protection Manager additionally to SnapCreator, but maybe we can look into this.

I think the option to use snapvault snap sched compliant snapshots is also not working, as we are mostly using sdcli snap create commands and the smsql plugin for consistent snapshot creation and as long SC cannot rename those newly created snapshot to snapvault compliant snapshots it's not of much use for us.

Which brings me to the script as POST action. Can I somehow access the name of the just created snapshot (be it the snapshot really created through SC or the external snap which it reads after running SnapManager)?

Thanks
Marcel

[ktenzer]

Hi Marcel,

Yeah if you are scripting best thing to do is use _recent naming convention. SC supports this and so do most SMs (except for SnapManager Oracle). Then you always know name of snapshot. Additionally SC sets snapshot name as an env variable SVNAME_COMBINED=sv_vol-SV_daily_20130620140315 so you could query that in your script too. Again if you are using snapmanager SC has no control over snapshot name.

Let me know if this helps

Keith

[marcel_juhnke]

Hi Keith,

the SVNAME_COMBINED only gives me the snapshot name it would create on the Secondary if I would have enabled this.

2 Questions:

• Does SnapCreator set an env variable for the External Snapshot name it uses for the transfer (if use external snap is enabled). I can see in the logs what snapshot name it uses, but I would want to access this name also via a script.
• Is there a possibility to prevent SnapCreator from creating a Secondary SnapVault snapshot, so it only triggers the update transfer, but the snapshot creation on the secondary will be triggered by snapvault snap sched (which waits for already running transfers to finish before creating the snapshot).

EDIT: For the second one I found a solution: I commented out all secondary snapshot tasks in the backup.xml workflow file, so now it starts the transfer, but doesn't want to create a secondary snapshot after finishing this, so we can use snapvault snap sched on the secondary. Now this works regardless of the SnapCreator job failing if the snapvault transfer is initially not successful, as now in both cases SC is not creating a secondary snap.

Thanks

Marcel

[ktenzer]

Hi Marcel,

SC exposes lots of ENV parameters. The best thing you can do is just run a PRE_APP_QUIESCE_CMD01=printenv > /tmp/sc_env.out, this will tell you everything that is there. I am not sure if there is something for external snapshot but you can try the env parameter USER_SNAP_NAME or check printenv results to see if anything else useful is exported.

As for your second solution that is exactly why in SC 4.0 we made workflows editable by end user so you could customize things as you see fit. Just be aware that workflow changes are global. In the future we plan on allowing customers ability to write scripts and have them be tasks in workflow engine so you could even replace certain tasks in future with your own tasks that have different logic.

Let us know

Keith

[marcel_juhnke]

Looks like we have a winner

SNAME_COMBINED=sqlsnap__hofdbap2002_06-26-2013_13.58.19

As for the workflow being global, that's fine, because we the will have the complete environment in a consistent configuration, so all snapvault snapshot creations go via snapvault snap sched and only transfer is triggered by SnapCreator. So we can keep away from Protection Manager now. Not that I have something against Protection Manager, but it's again an additional tool, where we would want to streamline the environment and retire old custom scripts, now we are one step closer to this.