Briefing Note: Tintri VMstore
Since the advent of VMware and other virtualization products, storage has been an issue. First, the challenge is having to use traditional shared storage devices with hypervisors. Traditional LUNs are too difficult to create, grow, and share, and they suffer from the noisy neighbor problem where the performance of one virtual machine (VM) could negatively impact the performance of another. Identifying the problematic VM within a LUN is almost impossible.
To try to solve that, some in IT use NFS and SMB appliances. They are successfully addressing the sharing problem but they do nothing to address the noisy neighbor issue.
The real challenge with the noisy neighbor is actually the I/O blender. To an NFS or SMB server, all read or write operations look the same. A big database update looks the same as an installation of Windows patches on patch Tuesday. A large database query looks the same as a VDI boot storm. Since all reads and writes are not created equal, what IT needs is the ability to identify I/O operations and make intelligent decisions about them. That is the reason for the development of the Tintri VMstore.
On the surface, the Tintri VMstore looks like any other storage appliance. It’s a single RAID-6 volume of flash storage or a combination of flash and spinning disk. (The all-flash offering is new.) VMstore appears to the hypervisor as an NFS or SMB device. But this is where the similarity to normal ends. While Tintri does support the NFS protocol, for example, it only supports the elements of that protocol necessary for VMware to use Tintri as a datastore. While it does use a single RAID-6 volume, it does not write blocks to that volume in the same haphazard way that typical storage products do.
Tintri monitors each VM for I/O, so it knows which VM is sending which read or write request, effectively removing the I/O blender. It is even able to understand what type of workload each VM has, such as whether it is behaving like an Oracle VM or VDI instance – and then respond appropriately to that type of workload. Tintri also recently added a VM aware Quality of Service (QoS) feature that allows customers to specify a minimum or maximum number of IOPs for each VM. As my colleague George Crump pointed out in a recent article, QoS in a virtualized environment requires an understanding of the VMs in the service levels. Since Tintri already knows which VM each IOP comes from, it allows VMstore to treat each IOP individually. Maximum QoS is always enforced as a ceiling on performance, the minimum QoS value gives the VM a guarantee minimum of performance if the appliance receives more IOPs than it can satisfy within a certain period of time. For example, if a VM asks for more IOPs than its minimum specified value, and the Tintri appliance can satisfy those IOPs, it will do so. However, if there are more IOP requests from all VMs than the appliance can satisfy, it will give that VM and the other VMs that have minimum QoS their IOPS first, then divide the remaining IOPS among the remaining VMs. Understanding the workload also allows the appliance to lay down similar data in larger stripes to make reads easier, and a number of other intelligent decisions that are only possible because they removed the I/O blender from the equation.
To accomplish all this, Tintri VMsStore collects real time statistics on all I/O operations, and it stores this information for historical reporting. This allows customers to see, on a per-VM basis, all I/O operations and whether or not any performance issues were caused by the storage itself, the host, or the network.
Tintri VMstore appears to have a solid answer to the I/O blender issue. The addition of QoS features and an all-flash offering to this already strong product should make a very interesting combination. Finally, the statistics it collects are real time but stores for history should help customers solve many finger-pointing issues between teams.