We have been using Snapmanager for SQL with RDM's integrated with OnCommand to vault backups to our remote site. We are standing up a new SQL server and I'd like to use strictly VMDK files instead of RDM, but I'm not finding much documentation to assist with this. Can anyone help? I'd like for it to be vaulted to a remote site and and integration with OnCommand. Is this possible? The SM doc refers to needing to install VSC, but it is not clear on why and if I can still integrate with OnCommand or not.
VSC is used to create the VMDKs. When you install SnapDrive and VSC, they each ask for information to be able to connect to each other. When VSC creates the VMDK, it is represented in SnapDrive automatically, so, all you have to do is run the SMSQL config tool to set up the SnapInfo for where the database and logs are located, or, being migrated to.
Yes, there is an OnCommand (aka Protection Manager) integration for SnapVault (set up during SDW install)
See the SMSQL Installation and Administration Guide on the NOW site for full details on these items.
Thanks for the information. I have installed VSC and configured Snapdrive to work with it, so I'm one step closer. I have been combing through the snapmanager for sql guide today and it is just so sketchy on working with vmdk's, I'm still a little stuck. Let me explain what we normally do and please tell me if it is possible as well as any documents if you are aware of them.
Normally, we place the VM on iSCSI, and attach RDMs. We use SnapManager integrated with OnCommand. SM, performs the backup, then initiates a protection job with Protection Manager to vault the database to our DR site. Reading through the SM install doc, I found this statement on Pg 190.
• The SnapVault integration is not supported for VMDK disks.
Yikes! I forgot about the VMDK PM support (or lack thereof).
I will check with engineering to see when and if this is going to be supported and report back to you.
I have set up VMDKs using NFS to connect the ESX server to the NetApp controller.
You can create separate VMDKs for database, logs, and SnapInfo. Depending on your level of comfort, these can be in the same volume or separate volumes or even separate aggregates (remember, on restore you can backup the ldf before doing the restore if you still have it). I believe we are using (or, soon to use) LUN clone split method of restoring VMDKs, so the restore can be really fast aka Vol SnapRestore. Even if single file snaprestore is use, it is still pretty fast when you have multiple VMDKs in the same volume.
The same happened with us and we are constantly in touch with engineer to see if it is supported, but it's still not.
We were using NFS for datastores. We know at the time of deployment of SnapManager for SQL did not support VMDKs and were told it was "coming soon". Using RDMs via iSCSI at the VMware level was fine than, but when I started to dig into our SRM deployment and realized how much of a benefit this would be if we could use VMDKs when it came to failing over.
Will update you if I hear any thing soon, fingers crossed and hope for the best
Yes, SRM and just wanting to get away from RDMs was my motivation. We use NFS datastores, but for cases like this, I have to use an iSCSI datastore so that I can make use of RDMs. Not ideal, but I guess for now, I'll keep using staying the currrent path. Thanks