Choosing analytics: built-in, on-premises, or cloud-based

With the announcement of Tintri Analytics, we delivered on our vision: providing comprehensive, application-centric real-time analytics (using fully integrated on-prem and cloud-based solutions) that provide predictive, actionable insights based on historical system data (of up to 3 years).

Customers can now automatically (or manually) group VMs based on applications to analyze application profiles, run what-if scenarios, and model workload growth in terms of performance, capacity and flash working sets.Analytics

When you consider a storage solution refresh, analytics probably tops your list of needed features. It simplifies IT’s job, makes IT more productive and helps organizations save time and money.

The question is, what type of analytics should an organization look to have—built-in, on-premises or cloud-based? If you are just getting started, any sort of analytics would be great! Most storage vendors have an on-premises and/or a cloud-based solution. But an ideal storage product should have all three, as each of them has its own irreplaceable use case. Let’s take a look at each one.

Built-in analytics for auto-tuning

Built-in analytics that the system uses for self-tuning are uncommon in the industry. Tintri’s unique auto-QoS capability is a great example that uses built-in analytics, available at a vDisk level, to logically divide up all the storage resources and allocate the right amount of shares of the right type of resource (flash, CPU, network buffers etc.) to each vDisk. By doing this, a Tintri VMstore ensures that each vDisk is isolated from the other, without noisy neighbors.

Operationally, this simplifies architecture, as the IT team doesn’t have to figure out the number of its LUNs/volumes, the size of its LUNs/volumes, which workloads would work well together and so on. It can focus on just adding VMs to a datastore/storage repository as long as it has capacity and performance headroom available (as shown by the Tintri dashboard).

On-premises real-time analytics

On-prem analytics are extracted from a storage system by a built-in or external application deployed within the environment. Admins can consult these real-time analytics to help troubleshoot a live problem or store them for historical information. Admins can further use these analytics to help their storage solution deliver a prescriptive approach to placing workloads, and provide short-term historical data for trending, reporting and chargeback.

Tintri VMstore takes advantage of its built-in analytics to deliver an on-prem solution for analytics through both the VMstore GUI and Tintri Global Center. Up to a month of history can be imported into software like vRealize Operations, Nagios, Solarwinds and more.

Of course, customers don’t have to wait before they can see these analytics—unlike with cloud-based analytics, they can monitor systems in real-time.

Cloud-based predictive analytics

Cloud-based analytics help customers with long-term trending, what-if scenarios, predictive and comparative analytics. But not all cloud-based analytics are created equal. Some just show the metrics, while others let you trend storage capacity and performance. But the majority of them can’t go application-granular across multiple hypervisors, especially in a virtual environment. They’re just statistical guesswork based on LUN/volume data.

And that’s where Tintri Analytics separate themselves from the pack. With a VM-Aware approach, we understand applications, group them automatically and provide great insights across customers data.

Your IT team wants to be proactive, working on solving business problems instead of doing day-to-day mundane tasks. That’s why each of these three categories of analytics are must-haves. With Tintri Analytics, Tintri’s committed to reducing the pressure on storage and system admins, and helping to grow, not stall, your organization.



Improving Storage QoS Accuracy and Performance based Chargeback/Showback

A few weeks back, I wrote a series of blog posts (Part 1, Part 2, Part 3) on how Tintri simplifies chargeback/showback for service providers (SPs). With the release of manual quality of service (QoS) per virtual machine (VM) and the introduction of normalized IOPS, Tintri has made that value proposition for SPs even better.

Tintri Storage QoS

As we all know, Tintri is the only storage platform that has an always-on dynamic QoS service that ensures QoS at a vDisk level. As part of this new functionality, Tintri customers can manually configure QoS at a VM level.

QoS on Tintri systems is implemented on normalized IOPS (more on this below) and customers can configure min and/or max settings for individual VMs. The minimum setting guarantees performance when the system is under contention (when you are more than 100% on the Performance Reserves bar) and the maximum setting allows an upper limit on performance for the VM. The new latency visualization gets an enhancement as well with the support for contention and throttle latency visualizations that ensure that QoS doesn’t become a liability.

Screen Shot 2015-04-23 at 9.15.01 PM

If you want to read more about QoS, head over to the blog post here. There is also a great video posted here.

Normalized IOPS

Normalized IOPS are measured at a granularity of 8K by a reporting mechanism that translates standard IOPS into 8K IOPS. This helps create a single scale to measure the performance of various VMs/applications. So, in addition to reporting the standard IOPS per VM/vDisk, the VMstore also reports normalized IOPS for the VMs. So how does the Tintri VMstore report Normalized IOPS? Here are a few examples –

If an application/VM is doing 1000 IOPS @ 8K block size, the VMstore would report it as 1000 Normalized IOPS. Similarly the Normalized IOPs for an application doing 1000 IOPs @ 16K block size would be reported as 2000 Normalized IOPs. Taking a few more examples –

1000 IOPS @ 12K would be equal to 2000 Normalized IOPS as well (rounding off to nearest 8K)

and 1000 IOPS @ 32K would be reported as 4000 Normalized IOPS

Why use normalized IOPS?

  • As we all know, different applications have different block sizes. Normalized IOPS allows us to understand the real workload generated by various applications and help create an apples-to-apples comparison between applications.
  • It also makes QoS predictable. When we set up QoS using normalized IOPS, we know exactly what the result will be, instead of getting a skewed result because of the block size of the application.
  • It gives one single parameter for SPs to implement performance-based chargeback/showback. So, instead of considering IOPS, block size, and throughput, and then trying to do some sort of manual reporting and inconsistent chargeback/showback, the SPs get the measurements out of the box.

Let’s use an example to see how SPs can take advantage of the new functionality.

Screen Shot 2015-04-23 at 9.13.41 PM

In the above screenshot, we have three VMs and we can see the IOPS and Normalized IOPS for each of these VMs. If we look at just the IOPS, we would be inclined to think that the VM SatSha_tingle is putting the highest load on the system, and that it is 2.7x the VM SatSha_tingle-02. But if we look at the Normalized IOPS, we know the real story. The VM SatSha_tingle-02 is almost 1.5x of SatSha_tingle. This is also reflected in the reserves allocated by the system to the VMs under Reserve%.

In a SP environment, without the normalized IOPS, the SP would either end up charging less for SatSha_tingle-02, or would have to look at block size and do some manual calculation to understand the real cost of running the VM. But with Normalized IOPS, the SP can standardize on one parameter for charging based on performance and get more accurate and more predictable with its chargeback/showback.

Since Normalized IOPS are also used for setting up QoS, SPs can now guarantee predictable performance to its customers through implementation of min and max IOPS-based QoS. With Normalized IOPS, the SPs now have four different ways to chargeback/showback on Tintri systems: Provisioned space, Used space, Reserves and min/max Normalized IOPS. Each of these ways bring more accuracy and predictability to any SPs chargeback/showback model that directly affects their Profitability.



Simplifying Storage Chargeback/Showback with Tintri – Part 3 (Performance)

In the Part1 of this series, I covered the challenges around Storage Chargeback and Showback in Virtualized environments running on traditional storage platforms that use LUN/Volume Abstraction Layers and in Part2, I covered how Tintri simplifies and brings more accuracy to the Capacity Centric Model with its VM centric design.

In this post I will cover how Tintri makes it easy to incorporate a more accurate Performance based model into Chargeback/Showback that can be used in combination with the Capacity Centric Model.

As I stated in my first post – although everyone would like to add a performance centric model to Chargeback/Showback, it is not that popular given the complexities around implementing something like that on the storage side in a virtualized environment (refer my first post in the series).

As we all know, one of the big advantages (and differentiator) that Tintri has is that its abstraction layer is a vDisk (VMDK, VHD etc.) and not a LUN or a Volume. This allows it to see at the right level of abstraction (rather than looking at a LUN or a Volume). The other advantage that it has is that because of its tight API integration with various hypervisors, it sees a vDisk as a vDisk and not as another file. This ability allows it to create an IO Profile of every vDisk in the system. This IO profile gives Tintri an understanding of the type of IO taking place in side a vDisk (Random, Sequential, %Reads, %Writes, Block Size) based on which it assigns ‘Performance Reserves‘ to every vDisk. The Performance Reserves are a combination various resources in the storage platform – like Flash, CPU shares, Network buffers etc. and are shown by the Tintri Management interface in % values.

So if we consider a Database (DB) VM with C: Drive, D: Drive (DB files) and E: Drive (Logs), Tintri would look at those individual drives, learn about the IO profiles (say D: is random IO, E: is sequential and C: not much IO) and then automatically assigns Performance Reserves to these with a goal to deliver 99-10% IO from flash and sub-ms response times. The first benefit (as I have discussed in my other posts) of this approach is that Tintri automatically tunes itself unlike some other storage products that just show some values (most of them at a LUN/Volume level) and require the admin to take action – like add/buy more flash, reshuffle the VMs, reduce CPU/cache load etc. The second benefit, the one that we will discuss here in more detail, is that IT/Service Providers now have a metric against which they can do a Chargeback/Showback.

Performance Reserves are independent of IOPs and are a measure of how much Storage resources are consumed (or will be consumed) by the vDisk in order to get 99-100% IO from flash and sub-ms response times. Traditional Performance centric models that use IOPs as the measure don’t take into consideration the amount of Storage resources consumed by the vDisk to do for a particular type/size of IO.

The problem here is the traditional underlying storage architecture that continues to use LUNs/Volumes as the abstraction layer. These Storage products in some cases don’t have an ability to provide a Quality of Service to even those abstraction layers, let alone looking at individual vDisks and automatically tuning various storage resources for a workload.

Here we look at a simple example of how three different VMs having different type of IO characteristics get their Performance Reserves assigned by Tintri.

The VM ss_testld_1 in the first screenshot is doing 2,751 IOPs (Ave. 8K block size) with 90% Reads and has 5.2% Performance Reserves allocated to it.

Screenshot-1 - VM ss_testld_1

The VM ss_testld_2 in the second screenshot is doing 1,112 IOPs (Ave. 81.6K block size) with 90% Reads and has 10.8% Performance Reserves allocated to it.

Screenshot-2 - VM ss_testld_2

The VM ss_testld_3 in the third screenshot is doing 1,458 IOPs (Ave. 8K block size) with 90% Writes and has 4.6% Performance Reserves allocated to it.

Screenshot-3 - VM ss_testld_3

So what we do we see here?

The VM ss_testld_1 is doing 90% reads just like the VM ss_testld_2 and is doing almost 2.5x IOPs (2,751) than the VM ss_testld_2 (1,112) but still has lower Performance Reserves/Footprint (5.2% Vs 10.8%) because it has a much smaller block size (Ave. 8K Vs Ave. 81.6K)

So, if we look at just IOPs, the cost of running ss_testld_1 seems higher but in reality the cost of running ss_testld_2 is more than double that of ss_testld_1.

In the same way the VM ss_testld_1 is doing almost double the IOPs (2,751) than the VM ss_testld_3 (1,458) with the same block size (Ave. 8K) but they are using almost similar performance reserves 5.2% and 4.6%) because the latter is heavy on write (90% Writes).

Here if we look at just the IOPs, the cost of running ss_testld_1 again seems higher but in reality the cost of running ss_testld_3 is almost the same as ss_testld_1 even with ss_testld_3 doing half the IOPs.

Taking a very simplistic example for Chargeback/Showback, if we consider the cost of 100% Reserves at say $100,000 based on cost to acquire/install/support Tintri

  • ss_testld_1 would cost around $5.2K to run
  • ss_testld_2 would cost around $10.8K to run
  • ss_testld_3 would cost around $4.6K to run

If we had taken a IOPs centric model, the costs would have been completely different with no relation to the amount of storage resources consumed to run a particular type of workload.

The other big challenge with the IOPs centric model is its unpredictability. Let’s say we sized a storage platform for X IOPs (say 8K) with some read:write, rand:seq mix and then priced per IOP accordingly. What if the platform doesn’t deliver those IOPs (say it delivers Y IOPs) because our assumptions were wrong or because of completely unpredictable workloads. The difference (X-Y) now has to be absorbed somewhere. So to cover that, IT/Service Provider would charge more next time and become uncompetitive.

The Performance Reserve metric is independent of the IOPs and can be combined with a Capacity Centric Model (for capacity hungry VMs) to give a more accurate Chargeback/Showback model.

The cool thing about all of Tintri’s metrics is that they are all exposed through our REST APIs and Powershell Integration. Therefore these can plug into any customized model as well, giving a more predictable, simplified and accurate Chargeback/Showback Model.

Thanks for reading…



Simplifying Storage Chargeback/Showback with Tintri – Part 2 (Capacity)

In the first post of this three part series, we discussed the challenges around Storage Chargeback and Showback in traditional environments. This post will focus on the Capacity based Model for Chargeback/Showback and how Tintri brings in more accuracy and value add to the model.

As we all know (by now – refer my other blog posts), Tintri doesn’t use a LUN/Volume abstraction layer like traditional storage platforms. LUNs/Volumes were designed for physical environments and we just continued to use them for virtualized environments since there was no innovation done by storage vendors specifically for virtualized deployments (until now). Tintri uses vDisks (think VMDKs, VVOLS, VHDs etc.) as the abstraction layer in the storage platform. Using vDisks as the abstraction layer, allows it to see at the right level of abstraction without the added complexity or layers of LUNs/Volumes. What this means to a Service Provider (Internal IT or Public) is that now they can not just look at what is provisioned to a VM or used inside the VM but the overall Capacity Footprint of a VM. The overall Capacity Footprint of a VM not just consists of the Live Data but also space used for other things like Data Protection.

In the example below, I have highlighted the VM Demo-A. As you can see that in the Tintri GUI, you not only see the provisioned space but also the actual used space by the VM in the Used GiB column. Double clicking the VM shows us various graphs for the VM and in this case I have selected the ‘Space’ Graph that shows us exactly how a 50GiB VM is using 134.5GiBs. We breakdown the 134.5 GiBs into Live Data, Hypervisor Snapshots and Tintri Snapshots to give a complete picture of the Capacity Footprint of the VM.

Capacity Showback

Tintri GUI Screenshot showing the Capacity Footprint of a VM

This is not only important because it allows the IT/Service Provider to charge for the right amount of storage consumed by the tenant, therefore increasing the accuracy and predictability around Storage consumption but also because now the IT/Service Provider can provide more insight and value add.

Chargeback/Showback models can be complex. Here we take a very simplistic example –

  • If we consider the cost of 1 GB of storage as $3
    • With a traditional storage the chargeback would be 50GB x $3 = $150
    • Whereas the actual cost of the VM Demo-A is 134.5 GB x $3 = $403.5
      • So either the Service Provider is taking a hit here or is including this cost as a buffer in the overall costing per GB, making it less competitive
    • As a value add, IT/Service Provider can show the various buckets in which the capacity is being utilized in order for the Tenant to reduce its cost
      • So in case of the VM Demo-A the breakup would be –
        • Cost of Storing Live Data – 45GB x $3 = $135
        • Cost of Data Protection – $3 x (9.29GB+80GB) = $267.87
      • With this information in hand, the tenant can take a decision on deleting some of the older snapshot copies to reduce the cost of running the VM from a capacity standpoint

As we can see in this example, Tintri brings in more simplicity and accuracy with a Capacity based chargeback/showback model . In the next post, I will discuss the performance based model and how Tintri can help with implementing something that is potentially more accurate than a typical IOPs based model.

Thanks for reading.



Simplifying Storage Chargeback/Showback with Tintri- Part 1

Enterprises today are moving towards a Private Cloud based model for running their IT Infrastructure or they are looking at Public Cloud for some of their select workloads. One of the key requirements of deploying a Private Cloud or consuming the public cloud is Chargeback or Showback.chargeback

As we know, with Chargeback, the IT Department/Service Provider hands over a formal bill to the Line of Businesses (LOB)/Customer to recover costs of delivering the service to them whereas with Showback, there is no exchange of any Bills or money.With Showback, IT just tries to introduce a culture of Cost Awareness, Cost Justification, Capacity Planning and Awareness. The model chosen by different enterprises depends on policies and objectives that different Enterprises have.

Chargeback/Showback – The Storage Challenge

Both Chargeback and Showback require some definitive metrics at various levels based on which the overall cost can be measured for delivering a service. Here the discussion will focus on the Data Storage side of the equation.

Continue reading