$/GB vs $/IOPS and how to compare enterprise storage pricing

A quick check on the website of any online retailer shows that storage is cheap. A consumer can get a 4TB capacity drive for less than £100. That’s an incredible £0.025 per GB.

But while raw drive prices are measured in pennies per gigabyte, the actual cost of storage for the enterprise is much higher, and more difficult to calculate. There are many factors that need to be considered, including media type, platform hardware and software costs.

So how can we work out a fair $/GB price, is this still the right metric and how do we use it to compare products from multiple suppliers?

Over the past 15 years of shared storage in the enterprise, the $/GB metric has been the de facto standard in product price comparison.

In the early days of SAN storage, things were pretty simple: there were 10,000rpm drives and Raid 1 systems. Things quickly became more complex, with other protection systems (RAID 5, RAID 6) and an increase in performance (to 15,000rpm drives) followed by a scaling back ( to 7,500rpm SATA drives), and all supported within the same array.

From 2009, we saw the introduction into enterprise platforms of flash storage with hot data dynamically assigned to flash as a tier or cache, making it even more difficult to calculate a simple $/GB figure for capacity.

So what is the best strategy to price storage? Here are some options to consider:

Start with raw $/GB. In any calculation, it makes sense to begin with raw capacity numbers before any reduction for data protection (for example, RAID) or any multipliers that result from data deduplication or compression, for example. Regardless of platform features, raw capacity allows a fair measure of one supplier’s platform against another.

Compare like for like. It’s not fair to compare SATA drives with flash drives in terms of performance or capacity, so don’t try to. Instead, look at either performance or capacity requirements (whichever is the most appropriate for the media) and base your calculation on that.

Check for Binary or Decimal GB. Yes, there is a difference. Storage suppliers quote capacities based on multipliers of 1,000, so 1GB = 10⁹ bytes. But, traditionally, storage has been sized using binary values, where one 1GB = 1,073,741,824 bytes = 1024³ = 2³⁰ bytes (technically known as a Gibibyte). The difference in these two figures is 7%, which can be significant in sizing calculations.

Build a standard model. Enterprise storage consists of more than just disk hardware. There are controllers, back-end directors, front-end ports, backplanes, management nodes and other pieces required to run a shared storage solution. Suppliers sell either as a package or price each component individually. On top of that, there is software. Some suppliers bundle software features for “free”, and some charge for each component. Either way, you’re paying for software in the cost of the product, explicitly or otherwise, and it should form part of your $/GB calculation.

Supplier comparisons cannot be made without having a similar configuration to compare against. This is why establishing design requirements is so important and why new storage deployments can be so complex. In legacy platforms from the last 15 years, a lot of time and design effort was invested in scaling the back-end and front-end connectivity of storage arrays. Today this is less of an issue because of the over-performance of flash systems (but it will become an issue again).

Be careful of supplier optimisation claims. Raw storage capacity is a good starting point for cost calculations, but many suppliers push the concept of “effective capacity”. This metric is the usable capacity of a system after data protection overhead and space optimisation techniques are taken into consideration. Features such as data deduplication and compression can result in very high savings ratios of 10:1 or more.

The actual compression benefits received may be somewhat less than suppliers advertise, as they are entirely dependent on the mix of data to which they are applied. Virtual machines and desktops deduplicate well. Meanwhile, OLTP databases compress well but are not great for dedupe, and very mixed datasets may not deduplicate very much at all. Values will also change over time and be affected by things like the roll-out of new operating systems (OS).