What type of storage does your application really need?

Decision time

You can, of course, go to the nth degree when figuring out your storage requirements. Pragmatically speaking, though, the last thing you need is half a dozen types of storage that you have to juggle constantly between applications. I'd suggest you limit yourself to three at the absolute maximum.

Oh, and I am assuming you will be going for shared storage, not a pile of on-board disk with or without this new-fangled virtual SAN stuff that is starting to emerge.

High-end storage: if you need super-high performance number then you should definitely be looking at SSD, and you want the on-board disk interface to be something speedy such as SAS or Fibre Channel.

Frankly, unless you already have a pile of Fibre Channel disk shelves then go for SATA. It is currently available at 12Gbps throughput rates, and because of its backward compatibility with SATA there are benefits with upgrade protection (more about that later). So for your data-hungry applications it is SSD all the way.

Low-end storage: at the slower end of the market, the choice for most is SATA-connected storage on spinning disk. SATA gives a perfect balance of price versus performance – the lower speeds in the SATA range, at 3Gbps-6Gbps, are generally fine and cost next to nothing.

There is no reason right now to even contemplate SSD in your low-end applications, so go with spinning disk for the foreseeable future. What you might consider, though, is to host it in a storage system that will allow you one day to upgrade to something with a SAS interface.

This future-proofs you to an extent because if your higher-performance infrastructure starts to fill up you have the option to replace the SATA media with SAS-based SSD and maybe shift the low-end storage requirement elsewhere (to the cloud, for example).

Mid-range storage: I've left the middle to last, because it is the hardest – not that the basic technology decisions are difficult but everyone's requirement is slightly different. So the question is how to draw the balance between, say, high-speed SATA, mid-speed SAS spinning disk and high-speed SAS-based SSD.

The ideal solution would of course be to make it as fast as possible and go for SSD. There are two standard problems with this, though.

First, there is the cost – SSDs are an order of magnitude more expensive than traditional media. Second there is the fact that SSD “wears” – that is, you can only rewrite a particular location a certain number of times.

Realistically, though, the concept of SSD wear is starting to go away. In fact not so long ago one of the vendors came out with an “infinite wear” scheme, offering to replace a drive that wears out if you are still using it. You can put a tenner on the other vendors doing the same before long, so let's discount wear.

Back to cost, then. Yes, SSD is more expensive but as time goes by it will become less so. More importantly, the data I/O rates on an SSD drive are significantly higher than those on spinning disk, which you care about because you are aggregating your data onto a central storage repository.

So it is not about cost or, for that matter, about individual mid-range applications: it is about the best way to deal with the aggregated set of mid-performance applications.

Free the bottleneck

We have already said that your high-speed, bursty applications have a high disk requirement sometimes but not all the time. The burstiness can usually be handled quite easily with spinning disk, unless you are a big enterprise or an SME with some very esoteric and hungry applications.

What does become a problem, though, is the total overall requirement for the sum of the applications you have. It can all add up to a big load of data transfer, and what matters is the total IOPS (input/output operations per second) of the underlying storage system.

The link between your servers and the storage is no longer a bottleneck: with iSCSI on 10Gig Ethernet you can have cheap high-speed connectivity with a complete lack of rocket science.

But if the storage can't keep up with the aggregate throughput of your applications then you are stuck. In short, if you want maximum IOPS, wheel in the SSD.

The best solution is of course to bite the expense bullet and go for a full SSD installation which will take in the high-end and the more general apps on the same equipment. If you can afford it you will be blown away by the performance, but this is not an option for the faint-hearted.

The more sensible way to go for most is a hybrid solution: a single storage subsystem hosting multiple drive types.

Vendors are producing more and more clever automation that lets the disk array figure out what type of storage to use for each data item

Particularly if you are in a virtualised environment it is a breeze to assign different grades of storage to each of your virtual servers, and at the storage end you will be able to define the number of IOPS each LUN (virtual disk volume) can cater for, hence guaranteeing throughput to the key apps that need it.

Moreover, while the underlying SSD disks are coming down in price and growing in volume, so the storage subsystem vendors that use those disks are producing more and more clever automation that lets the disk array figure out what type of storage to use for each data item and present it to the applications that use it at the right speed.

So if you have a hybrid storage setup, then to a large extent you don't really have to care too much about what is where. More and more it will be able to juggle your data around itself to manage demand.