Best Practices for SnapManager for SQL and SnapDrive 6.3 with VMDKs

[#1]

Hi all,

With the introduction of SnapDrive 6.3 and VMDK support, how does this affect the way Ideploy SQL in virtual environments?

I am familiar with SQL data layout using RDMs and LUNs through the Microsoft ISCSI initiator in the VM but how does this affect SQL data layout using VMDKs? Do I just substitute LUNs for VMDKs on NFS volumes using the same logs/database separation? Is the sizing process the same? Is throughout on a VMDK in a NFS volume the same as a LUN?

Any help in this area would be useful, as we will be deploying more and more of these environments using SnapDrive 6.3 and this would really simplify things.

Thanks,

David Brown Senior Virtualisation and Storage Consultant for EACS Limited - NCDA, NCIE

[thomas_glodde]

That restore scenario makes most of our customers stick to RDMs. Althou it should be possible to clone the datastore holding the vmdks, attatch the disks to the vm and then you could do a storage vmotion. But not every deployment has storage vmotion licensed 😞

[ianaforbes]

Why would a file level snaprestore be much slower? WAFL is just moving pointers around, not copying data.

[peter_lehmann]

try it and you'll see it...

You are right, WAFL is just managing pointers and blocks (over simplified, sorry WAFL Engineers), but in the case of a SFSR (SingleFileSnaprestore) it has to juggle much more pointers and blocks in the background. In a very large volume with lots of files even the SFSR can take quite a while... I personaly did see it running 1 hour and more.

But if you have a volume with just a few files, it is (can be) very fast!

[ianaforbes]

So, maybe the new NetApp tagline should be, "SnapManager products provide fast backups and not so fast restores" :-). If we promise our customers that they should be investing in Snapmanager products because they can backup and more importantly restore their important data in minutes, then this needs to be guaranteed - or else we all have egg on our face.

This is why it's important to accompany best practices with new features(i.e. the vmdk's within NFS datastores). It sounds like you might be saying that to achieve fast restores using SFSR one should place a single database vmdk within a volume. Additional vmdk's within the same volume will slow the restore. The problem lies where you have many databases - which would mean many volumes/datastores to manage. Also, if you're doing SnapMirror you start running up against replication limits (depending on the controller). You could stagger the replications but then you might be breaking your consistency points.