VSC 6.2P2 without SnapCenter - what do I lose?

[jgebhart2]

I'm in the middle of a VSC 6.2P2 implementation and I can't find anything that clearly defines what I gain by using SnapCenter.

Some of the documents indicate that without SnapCenter, I can't bring a VM online in another data center even if I have configured SnapMirror/SnapVault without SnapCenter. Is this accurate?

Assuming I don't care about the centralized management or the application integration, what does SnapCenter do for me and why would I use it with VSC?

[spinks]

Integrating VSC Backup and Recovery with SnapCenter offers several benefits.

One of the biggest advantages is increased scalability.  By integrating with SnapCenter you are using the SnapCenter repository (database) instead of using XML files.  This allows for an increase in performace and scability.

Since you are using the database you are also able to now use and reuse backup policies.  This means that if you need a daily, weekly, and monthly backup of your VMs you no longer have to create three backup jobs.  You can instead create three backup policies (one policy with a daily schedule, one with a weekly, and one with a monthly).  Then in your backup job you can select one of more of the backup policies.  Since the policies are stored in the SnapCenter repository you can reuse them for any backup job and with any vCenter that is conected to that SnapCenter environment.  You can also attach and detach virtual disks through VSC.

Also since the SnapCenter repository essentially contains a catalog of all og the backups, this enables additional features such as the capability to restore from a SnapVault Secondary.

When performing a restore operation there is a location dropdown box and if you have a secondary relationship you can select it from the dropdown.

Through the SnapCenter interface today you would be able to see the backup policies and backup jobs, but you will not be able to modify them as this should be done through VSC.

However in the SnapCenter monitor you can see the status of the backup jobs (success, warning, failure) and from the logs are you can review the logs.

So this is a form of centralized logging and monitoring.

Even though you mentioned you aren't interested, from the database perspective, if you were running Oracle or SQL on VMDKs or RDM LUNs, the integration with SnapCenter would allow for seamless backup, cloning, and restore of databases.  Once you connect VSC and SnapCenter there is no difference in the workflows regarless of if your databases are on FC, iSCSI, NFS, VMDK, or RDM LUNs - it all works the same.

I'm sure I missed a few benefits, but these are some of the top of mind items for VSC and SnapCenter integration.

Hope this helps,

John

[ramanps]

A couple of other features available only with SnapCenter integration:

- Ability to mount only specific datastores from a backup. VSC always used to mount all datastores in backup during a mount workflow

- Better handling of spanned datastores. Ability to always exclude or include spanning datastore during backup.

- John referred to reusability of policies. But it also now allows you to have multiple schedules for same backup job by attaching multiple policies. So, if you want both daily and hourly backups for a datastore, you need to have only one backup job. VSC without snapcenter would have required two. In general, we expect the number of backup jobs to reduce by reusing policies.

[nicholsongc]

Hopefully I can jump in here and get some usable feedback.  I have integrated VSC 6.2.1P1D1 with Snapenter 2.0.  Backups work great... it's the mounting part that's falling down.

I do have a case open but after a few days of little/no response and TSE shuffling I thought I'd go to the Community.

My challenge:

Backups SEEM to run fine.  I get a snapshot with the appropriate name based on Job Name.  However, when I go to MOUNT the backup in vSphere I only see ONE of the five LUNs available to present to my ESX host.

Rewind to before I introduced SnapCenter and this was all possible.... right-click/mount/good to go.

Background... we have 5 LUNs in a volume that are presented to ESX as 5 datastores... blah blah blah.  They are all required to be added to the VM and imported as a spanned volume/disk in Windows 2012.  it works.  Not the best architecture I'll agree.  And I can manually SIS clone, map, add to ESX and get my data restored but I was hoping VSC with the help of SC 2.0 could make it a little less tedious.  When I have ONLY VSC in the mix (SnapCenter out of the picture) I can ALMOST do this.  it was fine with FOUR LUNs.... seemed to break with 5 but thats a different topic of discussion.

So the fact that I only see 1 of my 5 LUNs is the basic problem here now that I have SnapCenter integrated with VSC 6.2.1.

Any insight here is appreciated, of course.  Thank you for entertainng my rambling post!

[NetApp_SEAL]

Whoa, Deja Vu 🙂

As long as you're not levergaging SRM, you can still user Version Flexible SnapMirror as Mirror / Vault and maintain recoverability in the same manner as we would before - mounting a snapshot up on a remote vCenter environment, SnapMirroring it back (if feasible), or whatever worked best previously. 

SnapCenter affords you the ability to have something journal / index the snapshots for you, like with using AUX Mirror / AUX Vault copies within SNapProtect / Commvault. 

What I discovered, though - and I had two instances where I specificallly just wanted to stand up SnapCenter to integrate with the VSC so that I could have a few Backup Policies eliminate multiple, redundant backup jobs - is that if that's the sole pourpse of wanting it, it's just not worth it right now.

It's great to see, no doubt, but the effort that has to go into maintaining SnapCenter and it's finiky little relationship with the VSC at the present time just causes more headaches, especially when you see what it can do with other datasets, and then you're just like, "UGGGHHHHH!!!!! I want true SnapCenter / VSC / vCenter integration now!!!" 

The other major thing I'm seeing people struggle with (and when I say "struggle", I mean in the sense of having to change how they used to do something for the sake of SnapCenter, etc...) is the whole "SnapCenter requires SVM-level integration to work" and while I'm all about configuring individual SVMs within the VSC, there's the other side of that coin with the "VSC just won't back up and go tango-uniform if it doesn't have a cluster to talk to" bit.

So yeah, quite the conundrum, but I'm holding out for added functionality sooner rather than later, and that SnapCenter doesn't just die on the vine. 

I mean, all  they have to do is take SnapProtect, pull out the parts that mattered (and worked), craft them into SnapCenter, and voila!