This article is more than 1 year old

Storage, probably like a college girl buying a belt. Be ready for the freshman 15

OMG, I just need to let my array out a bit

Storagebod Provisioning and utilisation seem to be a perennial subject — there still seems to be a massive problem with large enterprises who appear to have far too much storage for the amount of data they store. There are many reasons for this, and there is certainly fault on both the customer and vendor side.

Firstly, as a customer, you should expect to be able to use all the capacity that you purchase, and your internal pricing models should reflect this.

Obviously, there is always an overhead for data protection and hot spares, but once this is taken into account, all that capacity should be usable. You need to define what usable capacity means to you.

There should not be a performance hit for utilising all usable capacity. If the vendor states that best practise is only to use 70 per cent of usable capacity, that needs to reflected in your TCO calculations to give you a true storage cost.

Secondly, as a customer you need to ensure that your processes and operational procedures are based around provisioning the right amount of storage and not over-provisioning. Allocating storage for a rainy day is not a great idea; thin provisioning can help with this but it is not a silver bullet.

Thirdly, as a vendor you need to be up front about the usable capacity; if you can only realistically use 70 per cent, you need to factor this into your pricing models and show the customers exactly what they are getting for their money.

Be open and honest. If you want to show a price per IOP, a price per gigabyte, or some other measure, that's fine. If you want to show a price based on your assumed dedupe ratio, be prepared to put your money where your mouth is.

Fourthly, as a vendor, look at ways of changing how storage is allocated and presented. It is time for us to move away from LUNs and other such archaic notions; provisioning needs to be efficient and simple. And we also need the ability to deallocate as easily as we allocate. This has often been problematic. Obviously this is not just a storage problem — how many companies are spinning up VMs and then not clearing them down properly? But make it easier across the board.

Lastly, as vendors and users, we need to look at data mobility. Too often, the reason that an array is under-utilised is because you have reserved capacity for application growth because it is simply ‘too hard’ to move an application’s data once it is in place. This is also a reason why many customers are wary of thin-provisioning; the rainy day scenario again.

However, large arrays bring their own issues; from change management to refresh cycles. Smaller might be better for many but unless data can be easily moved, there is a tendency to buy arrays that are large and reserving capacity for growth. ®

More about

More about

More about


Send us news

Other stories you might like