I wrote an article just a few days ago entitled “Where did the 15k disk drive go?” It was a short piece, quickly done and meant to draw fairly obvious conclusions. When given a choice between faster and fastest, for the same or close money, people will always choose fastest. Little did I suspect the sheer amount of comments and emails that I would get from that article. It appears that everyone has an opinion on storage technology and how storage vendors build out their appliances. So, in the spirit of keeping the discussion going, I’ve decided to ask the flip side of most of the comment and email subjects. “If 15k drives are dead, then how much SSD is too much?” Let the games begin!
How much SSD?
I heard a Texan once say “How much is too much? Well, if it’s money in the bank or cows on the ranch, you can never have too much!” He was talking about things that directly affected his performance as a cattleman and his ability to perform his job or company function. The same can be said for SSD disk in the ever-changing storage arena of business. How much is too much SSD in a storage array or on a server? I’m not talking about the sheer amount of physical space – that depends on the applications and data depositories that the application will require. Plus a little bit for growth. What I am talking about is a percentage. Of 100% of the storage space on a given server or storage appliance, just how what percentage should be SSD – fast but expensive?
In my opinion, much will depend on a storage study. How many IOPs does your environment need so that storage is not the bottleneck in your environment? Is there too much latency in your SAN or NAS? If you don’t know the answers to these questions, then a storage study should be your next step. Check out my article here. SSD tends to be the most expensive option in GB/$, but that ratio is coming down as manufacturing processes change and get more efficient. But we all work in the here-and-now, so as of today, how much SSD is too much in your SAN, NAS, or hyperconverged appliance?
All Flash, or no Flash?
I have seen several examples of SSD ratios, all aided by software in one form or another. These fall into two camps at either end of the spectrum.
To start, there is the storage appliances with no SSD. These are fairly simple, and I don’t see them around much. If all you need is an array of large disks spinning merrily along, and your storage goals are met, do you really need SSD? I have been in proof-of-concept trials where SSD would not make any difference is system performance, until the programmers changed the application code to make it more parallel.
Then there is the “all flash all-the-time” argument. I am familiar with one storage array vendor that sells an all flash array with compression and de-duplication and claims that across the environment, the cost per used Gigabyte is cheaper than their hybrid array (which does not offer any compression type functionality). Of course with de-duplication your milage may vary, but that makes a compelling argument for all flash. There are certain industries where milliseconds matter, like stock market trading, or transaction processing. Those industries go all flash without a second thought.
The middle ground?
So now we reach the middle ground, where the argument get heated. Hybrid arrays replace the fastest tier of storage with SSD, or use large amounts of SSD as caches to buffer regular hard drives. Manufacturers use SSD to take the place of those good ol’ 15K drives, as well as some of the 10k drives, too. The larger and slower SATA drives remain the workhorses for storage. Older, slower data goes there to die. Or at least drive your backup software crazy.
So, where does all this leave us? Should we go ahead and use all flash since it is the wave of the future? Since I will be replacing my array as I outgrow it, should I buy affordable now, and look to put in all-flash when it is the standard? Assuming that I am not a government agency with black-budget trillions to spend, how much SSD is too much SSD? Looking forward to your comments.