TINTRI VMSTORE Zero Management Storage DECEMBER 2013

TECHNOLOGY VALIDATION.

Storage challenges in the virtual infrastructure are tremendous. Virtualization consolidates more IO than ever before, and then obscures the sources of that IO so that end-to-end visibility and understanding become next to impossible. As the storage practitioner labors on with business-as-usual, deploying yet more storage and fighting fires attempting to keep up with demands, the business is losing the battle around trying to do more with less.

The problem is that inserting the virtual infrastructure in the middle of the application-to-storage connection, and then massively expanding the virtual infrastructure, introduces a tremendous amount of complexity. A seemingly endless stream of storage vendors are circling this problem today with an apparent answer – storage systems that deliver more performance. But more “bang for the buck” is too often just an attempt to cover up the lack of an answer for complexity-induced management inefficiency – ranging across activities like provisioning, peering into utilization, troubleshooting performance problems, and planning for the future.

With an answer to this problem, one vendor has been sailing to wide spread adoption, and leaving a number of fundamentally changed enterprises in their wake. That vendor is Tintri, and they’ve focused on changing the way storage is integrated and used, instead of just tweaking storage performance. Tintri integrates more deeply with the virtual infrastructure than any other product we’ve seen, and creates distinct advantages in both storage capabilities and on-going management.

Taneja Group recently had the opportunity to put Tintri’s VMstore array through a hands-on exercise, to see for ourselves whether there’s mileage to be had from a virtualization-specific storage solution. Without doubt, there is clear merit to Tintri’s approach. A virtualization specific storage system can reinvent a broad range of storage management interactions – by being VM-aware – and fundamentally alter the complexity of the virtual infrastructure for the better. In our view, these changes stand to have massive impact on the TCO of virtualization initiatives (some of which are identified in the table of highlights below) but the story doesn’t end there. At the same time they’ve fundamentally changed management, Tintri has also innovated around storage technology that enables Tintri VMstore to serve up storage beneath even the most extreme virtual infrastructures.

On the technology front, Tintri sports a flash-first architecture that deduplicates and compresses data stored on solid-state storage to make it go further, alongside a sophisticated QoS approach that couples intelligent insight into per-VM IO patterns with algorithms that guarantee fair-service even among a multitude of VMs and the most contentious IO. Meanwhile, Tintri is uniquely VM-aware, and can apply these technologies in the right time and place by understanding things like where metadata should be stored for maximum performance and capacity efficiency.

But Tintri is more than just either one of these single management or technology dimensions of innovation. The innovations in these two areas are inseparably intertwined with Tintri, and that’s what makes the difference. In essence, with an architecture that guarantees VM performance, Tintri reduces storage interaction to the point that it almost disappears, and every storage operation suddenly becomes just a VM operation – you no longer manage a data store, just VMs. And those VMs

Technology Validation are now wrapped with serious storage capability. vSphere storage operations may look to have full utility, but in reality they come with a long list of serious limitations – including performance penalties, and limitations like requiring snapshot consolidation during any clone event. With Tintri VMstore, those operations become seamlessly integrated with the hardware power of an accelerated storage array, and make possible more efficient, higher speed storage features that can radically reduce space consumption and the time and effort associated with storage tasks.

Arguably, this is the way it should be. In a VM-centric world, storage provisioning automatically happens, and the VM becomes the building block. Since the storage system is no longer a distinct entity that must be managed, this allows Tintri to function as a virtual infrastructure building block with almost no overhead, no matter how many Tintri VMstore arrays are involved. On top of this, emerging technologies like Tintri’s Global Center are poised to reshape Tintri management at scale into an even greater advantage. While we did not specifically review it here, Global Center is Tintri’s new solution and architecture for managing many Tintri systems (up to 32 VMstores per Global Center in the first version) while preserving all of the VM level insight and analytics that were responsible for the clearly differentiated Tintri management capabilities in this exercise.

The Tintri VMstore is as close to truly zero management storage as we have ever seen. More importantly, as we’ll discuss in this report, the impacts are significant enough that we think every business should be considering what Tintri and virtualization-specific storage can do for TCO.

Highlights from Validating Tintri VMstore

Performance: Observed mixed 6X better than typical Delivering 60,000 to 75,000 IOPS per 3U R/W Performance per VMstore mid-range storage building block, Tintri’s flash-first architecture systems with SSD. delivers superior performance density over typical performance-accelerated traditional storage systems, even when they sport mixed SSD/HDD configurations.

Capacity Advantage 6X or better capacity At 4.5TB usable storage per rack unit, Tintri than typical mid-range sets a high bar for storage density behind storage of similar the virtual infrastructure. (And a new T650 performance increases this to 8.4TB usable per U)

Routine Management Time and 52X advantage Tintri, even at scale, can reduce annual time Effort at Scale – hypothetical spent on deployment and provisioning to estimation of 8,000 VMs minutes, versus weeks for storage made up of traditional arrays.

Estimated time to troubleshoot Minutes versus days VM IO intelligence and end-to-end path typical virtual infrastructure insight allows administrators to drill down performance problems into individual workload demands and utilization, and immediately pinpoint problems, even if they are in the hypervisor or network.

Our estimated annual 60X reduction In-depth, end-to-end virtual infrastructure management time and effort visibility and consistent ease of use vastly impact from Tintri storage simplify virtual storage administration, yielding a distinctly different management approach versus traditional storage Table 1: Highlights from our hands-on testing of Tintri’s VMstore touching on both core storage capabilities in the virtual infrastructure, and management efficiencies. Copyright The TANEJA Group, Inc. 2011. All Rights Reserved. 2 of 24 87 Elm Street, Suite 900 Hopkinton, MA 01748 T: 508.435.2556 F: 508.435.2557 www.tanejagroup.com

Technology Validation

THE VIRTUAL STORAGE CHALLENGE – IT’S (MOSTLY) ABOUT MANAGEMENT We’ve been on a multi-decade firefight to address performance and basic storage capabilities – things like ensuring sufficient performance and availability, protecting data in place, and scaling storage capacity. But today, when these capabilities are acceptably delivered by a storage system, it readily becomes apparent the industry is still neglecting a key dimension – storage management. Worse yet, storage management is an enormous challenge that makes these other more fundamental storage capabilities look simple. Storage management ranges from the seemingly straightforward – storage array deployment – to more daunting tasks like managing performance demands or troubleshooting storage fabric problems. And it is that complexity that is largely responsible for vendors ignoring storage management, or relegating it to massive management frameworks that are more complex than the problems they are meant to address.

Moreover, the challenge of storage management is exacerbated by several characteristics of the virtual infrastructure.

- Rapid, easy provisioning means that workloads often come and go, changing storage demands, connections, and interactions.

- Mobility means that workloads may shift from place to place, moving dependencies and changing storage-to-application relationships and making insight and reporting difficult, if not almost impossible.

- The virtual infrastructure obscures storage interactions and dependencies by injecting a layer of abstraction – the VMFS datastore – that obscures the relationships and interactions between the workload and the storage system.

All of these factors work together to create a complex web of storage connectivity, interactions, and dependencies. This can make virtual infrastructure storage management exceedingly Storage challenges - centering on burdensome. In the face of this management - often disrupt burden, organizations often planned savings become far less agile and capable than they imagined they would be OpEx Savings when stepping into the realm of Total Cost of Ownership virtualization. Worse yet, the Cost management requirements cut into anticipated virtual infrastructure cost savings (Figure 1). Today, CapEx Savings when mid-range storage runs in the neighborhood of $3 to $5 a gigabyte at street prices, storage Scale management at scale can easily add another $5 to $10 per gigabyte on Figure 1: As businesses scale their virtual infrastructures, out of control an annual basis, and this can dwarf storage management challenges often undercut the planned savings the up front costs of buying and from server virtualization initiatives. Only the innovative manage to licensing the storage system. remediate the challenges and restore to an efficient infrastructure. Storage management is a problem that demands a solution.

Tintri, a storage vendor based out of Mountain View, California, knows this, and has said that the job is so unique within the virtual infrastructure that it takes a virtualization-specific storage solution. By

Technology Validation focusing on virtualization-specific storage, Tintri has been able to innovate in several dimensions in order to attack these virtual infrastructure storage challenges.

With this in mind, Taneja Group engaged in hands-on testing of a Tintri VMstore in September of 2013, using a Tintri online partner test facility located in Santa Clara, CA. We set out with the goal of evaluating how much impact the Tintri approach to virtual storage had on the challenge of virtual storage management; but of course, we also touched on the innovative technologies behind the act of storing bits and bytes on a Tintri VMstore.

Next, let’s take a brief look at a few of these Tintri innovations. FOCUS ON TINTRI VMSTORE The Tintri VMstore T540 we evaluated during this exercise is a 3 rack unit, fully redundant, 13.5TB useable capacity, NFS-connected, hybrid storage system that is fully VAAI-enabled and uniquely integrated with the virtual infrastructure. Internally, the T540 system contains 8 high capacity drives, and 8 high performance SSD drives that are seamlessly blended together in an auto-tiered flash-first architecture to deliver tremendous performance from an extremely dense footprint. Moreover, it is solely dedicated to the task of storage behind the virtual infrastructure, and leverages a number of integrations and optimizations to enhance both storage and the efficiency of the virtual infrastructure.

Tintri designed their hardware platform around underlying solid state storage that can enhance VMstore performance to extremes. Tintri has put SSD to work in a flash-first architecture that improves how fully SSD is utilized, but also enhances SSD performance through unique read/write algorithms and solid state tier deduplication and compression. Tintri then couples their software architecture to this hardware platform to deliver a solution that goes well beyond the performance and storage capabilities that hardware alone can deliver.

More specifically, Tintri VMstore is optimized storage that is stripped of unnecessary protocols, file systems, or abstraction layers. As virtualization-specific storage, Tintri has simplified the task of configuring and presenting storage to the virtual infrastructure by eliminating the visibility of disk constructs, volume sizes, RAID levels, and other storage mechanics, and presents a streamlined storage interface to solely the virtual infrastructure. But it takes more than simplification to do this in a way that delivers performance and scalability. Tintri has also been attentive to investing in a uniquely intelligent IO stack – a VM-intelligent IO stack.

By uniquely integrating Tintri VMstore with the VMware virtual infrastructure, Tintri is able to identify VM storage objects, and then profile and understand the demands of those objects on a per- VM basis. Tintri VMstore then uses SSD in a flash-first storage architecture that ensures maximum performance is delivered from flash, while using VM-intelligence to isolate only truly cold and irrelevant data for demotion out of cache when necessary.

Meanwhile, Tintri has coupled these capabilities with a sophisticated QoS engine that doesn’t rely on layers of complex policy, but rather uses a patented algorithm to balance out IO across workloads – even under extreme conditions – and make sure that all workloads are treated equitably. Individual workloads have the workload to consume significant performance, but as performance demands approach the limits of the system, the “cost” of IOs becomes higher, effectively putting a cap on the largest consumers, and making it impossible for one single workload to consume too much IO to the detriment of all.

Technology Validation

Figure 2: Tintri’s view of their storage system showing the 8 SSDs and 8 HDDs that make up a single Tintri T540 system.

TESTING TINTRI – A COMPARISON TO TRADITIONAL STORAGE We evaluated Tintri by walking through the setup of a Tintri VMstore, and putting most of the key features to use through a variety of exercises and under a variety of IO loads. We did this to investigate how Tintri’s features empowered the virtual administrator to perform new tasks, or improve the execution of typical storage tasks, while also evaluating how complete and robust Tintri’s capabilities are under real world usage. We’ve structured our recap of our Tintri VMstore evaluation in a logical fashion, and we’ll walk through each of the following areas of assessment:

• Deployment

• Capacity and Performance Efficiency

• Storage Operations

• Storage Management Moreover, with Tintri’s Zero Management storage claim in mind and using the data points we harvested from this hands-on exercise, we had the opportunity to conduct a lightweight comparative evaluation of Tintri’s capabilities in altering the efficiency and management of storage versus traditional storage. We did this using another late generation, typical dual- controller, unified storage array that was also supporting a virtualized infrastructure. In this review, Figure 3: A network diagram of our hosted Tintri lab.

Technology Validation we’ve anonymized the identity of this array, but it is typical of the mid-range, capable of hybrid storage configurations (flash storage in the array used as either caching or as a tier), and able to deliver substantial performance. Although this wasn’t a performance comparison, this competitive array did make use of 60 15K rpm HDDs, and 15 200GB SSDs, while yielding performance and capacity that were similar to a T540 VMstore we used in our testing.

The Tintri environment itself was remotely hosted, on a single host infrastructure as indicated in Table 2, and in Figure 3.

Test Environment Equipment at Start of Test

Equipment Tintri Test Environment Comparison Test Environment Storage System(s) Tintri VMstore T540 Dual Controller Unified Storage Array NFS attached, Flash accelerated FC attached, SSD cached LUN with 60 13.5TB Useable capacity disks, approximately 14TB of useable capacity Server System(s) Dell 720 HP BladeSystem, single G8 blade 12 cores 16 cores 128GB RAM 128GB RAM Networks 10GB Arista Networks Ethernet for BladeSystem Ethernet and FC modules general traffic Brocade FC switch 1GB Ethernet, Dell switch for management traffic Hosts OSs ESXi 5.1 ESXi 5.1 Windows 2008 guests Windows 2008 guests

Table 2: List of equipment used in our hands-on testing, with exception of general (non-iSCSI) network connectivity which is not listed.

Enhancing Storage Deployment and Provisioning We began our testing of Tintri VMstore by deploying the storage system into our infrastructure. Tintri VMstore deployment takes place in a straightforward manner that is intended to enhance and ease the repeated deployment of storage systems. While the VMstore T540 tested here is a single storage system, Tintri deploys in larger infrastructures with a horizontal, scale-out model. Consequently, the process of initially deploying a Tintri VMstore matters for large organizations.

But in this shared-nothing, but building-block, scale-out type approach, Tintri seeks to deliver a massively simplified but well integrated storage infrastructure. Tintri accomplishes this by making the VM the unit of management, and making the storage layer an afterthought. Moving data back and forth between multiple VMstores, including down to the movement of a single VM, is simplified by the use of VMstore to move data, and the tight integration of VMstore with vCenter to automate the virtual infrastructure aspects of machine movement. It is entirely possible to repurpose VMs on the same or different data stores without ever really viewing or worrying about the storage infrastructure. For example, when using two VMstores, replication can be setup between the VMstores on a per-VM basis, and then the destination VMstore can easily clone the VM as a new machine, effectively creating a copy or just moving the machine with a power-off/power-on operation. This can happen irrespective of whether the attached host machines know about each other or use the same vCenter Server.

Technology Validation

In spite of this fluidity across datastores, deployment matters because organizations who grow to large scale are likely to deploy multiple VMstores. With Tintri, capacity and performance are expanded by adding additional VMstores, but the hassle of managing multiple storage systems vanishes. (Note, Tintri has more recently further advanced their capabilities here through the use of Tintri Global Center that can provide simultaneous visibility into as many as 32 Tintri systems.)

TIME AND EFFORT TO CONFIGURE/DEPLOY Our hands-on testing easily verified that the process of deployment a Tintri VMstore is significantly simplified versus traditional storage. Most storage systems on the market need to be deployed, and then aspects of that deployment (configuration elements) are often constantly revisited as hosts or disks are added or settings need to be changed for better or different performance. Because Tintri does away with most of this revisiting of initial configuration settings, they’ve streamlined deployment as much as possible, and made it possible to deploy a Tintri with a single screen that could just as easily be completed from a remote connection.

Figure 4: Deploying Tintri VMstore required two screens, and the entry of basic network setup information.

Technology Validation

Once we walked through this deployment phase, we had invested less than 2 minutes in deploying a Tintri VMstore system.

In contrast, a more complex mid-range FC shared storage system may require administrators to spend a few hours just in initial system configuration, in order to construct RAID pools, make capacity allocations, initialize volumes, and configure LUN masking. Add in pre-planning, and the time may be greater.

From here, we were able to provision capacity to our virtual infrastructure, and begin utilizing that capacity as a datastore, but most storage administrators logically separate this initial configuration from the act of provisioning, as provisioning may happen over and over again as capacity is gradually doled out from a traditional storage system.

In Table 3, below, we’ve highlighted the comparable time and effort involved in deployment, and we’ve estimated 4 hours for the initial configuration of traditional FC systems, not including the physical racking and connection of the storage system. The reality is that we’ve seen many customers easily exceed this number in initial deployment exercises, and this complexity simply goes away when a storage system such as Tintri is fully dedicated to the virtual infrastructure and is extremely streamlined in deployment.

TIME AND EFFORT TO PROVISION Moreover, the act of provisioning storage beyond this basic deployment step largely goes away with Tintri VMstore. Because Tintri’s VMstore is solely dedicated to the virtual infrastructure, the entire storage system is served up as a single NFS mount point and attached to ESXi hosts. Tintri’s VMstore then auto-manages the performance of the individual virtual machines (a capability we’ll review later), and eliminates the need to manage different pools of storage to meet different business demands. Since Tintri VMstore isn’t shared with non-virtual systems, and since there’s no need to partition different VMs into different storage volumes, there’s no reason to dole capacity out in small slices at a time.

This in turn creates a pretty remarkable difference versus traditional storage. Administrators managing traditional storage systems typically dole out small slices of capacity so they can reserve capacity until systems truly need it. Worse yet, this capacity is doled out from multiple different pools of storage with different protection and/or performance characteristics that have been configured to meet different business requirements. On top of a traditional shared storage system, this makes provisioning more complex, and it means that the act of provisioning storage may happen with greater frequency – potentially every 10 or 20 VMs. Using a single Tintri VMstore as a dedicated, massive datastore significantly reduces the time and effort associated with this repeated provisioning storage.

System Y Tintri Advantage

Time to deploy and configure 4 hours 78 seconds 185X

Time to provision first volume/datastore 2 minutes2 20 seconds 6X

Table 3: Using a comparable, but more traditional unified storage system connected over an FC fabric and supporting shared storage behind both physical and virtual infrastructure, we compared the time and effort involved in initially deploying and then provisioning Tintri VMstore versus this comparable traditional array. Deployment and configuration in particular stands out, and is most impacted by the ease of use of Tintri VMstore’s NFS attachment as well as the infrastructure simplification that comes with fully dedicating a storage system to only the needs of the virtual infrastructure. But as we’ll review later in this document, the simplification in provisioning and the requirement for less total provisioning ultimately adds up to a significant impact too.

Technology Validation

Capacity and Performance Efficiency With this apparent deployment and configuration advantage in mind, we next turned to take a closer look at whether these two systems were really similar or not, in terms of their capacity and performance.

First, we examined capacity, and compared Tintri’s VMstore T540 capacity to this typical traditional storage system we used in the examples above. While Tintri has since come up with a denser system (the VMstore T650), we used the specifications from the tested VMstore T540. Tintri boasts a 13.5TB of useable capacity in the VMstore T540, which is a fairly notable accomplishment for a system with only 16 devices (half of which are SSD) that consumes only 3U of rack space. In comparison, the traditional system we compared VMstore against provided 14TB of useable capacity when configured to deliver similar performance to the Tintri VMstore. But, the traditional system also required significantly greater rack space for this capacity – coming in at 18U of rack space total. This in turn gave the Tintri VMstore a 6X capacity advantage. (Both systems were available at the time of testing for approximately the same street prices, so we have not assessed $/capacity.)

System Y Tintri

Useable Capacity 14TB 13.5TB

Controllers 3U 3U

SAS, 60 drives, in 4 shelves 12U N/A, in controller

SSD, 15 drives in 1 shelf 3U N/A, in controller

Total 18U 3U

Capacity Advantage 6X

Table 4: Comparing the physical footprint of a Tintri system and a current unified storage system clearly pointed out the capacity advantage with Tintri storage – 6X the capacity per unit of physical footprint. *Note, Taneja Group is referencing a currently on-hand, upper-end mid-range unified storage array using 3.5” 15K SAS and SSD disks, a performance-oriented configuration of disks, and our prior testing of the limits of this array. With this capacity advantage in mind, we turned to examining Tintri’s performance architecture, and whether a Tintri VMstore is able to deliver similar are better performance than this traditional storage architecture.

TINTRI VMSTORE PERFORMANCE As we’ve discussed, there are several elements in Tintri’s storage performance recipe that allow Tintri VMstore to deliver serious performance from just 3U of rack space. This includes Tintri’s “FlashFirst” architecture, flash deduplication and compression, and VM-intelligence to proactively tier to flash and ensure only cold data, such as snapshots, is destaged to slower rotational disks. Tintri claims this delivers a highly performant flash layer that is superior to that of general storage vendors using less intelligent auto-tiering approaches, especially when it comes to the virtual infrastructure.

We assessed Tintri’s performance by running a variety of tools, including a Tintri packaged VM using the Unix dperf command (labeled “tingle” VM in various screenshots). As expected, the system was highly responsive and delivered 100% of data for this workload from flash. Tintri reports clearly identify how much of IO is coming from flash.

Technology Validation

Figure 5: Tintri makes it easy to see overall performance, and view how well cache is addressing the demands of currently running workloads. During our testing, we never saw the cache hit ratio drop below 100%.

As we further tested this Tintri VMstore, we were able to hit a 60,000 IOPS performance from an assortment of workloads that created approximately a 75% random read to 25% random write IO mix at approximately a 4K IO size. This was in alignment with Tintri’s advertised performance levels that suggest customers should expect between 60,000 to 75,000 IOPS from a VMstore for typical workloads.

Technology Validation

Figure 6: Tintri makes it easy to see overall performance, and view how well cache is addressing the demands of currently running workloads. During our testing, we never saw the cache hit ratio drop below 100%. While we did not perform head-to-head competitive testing with this exercise, running a mixed load of real world exercises, we did have a prior performance characterization of the comparable traditional storage system we have referenced previously. That system’s hybrid SSD/HDD performance falls in the range of 45,000 to 65,000 IOPS (varying significantly depending on underlying disk configuration), putting its performance capabilities in the same neighborhood as the Tintri VMstore T540. Given the similar performance levels, and different physical footprints, Tintri VMstore once again demonstrated a similar performance density advantage of approximately 6X.

System Y Tintri T540

Useable Capacity 14TB 13.5TB

Physical Footprint 18U 3U 45,000 – 65,000 60,000 – 75,000 Performance Range (IOPS) (Similar to VMstore T540) (Similar to System Y) Performance Density Advantage 6X

Table 5: Based on their similar capacity footprints and their similar performance ranges, the Tintri system once again delivered a 6X density advantage (this time in performance) versus the more traditional storage system. On the surface, the conclusion that Tintri VMstore has a 6X performance density advantage over this comparable traditional storage system looks clear-cut, but the story is considerably more complex than this surface analysis. The virtual infrastructure is notorious for creating bursty, contentious IO streams that are challenging for typical storage arrays to handle. It is not just the challenge of simultaneous IO, but the fact that simultaneous IO can often happen in uniquely bursty patterns that can far exceed the ability of traditional arrays to handle queuing and caching of IO. Tintri has a couple Copyright The TANEJA Group, Inc. 2011. All Rights Reserved. 11 of 24 87 Elm Street, Suite 900 Hopkinton, MA 01748 T: 508.435.2556 F: 508.435.2557 www.tanejagroup.com

Technology Validation of additional important technologies that address these types of issues and further enhance performance in the virtual infrastructure.

TINTRI VMSTORE VIRTUALIZATION OPTIMIZATION AND FAIR SERVICE To start with, Tintri VM-intelligence helps make the VMstore read/write flash-first architecture more efficient by improving the likelihood that the right data comes out of VMstore main memory cache or off of SSDs. This VM-intelligence applies to VM metadata as well as the predictive caching of data and this increases the likelihood of cache and flash hits on IO reads and writes. Moreover, as many administrators are aware, because guest OS file systems can be formatted on top of vSphere’s VMFS in a way that results in a different than normal start of the first data block on disk, VM’s have historically run the risk of becoming “misaligned” with underlying storage devices. This can increase the number of IOs required for any single data request. Tintri’s VM-intelligence ensures that IOs are automatically aligned with the underlying storage devices, which can result in performance improvements of up to 30% compared to misaligned IOs.

Just as importantly though, Tintri VMstore also provides automatic QoS that ensures each VM is treated equitably and is not deprived of service, even if there’s enormous contentious IO or runaway workloads in the virtual infrastructure. Tintri does this with a QoS engine based on patented algorithms.. These algorithms dynamically control the allocation of IOs to different workloads based on fairness and on how much any single workload is requesting. Runaway requestors limit their own consumption of IO by trying to consume IO in too great of a quantity, thereby reaching gradual limits imposed by the QoS engine. This prevents saturation of the storage system by any single host or VM, unless that host or VM is the sole workload running. In turn, limits are reached gracefully, without denying other workloads, and IO service across all workloads is equitable. We spent a fair amount of time testing this behavior in our lab environment, using multiple copies of the IO workload based on dperf. We gradually scaled the workloads until they reached the point of IO saturation, and then continued to add more workloads and observed how well Tintri VMstore addressed the IO contention.

Figure 7: We cloned dperf workloads and then ran them simultaneously to see how equitably our Tintri T540 would manage the contending IO. All 10 of the workloads were well balanced with similar IOs and latency, less than a millisecond of latency from the storage system (the largest, green share of latency is host latency).

Technology Validation

What we observed from this exercise is that Tintri was able to very gracefully handle the IO load from simultaneous workloads even when any single workload would almost saturate the storage system by itself. Storage Operations Next, we moved on to assessing key Tintri VMstore features and functions, including Tintri SnapVM (snapshots), Tintri CloneVM (cloning), and Tintri ReplicateVM (replication). Each of these features stood out most significantly in their per-VM granularity – each operation could be applied to individual VMs, to groups of VMs, or across the entire datastore. This creates significant capability for Tintri VMstore administrators, with much more flexibility than traditional storage systems that can apply such technologies at only the LUN or volume level.

SNAPVM Tintri provides two different types of snapshots: crash consistent snapshots and VM consistent snapshots that are integrated with vSphere to quiesce the virtual machine before executing the snapshot. The snapshots can be executed directly from the Tintri VMstore management interface. We tested each of these features by executing a snapshot while 10 different VMs were simultaneously executing dperf IO and heavily loading the VMstore. Execution was instantaneous/undetectable for a crash consistent snapshot of a Windows 2012 VM, and took approximately 40 seconds for a VM- consistent snapshot of the same machine. In other words, a VM-consistent snapshot required approximately 40 additional seconds for vSphere to quiesce the virtual machine. More importantly, we observed no visible impact to IO during the execution of the crash-consistent or VM-consistent snapshots, and there was no detectable change in IO after the snapshot.

Figure 8: Virtual administrators can easily execute snapshots with a right click menu that is accessible in many different places within Tintri management interface.

Technology Validation

SnapVM and CloneVM Execution Time

Crash Consistent SnapVM Instant

VM-consistent SnapVM 40 seconds Create 10 clones of a Linux VM, automatically 14 seconds registered and configured in vCenter

Table 6: Tintri snapshots execute rapidly, with most of the latency for VM-consistent snapshots occuring in the hypervisor as vSphere quiesces the guest VM. Scheduled snapshots though are where Tintri’s SnapVM truly gets powerful. Using a storage-system- wide engine, snapshots can be scheduled for individual VMs, groups of VMs, or every VM on the system, while retaining the per-VM granularity (a unique snapshot still exists for each VM even if every VM executes SnapVM simultaneously). By default, a system-wide policy that is initially defined by the administrator applies to all VMs. Setting a protection policy for groups of VMs or individual VMs overrides this system-wide policy.

More importantly, these scheduled snapshots come with a considerable amount of granularity in both the schedule and the retention policy. Since snapshots impose neither a performance penalty nor space overhead, Tintri enables significant retention of snapshots.

Figure 9: Setting up snapshot protection policies can be done by selecting “Protect” from the right click context menu. By default, all VMs are protected with the default system-level policy, but unique schedules can be built on a per-VM basis, or for groups of VMs.

CLONEVM Snapshots of course provide the basis for reuse or rapid deployment of additional VMs, and Tintri accomplishes this with their cloning feature they call CloneVM. Any snapshot can be turned into full VM copies without consuming additional disk space, thereby delivering a type of natural deduplication – 20 VMs could point to a single snapshot of a master image, and these 20 VMs will not utilize additional space until they start writing data to disk. More importantly, CloneVM allows administrators to rapidly create many clones (up to 500 at time, see figure 10 below) and these clones can be fully provisioned into any attached host cluster in any vCenter server, even if the original SnapVM did not originate from that cluster.

Technology Validation

Figure 10: We could immediately turn a snapshot into multiple clones of the original VM in a simple, right-click launched interface. Tintri also allows the configuration of these VMs to be customized at the time of deployment. We employed this cloning functionality at scale to create multiple clones at once. We cloned 10 VMs, and they were fully populated in vSphere within 14 seconds.

Figure 11: Cloning happened in rapid order – powered off clones could be created in mass quantities and were immediately populated within vCenter.

REPLICATEVM SnapVM and CloneVM underpin Tintri’s replication approach, called ReplicateVM. Replication asynchronously moves snapshots between different Tintri VMstore models. Once a replication relationship is setup between VMstores, ReplicateVM is configured on a per-VM basis, typically alongside snapshot schedules. Snapshots are used to synchronize replication, and allow Tintri to efficiently replicate only changed data between snapshots. ReplicateVM furthers reduces data over the WAN by sending the delta changes between snapshots deduplicated and compressed. Once VMs are synchronized between Tintri VMstores, CloneVM can be used on any snapshot to promote it to a fully useable VM on the remote Tintri VMstore, with VMstore automatically registering that VM with

Technology Validation vCenter. Just as with other features, ReplicateVM is easy to setup, with the Tintri management interface validating the connection to the remote system, and then drop down dialogs enabling the replication for any given VM.

Figure 12: Setting up replication is a simple screen, and then replication is driven by scheduled snapshots. Here, the Tingle-1.0.5 VM is set to replicate with the snapshot schedule, and retain snapshots for 12 hours. Visible in the images is the average daily data change for this VM, the network utilization at snapshot intervals, and utilization of remote system snapshot space as aging snapshots are deleted. VM-aware Storage Management To this point in our hands-on testing, we have observed that Tintri VMstore has significant impact in reducing storage costs and management effort in the virtual infrastructure through efficiency, ease of setup, and executional differences in routine storage operations. There is more to the story with Tintri, and we’ll turn next to looking at some of additional and equally important aspects of storage management.

Technology Validation

EXECUTION MAKES A DIFFERENCE If anything, we have not yet done justice to the scope of some of the executional differences in storage operations that are delivered by the Tintri VMstore. The Tintri management interface is heavily injected with contextual information and task enablements – nearly every item in the interface provides additional pop-up information when it is hovered over, and nearly every item is “right-click” enabled with menus that allow the execution of other tasks or deeper drills into underlying data such as latency or per-VM statistics.

Figure 13: It shouldn’t be missed that Tintri also provides significant detail and information depth in many contexts – nearly every data element in the interface is right-click or hover-over enabled in a way that yields additional summarization and a path to diving into further detail.

STORAGE AND VIRTUAL INFRASTRUCTURE INSIGHT First, Tintri’s abundant reports and insight assist administrators in policing the virtual infrastructure around such things as idle or orphaned virtual machines. This isn’t an insignificant capability, as storage capacity is often wasted by undetected idle VMs. Moreover, most storage systems cannot identify idle or orphaned VMs, especially at the individual VM level, and this becomes a challenge for storage and virtual administrators. This is just one example of Tintri reporting and infrastructure insight that can simplify the understanding of resource utilization and help administrators maintain more efficient virtual infrastructures.

Technology Validation

Figure 14: Tintri’s reports provide quick insight into VMs and snapshots, their point of origin, their type, and whether they are currently connected to a vCenter machine, or if they are orphaned.

FULL PATH INSIGHT More distinct than this general visibility, is the impact Tintri stands to have around infrastructure performance-analysis and troubleshooting. Well over 75% of the problems we see arise in the virtual infrastructure center around storage performance, and Tintri VMstore brings a unique solution to the table: the ability to integrate closely enough with the virtual infrastructure that they can see into all parts of the IO path, from the storage system’s response, to the network transmission, to host and guest VM IO handling. These statistics are available throughout the interface, and more importantly, they are aggregated in key spots and provide easy drill-down by clicking through on various metrics.

In contrast, traditional infrastructure can provide very little of this insight, and administrators are all too often forced to turn to multiple tools and systems to characterize the behavior of their virtual infrastructure. Many of those tools are challenging to use and understand – such as the esxtop CLI tool that is often needed to view incremental IO path latency as IOs cross the guest VM, hypervisor, and storage adapter. Worse yet, because the resulting information in a traditional storage infrastructure comes from multiple tools, it may be next to impossible to accurately correlate point in time samples across tools, or to even identify the anomalies that may occur between the limited sample intervals of some of these tools.

Tintri VMstore is a performance management and virtual infrastructure troubleshooting tool on steroids with its full path intelligence and data correlation across many metrics (IO, block sizes, latency, VM type, etc.) at any level (infrastructure-wide, per datastore, per host, or even per-VM). In our estimation, this will do a couple of things for most Tintri customers. First, this can easily reduce the time to resolve the typical incident requiring troubleshooting by a matter of days, improving uptimes and helping customers meet SLAs. Second, Tintri visibility can help administrators eradicate any non-storage bottlenecks and thereby better utilize the full performance potential of their storage systems and improve the overall efficiency of a Tintri VMstore-based virtual infrastructure.

Technology Validation

Figure 15: Three examples of Tintri full path insight information, including “hover-over” pop-ups that provide additional information. Tintri provides full path insight between the VM and the storage system, including hypervisor, network, and storage system latency, even going so far via context menus as to break down the total system latency attributable to a single VM (small box).

FORWARD-LOOKING INSIGHT Moreover, this end-to-end virtual infrastructure intelligence doesn’t stop with just “in-the-moment” depth. Tintri VMstore also provides superb visibility into overall utilization patterns, and how the various demands of VMs come together in the storage layer. Tintri then takes this on-going perspective and provides easy to view dashboard indicators of how much performance and capacity are left in any given Tintri infrastructure, and whether the infrastructure can host additional load.

While this significantly simplifies capacity planning and management, this also addresses a bigger issue in the virtual infrastructure. Given the lack of visibility around traditional storage and the dire consequences that ensue when storage or servers become overloaded, most practitioners far underutilize the capabilities of their infrastructure – we’ve seen many large enterprises where the rule of thumb is to never exceed 50% of the performance or capacity of a system in order to allow workloads to increase and still stay safely within performance thresholds. Tintri looks poised to simplify planning, significantly improve utilization, and do away with the inflexible rules of thumb that create bad practices with traditional storage systems.

Technology Validation

Figure 16: Tintri’s VM and storage system intelligence provide significant visibility into virtual infrastructure patterns and trends. Here this information surfaces on a dashboard that reports on the utilization of total system performance and the forecasted use of capacity based on past trends.

MANAGEMENT AT SCALE As we’ve commented, Tintri brings substantial capability to a business’s virtual infrastructure management, providing unique new data and detailed insights. But Tintri hasn’t stopped there, and has just announced a new set of technology designed to inject the scaling Tintri infrastructure with even more efficiency – Tintri Global Center.

Far too often, virtual infrastructures are planned by and restricted by storage infrastructure. Tintri has long talked about their VMstore technology making storage concerns vanish, and thereby turning the VM into the “quanta” or building block of the virtual infrastructure. More significantly, they’ve also talked about this model working at scale, since VMstore largely makes the task of storage management go away, and additional VMstores can be added to an infrastructure in building block fashion without much additional overhead. But now, Tintri Global Center is one more step down this path.

Global Center aggregates groups of Tintri VMstores – up to 32 VMstores – into a single management interface while preserving much of this deep and forward-looking insight into the storage layer. While we did not test Global Center, it clearly looks able to make utility-like scaling possible for very large customers by eradicating the overhead of managing multiple VMstores individually.

Technology Validation

Figure 17: Tintri Global Center allows organizations to aggregate the management of multiple Tintri VMstore systems, while still maintaining the same depth of analysis and end-to-end, entire infrastructure visibility that a single VMstore provides.

TANEJA GROUP OPINION - THE ZERO MANAGEMENT IMPACT At the end of our exercise with Tintri VMstore, Tintri’s impact on the time and effort of various Tintri VMstore capabilities clearly stood out, but remained largely unquantified. In turn, using the various metrics we collected, we turned our attention to taking a slightly deeper look at the degree to which Tintri’s technologies could impact storage management for businesses that are operating more traditional SAN storage systems. Specifically, we decided to hone in on the tasks of deployment and provisioning, since the metrics here were most easily compared with a traditional storage system, and we believe that the findings here may be a decent proxy for what type of overall savings a business might experience across all of the virtual infrastructure portion of their storage operations.

There were a number of assumptions that we made in assembling this model, particularly around the number of VMs that we anticipated a Tintri VMstore could host. For our model, and over Tintri’s objections, we used what is likely an absurdly low number of VMs per Tintri VMstore storage array.

Tintri, in real world customer deployments, has demonstrated a single VMstore supporting thousands of VMs. While this seems extreme, the reality is that IO is often not simultaneous, and Tintri can equitably service an extreme amount of IO across many VMs. Moreover, Tintri is thin- enabled by default, and offers thin-enabled snapshots and clones that come with no observable performance penalty. By interweaving Tintri and VMware technologies (such as Linked Clones executed on top of Tintri SnapVM), it is quite possible to be extremely space efficient. Such space

Technology Validation efficiency can help Tintri harness their significant amount of performance from SSD to service many, many VMs simultaneously.

But we concluded Tintri’s demonstrated number of thousands of VMs on a single VMstore would have resulted in efficiency improvements that seem potentially unbelievable, and we decided to err on the side of caution by using a much lower hypothetical number. To evaluate the worst case, we instead turned to a model that assumed complete capacity or performance consumption (either full utilization by 50GB to 60GB sized guests, or full utilization of 60,000 IOPS, or a combination thereof) and a much lower number of VMs per VMstore.

Using this number, we developed a model for what would be required to build out a typical shared storage FC infrastructure to thousands of VMs. To get there, we assumed that the typical mid-range storage system we’ve been assessing so far against Tintri would serve a shared storage infrastructure, and that the storage administrator would gradually dole out capacity to the virtual infrastructure every 20 VMs or so (assuming approximately 1TB of capacity is made available to the virtual administrator at one time). Using these assumptions, we modeled how much time and effort the deployment and configuring tasks would require in a business scaling to 8,000 VMs. What we found was that Tintri had a 52X advantage over the traditional FC infrastructure in these tasks. It is easy for us to conclude that may be a realistic proxy, as every Tintri capability has far reaching consequences. Even density, which was only 6X better than the traditional storage system, will have an impact greater than 6X because denser storage simplifies the physical plant, reduces power, cooling, and air conditioning, and will likely decrease the per-storage-system costs of software licensing.

System Y1 Tintri

Time to deploy and configure 4 hours 78 seconds

Time to provision first volume/datastore 2 minutes2 20 seconds Estimated frequency of provisioning in a every 20 VMs every 250 VMs3 shared storage infrastructure Typical number of VMs per storage system 250 250

Total time involved, per 8,000 VMs 45 hours 20 minutes 52 minutes, 16 seconds Deployment and Provisioning Advantage 52X at scale

Table 7: Our assessment of Tintri deployment and provisioning advantages (ease of use impact) at scale suggests that Tintri can reduce annual time and effort associated with this task by 52X. Notes: 1Taneja Group is referencing a currently on-hand, upper-end mid-range unified storage array using 3.5” 15K SAS and SSD disks, a performance-oriented configuration, and our testing of the limits of this array. 2Taneja Group assumes a single administrator can fully provision a VM on a shared SAN without needing to coordinate with other administrators, but time to provision takes into account the likely need to select appropriate storage volumes (classes of service, and/or available capacity) and routinely expand allocated storage when operating in a shared storage environment. 3For Tintri, Taneja Group is assuming large VM sizes and a relatively low number of VMs per Tintri T540 – Tintri frequently identifies real world customers running many times (10X+) greater numbers of VMs per Tintri system. Efficiency may vary with smaller VM sizes, use of technologies like Fast Provisioning that reduce duplicate image data, or in the case of traditional storage when low IO demands enable significantly greater capacity deployed behind each system. But there is obviously more to this picture than just the time and effort involved with deployment and provisioning. While this exercise is not an exhaustive TCO comparison, we took the opportunity to further consider where else Tintri’s capabilities could impact the operational costs of storage behind the virtual infrastructure, and then gauge what the “magnitude” of that impact might be. In

Technology Validation particular, we considered whether these impacts are of enough significance to put teeth in Tintri’s recently adopted “zero management storage” tag line.

To arrive at an answer, we picked four areas – Deployment and Provisioning, Operational Tasks, Troubleshooting, and Planning. In each of these, we considered the magnitude of effort spent on this task when managing a single Tintri-sized storage system behind the number of VMs that such a storage system would typically support. Since this wasn’t a methodical hands-on comparison, we relied purely on our expertise and experience and assigned the unit we’d measure time in over the course of a year (minutes, hours, days, weeks). We then compared those units, and assigned our conservative impression of the potential time difference – in this case concluding that managing storage the Tintri-way could quite possibly deliver a 60X decrease in time and effort spent over the course of a year, at least in these tasks which make a significant majority of the tasks a storage administrator spends their time on.

The results here align closely with the 52X advantage we identified in the deployment and provisioning table above, suggesting that similar benefits may apply across the entire range of storage management tasks. A potential 50x to 60X reduction in management time and effort may not literally mean “zero” management, but it certainly is close, and will go a long way in making the virtual infrastructure far more operationally efficient.

The Tintri Management Difference

Traditional Tintri Storage

Deployment and Provisioning Minutes Hours

Operational Tasks (snapshots, Hours Weeks clones, information retrieval such as reviewing utilization) Troubleshooting Minutes Weeks

Planning Minutes Days

Bottom Line Hours Weeks/Months

Improvement 50X – 60X

Table 8: How we estimate Tintri technologies may impact the total time and effort invested in different types of tasks over a year, when comparing a single system versus a single traditional storage system. In fairness, this is not a comprehensive assessment of all of the effort behind storage management. But it is a good assessment of Tintri’s impact in several key areas that make up a bulk of storage management costs. As we’ve stated, the cost of mid-range storage management runs between $5 and $10 per gigabyte depending on the sophistication of the organization, and these costs dwarf the capital costs of storage capacity. Even if this is a partial representation of annual storage management time and effort, the cost impact from Tintri storage is still tremendous, and will without a doubt bring the costs of storage management well below the capital costs of storage for the first time ever.

Technology Validation

.NOTICE: The information and product recommendations made by the TANEJA GROUP are based upon public information and sources and may also include personal opinions both of the TANEJA GROUP and others, all of which we believe to be accurate and reliable. However, as market conditions change and not within our control, the information and recommendations are made without warranty of any kind. All product names used and mentioned herein are the trademarks of their respective owners. The TANEJA GROUP, Inc. assumes no responsibility or liability for any damages whatsoever (including incidental, consequential or otherwise), caused by your use of, or reliance upon, the information and recommendations presented herein, nor for any inadvertent errors that may appear in this document.