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.

Storage is one of the more complex pieces, as it is difficult to understand the impact of an application on storage both from a capacity and performance standpoint. Even more, within a Virtualized environment where the storage has no clue about the type of workload running inside a LUN/Volume. As we all know a LUN/Volume may be running multiple VMs at any given point unlike physical environments where one usually runs one workload per LUN. (Things may change for good with VVOLs at least in case of VMware but we still don’t know how traditional storage vendors would implement it so I am keeping it out of our discussion at this point)

In this first post we will discuss the challenges around traditional Chargeback/Showback model and then move to the part about how Tintri brings a unique and innovative way doing Chargeback/Showback for our customers in the subsequent posts. I will use a VM, an application and a workload interchangeably for this series.

Capacity based model

In a Storage environment, one of the more popular model for Chargeback/Showback is the capacity based model. There are multiple challenges when it comes to Capacity based Chargeback/Showback. Firstly, there is no way to correlate a VM’s capacity footprint to Storage. The Hypervisor layer may show something completely different as compared to Storage making it difficult to get the model right. Secondly, the capacity footprint of a typical VM consists of Live Data, Hypervisor Snapshot and Storage Snapshot at the minimum. Getting a breakup of capacity utilization and including distribution in all of the buckets in Capacity Calculation is something that is not possible in a traditional storage environment that uses LUN/Volume abstractions. This makes it challenging to get the Chargeback/Showback right.

Performance based model

The other part of the Chargeback/Showback puzzle from a storage standpoint is the performance requirement of running a particular VM/Application on the storage, which I call as the Performance footprint of a VM on the storage. Although a lot of IT departments/Service Provider like the idea around Performance based Chargeback/Showback, the reality is that Performance based model is not widely used because of the complexities involved. Using the performance model in combination with capacity based model can give more accurate results. The reason is that a consumer may have a 50GB VM using 25% of the performance resources on the Storage whereas a 500GB VM may use only 2%. With this in mind, using only a Capacity based model would not be fair.

Some of the Enterprises use IOPs as a metric to Chargeback/Showback at a VM level but that is not an accurate metric for Chargeback/Showback as well. An IOP could have a completely different meaning in different use cases. Just for an example, 1000 IOPs, 8K in size have much smaller storage resource utilization (8MB/s) Vs 1000 IOPs, 128K (128MB/s) in size. Even if we use normalized IOP measurement where everything is calculated in say 8K IOP, one still has to consider the difference in resource utilization when the IO is Read Vs Write and Sequential Vs Random. Writes have more impact on the storage resources Vs reads and in same way Random IO has greater impact on Storage Resources Vs Sequential IO.

The Business Impact

The downside of not being able to price the storage resource properly apart from the factunpredictability-traders-daily that it is unfair to some users is that it makes the IT department/Service Provider less competitive from the pricing standpoint.It also brings in unpredictability as something that was sized and priced for X amount of capacity and Y amount of IOPs may not even deliver those numbers because of the large variance in how workloads occupy space and impact performance resources on the storage.

In the subsequent posts (Part 2, Part 3) we will discuss how Tintri simplifies Chargeback/Showback through its Deep understanding of the Virtual environment.

Stay Tuned!

Cheers..

@storarch

4 thoughts on “Simplifying Storage Chargeback/Showback with Tintri- Part 1

  1. Pingback: Simplifying Storage Chargeback/Showback – Part 2 | Virtual Data Blocks

  2. Pingback: Simplifying Storage Chargeback/Showback with Tintri – Part 2 | Virtual Data Blocks

  3. Pingback: Simplifying Storage Chargeback/Showback with Tintri – Part 3 (Performance) | Virtual Data Blocks

  4. Pingback: Improving Storage QoS Accuracy and Performance based Chargeback/Showback | Virtual Data Blocks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s