Nimble Storage InfoSight Reveals Extensive Usage of Thin Provisioning

Given the prevalence of thin provisioning as a table stakes feature in the storage industry, much has been written about its advantages, as well as its downsides. On the plus side, overprovisioning can save valuable storage capacity by preventing unused space from being locked in “thick provisioned” volumes if the volume was initially sized conservatively.

 

Among its downsides, unexpected spikes in capacity utilization (filling up of space on multiple volumes simultaneously) could cause the entire system to run out of space before additional capacity can be purchased, a so-called “run on the bank”. In some cases, host OS file systems (like older versions of NTFS) did not make the most efficient use of thin provisioned storage because they did not notify the storage system to free up deleted blocks. And of course, many storage products did not really do a good job of implementing thin provisioning – requiring complex configurations and painful reservations to take advantage of it.

 

Modern storage architectures like Nimble Storage’s CASL were designed with thin provisioning built in from the get-go, making it simple enough to be enabled by default. Features like “always on” inline compression truly make it useful to enable thin provisioning. Threshold alerts are complemented by deep workload analytics (such as InfoSight), allowing accurate forecasts well in advance. And industry advances such as SCSI unmap now allow host file systems such as VMFS and NTFS to free up dead blocks on thin provisioned volumes.

 

Surprisingly in all this discussion about thin provisioning, you rarely find meaningful statistics on its adoption rates. Even less common (but far more interesting) is any discussion of the degree of overprovisioning actually observed in the real world. Well, thanks to InfoSight statistics, we can tell you what’s going on in the Nimble install base.

 

Nimble customers actually use thin provisioning

Looking at arrays that have been in the field for at least six months (by which time the admins have presumably settled on their capacity management approach), we see the following:

First, virtually every system in our install base takes advantage of thin provisioning. Although you can disable it per volume by explicitly reserving physical capacity - only 1% of the systems had thin provisioning disabled entirely.

Even if we look for systems that have it disabled selectively (100% reservation for some subset of volumes), we find that only 20% of the systems had thin provisioning disabled (reserves enabled) for some subset of volumes. Or put another way, 80% of all systems are taking advantage of thin provisioning acrosss the board - i.e. on every single volume that exists on the system.


In fact Nimble customers are using thin provisioning very aggressively.

The data above describes how prevalent thin provisioning usage is in the Nimble install base. But to what degree are people “overprovisioning” capacity? The chart below answers this question – it shows the distribution of the Provisioning Ratio, defined as:

(sum of all provisioned volume sizes on the array) / (usable capacity).

For example, if an array with 25TB usable capacity was provisioned with 100 volumes of 500GB (0.5TB) each, its Provisioning Ratio is 200% (100 x 0.5 / 25). A few observations about the InfoSight statistics:

  1. The distribution of Provisioning Ratios is fairly wide (and very roughly resembles a normal distribution).
  2. The average Provisioning Ratio is 118%, and the median is 103%.
  3. Surprisingly, there are a large number of systems with Provisioning Ratio > 200%. In other words, these customers are leveraging Thin Provisioning very aggressively - and no, this isn’t explained just by lab demo systems – we excluded known demo systems from the distribution.

ThinProvDistribution.png

 

We’d like to hear from you

Are you taking advantage of thin provisioning (with Nimble or any other storage solution)? If so, how extensively, and what is your experience like?

If not, why not?