IT storage ... why its not HPC storage, and shouldn't be used where you need HPC storage

In a previous article, I railed on the concept of IT designing clusters. I pointed out many flaws we have seen when this happens. I’d like to do the same thing with storage. This will be brief. Recently had a customer for our consulting ask us with deep incredulity, how one of our older 24 drive 7200 RPM SATA drive units could so thoroughly demolish (on benchmark testing) a brand new 24 drive 15kRPM SAS drive unit. It all comes down to design. A 15kRPM drive doesn’t guarantee fast IO. Nor does SAS. I could keep going, but the salient point is that this always comes down to IO design. A great IO design will almost always demolish a crappy IO design. This is what happened here.

I have a longer post about this, and the risk of making platform decisions before you make business decisions about the most appropriate platform to meet a business objective. Its frankly wrong to purposefully ignore better/cheaper/faster solutions because they don’t carry a particular brand name on the outside. Wrong for the business, as you eliminate a-priori any potential benefit of the platform you ignore, including cost savings, performance/productivity enhancement, etc. There are many other reasons as well, but will stick with these for the moment. IT designed storage all looks about the same. Its not particularly high performance. Actually the way it is usually designed, it is in all honesty quite low in performance. And when you have hard performance targets to hit, this is where IT designed storage misses the mark. IT != HPC, despite protestations of some OS vendors. Conflating the two means more customers constrained to bad designs for high performance IO. And as I observed recently, customers test alternative OSes, and discover, rapidly, that they have performance advantages to switching. Add in these hard targets, and high hardware costs, and you have a recipe for several of the conversations I’ve had over the last few weeks, with about 5 customers in one market vertical. If your vendor can’t meet your performance targets, you need to expand which vendors you are talking to. I’ll finish up the longer post later on, but the gist is that you agree to accept technological and business risk when you limit your vendors to a select few. They may not be able to achieve their objectives. This is a bad thing. Is the cost of this risk worth the benefit? And what, precisely, is the benefit to using gear that can’t meet business performance objectives? How does this advance a mission?