I have been a silent reader of your blog and insights for quite some time. You have opened up a conversation on a topic that I feel is important. At Luminex we have found that the Storage Pyramid itself has outlived its usefulness. We now promote the Storage World which can be found and discussed at http://www.luminex.com/solutions/default.htm

The Storage World takes a customer view of what job is trying to be done that uses storage – in recognition of the insights detailed in the Innovator’s Dilemma as David Flynn mentions. The four primary jobs, or quadrants of the Storage World, are Primary Storage, Backup and DR, Archiving and Compliance, and Data Sharing. Using a storage technology may make perfect sense with respect to one quadrant, but not another. At any cost, flash isn’t better for off-site Backups than tape, just like tape isn’t a naturally great storage choice for Primary copies of production data. And the concepts perpetuated by the Storage Pyramid that data should migrate between storage media over time only works within a given storage quadrant, if at all, and don’t adequately address the true nature of customer storage concerns.

I’m interested in your comments and perspective.

Art Tolsma
CEO
LUMINEX

===

Well, for example, a lot of people use filesystems instead of RDBMSes. Many of the biggest systems in the world, driving the highest I/O rates, are machines at the national labs that never saw an RDBMS. Flynn’s recommendation to use log or query replication is completely inoperative in such situations, and where are the shared-nothing parallel filesystems? Panasas or Ibrix might claim to fit this bill, but (a) they’re rather expensive offerings competing with free ones, (b) they’re not dominant players in these markets, and (c) they have their own problems. What problems? Well, #1 that I mentioned in my own blog entry on the subject before you even posted Flynn’s advertorial is that once you’re doing that kind of thing you just gave up the in-host flash’s supposed advantage of nearness to the CPU crunching the data. If I, on a client/compute node, have to access storage on some server node through some sort of external interconnect, how does it benefit me any more for that storage to be flash? Disk offers more capacity per dollar, RAM more performance per dollar, and if we’re already distributing across servers because those are our unit of failure and recovery then the volatility of RAM ceased to be a serious disadvantage. Add in load on the interconnect (more for redundant copies, and even more for the same kind of rebuild that’s supposedly so awful when done internally on a disk array but is typically even more disruptive in a shared-nothing environment) and you’re pretty much back to treating that flash as a disk. Maybe it speaks Lustre or pNFS object-based protocol instead of block protocol, but what you will have built looks an awful lot like disk to the rest of the system.

===

P.S. Pounce, one way or another, you can be sure they’re doing it to satisfy customer demand. They might think customers are misguided e.g. in preferring shared storage over shared nothing, but customers are after all customers. They will build their systems according to how their architects, not any vendor’s, feel is best, and if a vendor’s product doesn’t fit well into that model then that’s an opportunity lost. The particular demand in this case is likely to be availability. I suspect that many customers who actually care about availability would like this fast storage to be replicated, either transparently or explicitly, and having an external port makes that more efficient than if the data had to go all the way up to a software agent on the remote/secondary system and back down to its card.