But at Tintri, we’ve been thinking about VM-level capabilities for some time. In fact, we released our first VMstore in 2011, around the same time VMware proposed VVol. From the beginning, we’ve architected specifically for virtual machines and workloads, which now encompass 75 percent of all workloads, up from 2 percent in 2005. The modern data center has evolved to think and act in VMs—and we’re happy to enable it.
So don’t worry—we’ve got our head wrapped around VVol. Let’s break down three things you should consider when it comes to VMware Virtual Volumes:
Conventional storage is managed entirely with LUNs and volumes. If an application performs poorly, there is no way to pinpoint the cause at the VM level—since conventional storage is at the LUN level. This lack of VM-level visibility makes it difficult, if not impossible, to identify the issue and deal with it.
When you layer on VVol, the storage admin can create storage containers (kind of like carving LUNs), assigning each one specific policies (performance, cloning, snapshot frequency, etc.). Then the virtualization admin can select performance characteristics for each VM they provision. VVol plays matchmaker, aligning VMs to appropriate storage container and rebalancing as necessary.
While this puts you on the 10-yard line, Tintri puts you in the end zone. With Tintri, virtualization or storage admins set the exact policies they desire for every individual VM. There’s no need to map them to a container (or a LUN or volume); the VMs are the containers—the most granular available. That’s true VM-aware storage.
That means it’s up to storage vendors to make VVol work for the masses. And that means not all VVol implementations will be equal. In fact, given their architecture, most conventional storage providers will only support the most basic VVol features.
Most storage providers plan to support between 200 and 1,000 VVol. Tintri supports up to 1,000,000. This might sound like overkill—but you need more than you think. To create one VM, you need (at least) three VVol—and for every snapshot that’s (at least) two more. Since data centers routinely take dozens of snapshots for hundreds of VMs, your VVol will add up quickly.
Conventional storage arrays that usually manage relatively smaller numbers of LUNs and volumes may need to rewrite their operating systems to handle this number of "units." That’s just one of the reasons the VVol API demands a storage provider with the right building blocks.
Once virtualization admins select their desired performance characteristics, the VVol API will choose a storage container that best fits the request. But it doesn’t always work out. The assigned container might include a few noisy neighbors—rogue VMs that suck up performance meant for other VMs in the container. So, VVol may reshuffle VMs to different containers with characteristics that are less optimal. As all this happens, you have very limited visibility or control. In other words, no matter what services storage administrators want, VMs with VVol are still at the mercy of LUNs and volumes.
With Tintri, that doesn’t happen. The admin can toggle the exact Quality of Service for each individual VM and there is no shuffling between containers—the VM’s performance is guaranteed.
So are you ready to take the VVol plunge? To start, let’s figure out how many VVol you’ll need. Check out this simple VVol calculator and answer three simple questions to get started.
Unique control with VM-level actions for infrastructure functions including snapshots, replication and QoS make protection and performance certain in production, and accelerate test and development cycles.