Per-VM Data Management

Snapshots

Legacy shared-storage architectures provide snapshots of storage objects, such as LUNs and volumes, rather than VMs. These snapshot technologies lead to inefficient storage utilization, as hundreds of VMs with varying change rates are often snapshotted at once. Snapshot schedules can only be set at a LUN or volume level, leading to such best practice recommendations as creating one LUN per VM as a workaround for the need to create individualized snapshot schedules at a per-VM level.

Unique space-efficient and granular per-VM snapshots allow administrators to create snapshots of individual VMs and quickly recover data or entire VMs from snapshots. Tintri OS supports 128 snapshots per VM for scalable data protection. Data protection management is also simplified with default snapshot schedules that protect every VM automatically, while custom schedules on a per-VM basis can be used to tailor data protection needs for specific VMs.

Note that a system-wide default snapshot schedule does not create interdependencies between each VM’s respective snapshots. Each VM still “owns” its own individual snapshots and the system-default schedule can be overridden on a per-VM basis. Applying VM-specific snapshot settings that differ from the system default schedule is straightforward and painless.

Tintri OS provides crash-consistent and hypervisor-coordinated, VM-consistent snapshots. Crash-consistent snapshots do not take extra measures with the hypervisor or guest VM to coordinate snapshots. Thanks to integration with native hypervisor management tools such as VMware vCenter integration, Tintri OS provides VM-consistent snapshots for simpler application recovery. With VM-consistent snapshots, hypervisor management APIs are invoked to quiesce the application in a VM, for a VM-consistent snapshot.

Clones

Tintri OS leverages per-VM snapshots to allow users to create new VMs through cloning operations. In cloning, the state captured in a given VM snapshot serves as the “parent,”and the new “cloned” VMs can be thought of as “children.” Like actual children, new VMs created via cloning operations exist and function independently from the parent VM(s) from which they are created. Behind the scenes, the new VMs share common vDisk references with their parent VM snapshots to maximize space and performance efficiencies.

The unique, patented  way Tintri uses flash assures that clones are 100% performance efficient. They get the same level of performance as any other VM stored on a Tintri VMstore system.

Initially, new VMs created via cloning do not consume any significant space, since they are virtually identical to their respective parent VMs. The extent to which they individually grow and diverge from the data they share with their respective parents defines their incremental storage space requirements.

Using the Tintri UI, hundreds of clone VMs can be created at a time. Users can select an existing snapshot of a VM, or the live running state to create clone VMs. The clone VMs are automatically registered and visible to hypervisor for immediate use. Administrators can also select customization specifications defined in vCenter for preparing the newly-created clone VMs. Further, clones can also be created from template VMs for use cases such as provisioning, test and development, and virtual desktop infrastructure (VDI).

When cloning VMs from the Tintri VMstore UI, you can create clones from existing snapshots, or use the current state, where Tintri VMstore automatically creates a snapshot when you press the “clone” button.

You can use vCenter customization specifications (Tintri VMstore retrieves them from vCenter), and you can choose a specific vSphere cluster or vHost (ESX/ESXi server) to which you want to register and deploy the VM(s). Tintri VMstore automatically adds cloned VMs to your vCenter inventory for immediate use.

Replication

Unique to Tintri VMstore, ReplicateVM enables administrators to apply protection policies to individual VMs, rather than to arbitrary units of storage such as volumes or LUNs. ReplicateVM efficiently replicates the deduplicated and compressed snapshots of VMs from one Tintri VMstore to another. Replication can be dedicated to specific network interfaces, and optionally throttled to limit the rate of replication when replicating snapshots between Tintri VMstore appliances located in datacenters connected over wide-area networks.

The usefulness of ReplicateVM comes clearly into view when administrators realize the power they can wield by right-clicking on a VM and then quickly and easily establishing a protective snapshot and replication policy on each VM or VMs as needed.

Protection policies are applied to database server VMs running applications like Microsoft SQL Server, Oracle, SAP, and Microsoft Exchange. Distributing “Gold” (master/parent) VM images used to create desktop pools for VMware Horizon View or VM Catalogs for XenDesktop VDI deployments enables multi-site HA for VDI.

Accessing protected VM snapshots on the source or destination Tintri VMstore system is painless, due to seamless vSphere integration. As discussed previously, Tintri VMstore always adds newly cloned VMs to the vCenter inventory you specify, so that they are ready to be powered and into service immediately.

ReplicateVM is particularly powerful when it comes to replicating important, mission-critical data sets and assets essential to the operations of an organization. This includes but is not limited to protecting the core VM and application images used in server and desktop virtualization environments, and replicating the snapshots of those applications and images across multiple systems in geographically-dispersed data centers.

Array Offload

Installed on each vSphere server, the Tintri vStorage APIs for Array Integration (VAAI) plugin ensures that every VM in vCenter can leverage the fast, powerful, and space-efficient cloning capability of Tintri VMstore.

Using the vSphere client, administrators can right-click on a VM, and select “Clone VM” to start the Clone Virtual Machine wizard. The vSphere cloning operation leverages Tintri’s VAAI provider, which then delegates the cloning process to Tintri VMstore.

When vSphere receives a request to clone a VM, it inspects the VM’s datastore and checks to see if the datastore supports hardware acceleration. The Tintri VAAI provider plugin in each vSphere server serves as the intermediary between vSphere and Tintri VMstore. vSphere delegates the cloning operation to Tintri VMstore, and then communicates to vSphere through VAAI that the operation is complete.

Scripting VM cloning operations with PowerShell/PowerCLI or any other method that calls the vSphere APIs also leverages the Tintri VAAI provider, because vSphere interacts with datastores the same way, regardless of whether or not the command arrives from the vSphere client, PowerCLI, via a vSphere API call, etc.

Per-vDisk Auto-Alignment

VM alignment is a daunting to-do item. It is a problem that poses real challenges as virtualization spreads into more mainstream workloads. Misaligned VMs magnify IO requests, consuming extra IOPS on the storage array. At a small scale, the impact is small. However, the impact snowballs as the environment grows, with a single array supporting potentially hundreds of VMs. At this size, performance impact estimates range from 10% to more than 30%.

Every guest OS writes data to disk in logical chunks. Storage arrays also represent data in logical blocks. When a VM is created, the block boundaries on the guest OS and storage don’t always align automatically. If the blocks are not aligned, guest requests span two storage blocks, requiring additional IO.

A VM runs a guest OS that includes one or more virtual disks to store state. The guest OS typically defines the layout of each virtual disk with a common partition layout, such as a master boot record (MBR). The MBR stores information about how each virtual disk is partitioned into smaller regions, with its size and location. Except for Windows Server 2008 and Windows 7, blocks defined by the guest OS file system (NTFS, EXT3, etc.) do not typically align with the underlying datastore block layout.

Administrators attempt to address the misalignment issue by using a variety of utilities to manually align VMs and reduce performance demand. Numerous blogs, white papers, and knowledgebase articles describe why VMs should be aligned, and provide step-by-step instructions. Unfortunately, as administrators know, realigning a VM is a manual process that generally requires downtime.

Trintri’s application-aware file system intrinsically “understands” each virtual disk. Building on this foundation, Tintri VMstore offers VM auto-alignment. Rather than the conventional disruptive approach of realigning each guest, Tintri VMstore dynamically adapts to the guest layout. Nothing changes from the guest OS point of view. Tintri VMstore automatically aligns all VMs as they are migrated, deployed, cloned or created, with zero downtime. A VM administrator can now eliminate this arcane task and enjoy performance gains from 10% to more than 30%, with no VM downtime and zero user interaction.

vDisk and File-Level Restore

Unlike storage-centric snapshot technologies in legacy shared storage systems, Tintri per-VM snapshots make recovery workflows remarkably easy. Files from individual VMs can be recovered without additional management overhead, dramatically reducing the time to recovery.