Subscribe

OnCommand SnapManager Integration

I am working with OnCommand 5.0 and have been trying to find out where the integration is between the OnCommand product and SnapManager products.  I know that OnCommand can monitor the replication of the data once the snapshot has been taken, but haven't found a definitive answer on if it can actually initiate the snapshots for say databases using SnapManager for SQL and run the post snapshot database verification.  We are looking for a single pane of glass to monitor all of the SnapManager products we have deployed and also the replication of these snapshots to our DR site.  It isn't a large environment, but having many different areas to monitor is time consuming. 

Thanks,

John

Re: OnCommand SnapManager Integration

I second the notion. There should be full integration for the SnapManager products, otherwise what is the point of a "centralized console"? If anyone knows how to integrate them I'm all ears.

Re: OnCommand SnapManager Integration

You can use Snap Creator to run the SMs centrally. This gives you central scheduling + central monitoring through either SC or OnCommand depending on what you prefer. For recovery you would still need to go to individual SMs but this solves a lot of the problem we are faced today.

Snap Creator has a agent/server architecture and you can centrally from one Snap Creator server schedule your SM jobs through the scAgent.

To do this you would set following parameters:

NTAP_SNAPSHOT_DISABLE=Y

NTAP_SNAPSHOT_NODELETE=Y

This tells SC to not take snapshot or delete snapshots, since we are using SM to do this

PRE_NTAP_CMD01=enter CLI call to run SnapManager, this would be powershell command for SME/SMSQL

This tells SC to run a command, before it does anything which would be SM CLI call through agent

SC_AGENT=myhost:9090

This tells SC which agent to use, each SM host would have an SC agent installed.

On scAgent edit agent.conf and add following:

command: powershell

This gives agent permissions to execute your powershell command

SC also supports a lot of applications the SMs don't but your main integration point for all these things would be OnCommand and Protection Manager. SMs can integrate with PM and so can SC for any app not supported by the SMs. SC provides central schedule and PM provides central data protection. If you use SC to run SM backups you also have option that SC could send alerts to OnCommand this would get data protection and monitoring in one place.

It is a step in the right direction and there is more work being done on this like allowing SC to support external snapshots so that all the SC goodness can be applied to any SM or snapshot provider.

Here is the SC community:

http://communities.netapp.com/community/products_and_solutions/databases_and_enterprise_apps/snapcreator

There are a bunch of videos, etc so you can check out what it looks like and read about it. Download is available on NOW site.

Regards,

Keith

Re: OnCommand SnapManager Integration

So what you are saying is "buy another product and do custom integration"...  Not a good answer.  I know that the roadmap is to have a centralized management console, is OnCommand it?  Don't know if that has been fully flushed out yet.

I have seen presentations on SnapCreator and it seems to be more of a compeditor to the SM products rather than a central management component.  To have it integrate with the SM products, you have to customize it so it doesn't do what it was designed to do, I.E. do the backup itself, but use SM for XXX to create the snapshot.

What is the roadmap?  Can these be brought together or not?  Marketing is saying that they work together, but I have yet to see it.

Thanks,

John

Re: OnCommand SnapManager Integration

Well Snap Creator is available at no additional cost.

I am just providing you an idea of what you could do today to get things to fit together better using SC and SM and OC. That may not be the right approach to solve your particular problems.

SC is not a competitor to SM it is a framework that can stand alone or integrate various NetApp and non NetApp products and allow customers to orchestrate data protection in a way they see fit.

SC was really designed for Service Providers and customers with many different applications or complex data protection solutions that aren't being met by other products. SC is a cross between SM and SnapProtect. It takes a completely different approach than SM and SnapProtect. However the cool thing is SM and SC can integrate with OnCommand meaning every application that exists can be integrated with OnCommand. The only issue that really still remains is SM and SC needs to be managed outside of OC to some extent. SC provides a single plane of glass as a snapshot provider for OC.

As for long-term roadmap I work on Snap Creator so I cannot comment on SM or OnCommand Roadmaps. I can say SC will continue to add support for new applications through plug-ins and features.

You may also want to checkout SnapProtect which is enterprise backup software and can certainly provide a single pane of glass.

There is no way I know from OC to do what you want without scripting something but again SC can provide central management for SM from scheduling perspective and SnapProtect can provide a single pane of glass if you are willing to move away from SM.

Hope this helps

Keith

Re: OnCommand SnapManager Integration

Hi John,

Snap Creator has the ability to run some backup in a completely independent way but it also have integration with Snap Manager Products.

We are using Snap Creator as a backup console to manage all kind of backup, from Oracle (natively because we run on NFS and we like Snap Creator more then Snap Manager for Oracle) to data volumes that don't need special procedure to some software that will need special backup procedure. With Snap Creator and some simple configuration files we're able to quiesce 3 different application server, put 3 oracle dabaseses in backup mode, snapshot all the volume of this application in a consistant way, unquiesce the databases and application servers with just a single commands. At the end the volumes will also be snapmirrored with OnCommand and we're getting warning if local or remote snapshot has any kind of problem.

We're also starting to integrate SME and SMSQL with Snap Creator and will also use it to run SMVI backup (Snap Creator has it's own VMWare backup procedure using VIBE but we have SMVI and we like how we can mount and restore VM from within vcenter).

The only missing thing at this moment is the integration between SM Backup and Oncommand but it's missing from SnapManager itself (it work only with SnapVault and we only use SnapMirror).

So at the end we will have Snap Creator with a graphical gui to schedule/run/monitor backup that we can give also to dba ora sap administrator to run/manage/control their own backup, Application constistant backup using SM products scheduled from SC instead of scheduling them locally on the single server (difficult to manage, if you need to disable the backup of many servers and reenable them after some time) and OnCommand Protection Manager Integration.

Not too bad for a good piece of software that is also free

Re: OnCommand SnapManager Integration

HI,

If you are talking about OnCommand and SnapManager. For now, if you select remote protection in snap manager it creates a physical dataset in OnCommand using which you can transfer the snapshots to secondary.

>> if it can actually initiate the snapshots for say databases using SnapManager for SQL and run the post snapshot database verification

1.  if you schedule these tasks in SnapManager,

2. And schedule the respective dataset backup in OnCommand, then whatever is backed up in the first step would be transferred to secondary in the second step.

Thanks,

  Arun

Re: OnCommand SnapManager Integration

The problem may be you didn't register a "multi" entry on snapmirror.conf...

The relationship names on OnCommand are quite strange: Filer1_Filer2_NUMBER:sourcevol or something like this

You have to put this line in snapmirror.conf

Filer1_Filer2_Number=multi(10.10.10.1,10.10.10.2)

With the ip addresses of your replica interfaces