Per-VM Snapshots from Virsto and Tintri

Posted by Howard Marks
June 11, 2012

As I discussed in "Storage Snapshots in a vSphere World," consolidating the data for multiple virtual machines (VMs) in a single block-storage LUN has greatly reduced the utility of storage system snapshots. The good news is that Virsto and Tintri have come to our rescue with per-VM snapshots.

Tintri's technology comes packaged as a hybrid storage system, though one specifically designed to support virtualization workloads. Virsto sells what it calls a storage hypervisor that installs as a virtual machine in each of your vSphere or Hyper-V hosts. Yet both vendors use similar techniques to provide snapshots that are not just worlds better than the native snapshot providers from Windows and vSphere, but also open up a raft of deployment and use models.

Both vendors implement what is in essence a log-based file system. Incoming data gets written to a log and then despooled to free space on the back-end disk in large chunks. Tintri stores the login flash and evicts data from flash only when the flash is full when it demotes the least-active chunks; you can configure Virsto's software to use shared flash for its log LUN. Since the log holds data that hasn't been written to the main disks, you don't want it trapped in a single server in the event of a server failure.

This demultiplexing function reduces the impact of the I/O blender effect that randomizes I/O from multiple VMs as it reaches the storage system. It gets most of the attention when people talk about Virsto's software.

Since both systems present their storage to vSphere via NFS, they can see the data not just as a series of blocks but also as the VMDKs and other files that make up a VM. They can then take advantage of that knowledge to create very efficient redirect, or, as Virsto calls it, allocate on-write snapshots. Since the log-based file system always writes to free space, rather than overwriting the previous contents of a rewritten block, a file or a snapshot is really the metadata that defines that volume as a chain of data blocks that could be written anywhere in the system.

Once you have snapshots that take up disk space only when they contain different data than the parent volume and have a minimal impact on performance, you can take application-consistent snapshots several times a day and keep them around for a while to let you revert a VM to a previous state quickly. Even better, you can create read/write clones and let your developers access a copy of the production database without using the disk space a duplicate copy would take up or the time to copy the data.

But the best part is you can create what are essentially storage system-based linked clones for your virtual servers. Both vendors' vCenter plugins can clone multiple virtual machines from a template in seconds, as each new VM is just a read-write clone of the master template. Since Virsto supports multiple tiers of storage and clones on a different tier than their parents, you can keep the master image with all its frequently accessed common data on a high-performance flash or 15K-rpm drive tier, and the dev/test clones on lower-cost 7,200-rpm drives.

I'm hoping more vendors jump on the per-VM snapshots bandwagon, and VMware is hinting with vVols that it will provide some guidance on how other vendors can implement them. However, until it does, Tintri and Virsto are high on my list of storage vendors for virtual environments.

Disclaimer: Neither Virsto nor Tintri is a client of DeepStorage LLC.

Related Reading

---