Storage Array Snapshots with VMware

This post is very timely for me, as I have just had discussions on this topic with both VMware and NetApp. What is the take on the use of VMware’s method to quiesce the filesystem. I have seen some issues with the filesystem flush and database backed apps such as AD, exchange, SQL, etc.

I agree that cold or warm snapshots probably give the best guarantee on consistent snapshots.

As to the difference between hot snapshots and vmware+array snapshots, in practice we’ve seen little difference on recoverability. If anything, virtual machines that have associated VM snapshots give extra problems if you flexclone them and import the cloned VM.

We perform a hot (Netapp) snapshot on all our datastores every hour. We used to “VM snapshot” the VMs before taking the NetApp snapshot, but this impacted performance, and even from time to time locked up a VM. Now we only take Netapp snapshots.

Other than vendor recommendations, does anyone have any direct evidence that VMFS3 filesystems snapshotted are any worse than a power failure?

VMFS2 had significant issues with crash consistancy, but in my experience NTFS on VMFS3 survives fairly well when you pull the plug (or recover the snapshot).

For super-critical financial applications, I am not recommending this, but three snapshots a day in this style has very rarely failed.

Does anybody know if their is a “SnapManager for Virtual Infrastructure” from Dell Equallogic coming out?

Scott,

Great post(s)!

I added my “2 cents” on my blog. It ended up being too much to post in a comment here.

http://vmetc.com/2008/06/07/avoid-hot-vmware-snapshots-when-using-storage-array-snapshots/#more-414

-Rich

The combination of VMsnaps+NetApp snaps has been heavily debated within NetApp the past few months.

Some of us believe we should provide, within SMVI, the option to disable VMsnaps while at the same time and during initiating a NetApp snap have a Warning window pop up,cautioning the user as to the potential ramifications of such practice. Bottom line, let the user decide the value of their data and make the appropriate decision.

Others believe that even if there’s a 1% chance for FS corruption, then we ought to do whatever’s possible to avoid putting customers in this situation which means utilize VMsnaps as part of the process.

For those who are not familiar with the process SMVI follows here’s how it works:

1) Initiate NetApp snapshot request
2) SMVI call to VC over port 443 - https. VC call to lgtosync.sys driver inside the Guest. Quiesce, flush fs buffers
2) VMsnapshot
3) NetApp Snapshot
4) After NetApp snapshot completion, remove VMsnapshot

The whole process takes somewhere between 5-6 secs. Because it’s so quick, there’s barely any I/Os accumulated in the Redo Log so deleting the VMsnap is a rather quick process.

Mind you that there’s SRM integration with SMVI. The NetApp SRA (Site Recovery adapter) will leverage SMVI snapshots and create FlexClones from SMVI snapshots for site recovery testing while replication is still intact and ongoing. Furthermore, the above can occur with FC or iSCSI or a combination of both (i.e FC on Production site and iSCSI on recovery).

Cheers

Great post as always Scott. EMC offers a tool that does this (along with application-integrated replication for Exchange 2003/2007, SQL Server 2005/2008, Oracle 10g/11g).

It’s called Replication Manager. It’s supported VMware for a long time (for customers running apps in VMs), but recently added VMFS integration (for filesytem-flushed datastore level point in time copies and instant restore for datastores or VMs)

For NetApp folks - it’s equivalent to the Snap Manager family (SME, SMS, SM for Sharepoint, SMO), but is a single tool.

Dell/EqualLogic will create a similar tool at some point, as they recently started creating tools that integrate with Exchange (VSS) and SQL Server (VSS/VDI). Only NetApp and EMC have been doing this for a long time.

I’ll be doing a post on this on my blog in a bit with screenshots and a demo, as it seems to be a hot topic.