Several days ago I found the time to sit down and watch Joe Tucci’s and Jeremy Burton’s Oracle OpenWorld speeches.
Jeremy’s discussion of “Project X” was something that stayed with me for a few days. Not only did I find what he did say interesting, but I also think it’s worth emphasizing something that he didn’t say.
Starting at 27:30 of the video, a statement was made that the all-flash disk array (Project X) has been designed from the ground up to manage flash only (no spinning disk):
“We can start to rethink the storage array from first principles, which is incredibly liberating.”
“Flash has got very different characteristics…. reliability … flash burns out … durability”.
The intelligent software inside Project X routes application I/O to the flash layer via auto-balancing algorithms (to reduce burn out rates) while simultaneously leveraging deduplication to minimize writes (also reducing burn out rates).
The statements got me thinking. Early in my career I had the good fortune to design disk array internals from scratch (CLARiiON, now known as VNX). The disk array internals were designed for spinning disks. Power failures, SCSI bus glitches, and mechanical disk malfunctions were the main gremlins that the intelligent RAID software had to cope with. Every opportunity was taken to parallelize operations that spanned mechanical disks to avoid write penalties. Caching algorithms came into existence to overcome phyiscal disk write penalties as well.
So indeed, the characteristics of the underlying media played a large part in the ground-up design. All of the code was written from scratch, and it took a good many years to qualify the system once the code was written.
In the case of Project X, the team is being asked to deliver in a much shorter time frame.
Which brings me to a rather significant difference between now and then (which wasn’t mentioned during the talk).
EMC has quite a few software components in the portfolio that Project X developers can integrate and use. So while the I/O path core design may be brand new, required features (such as deduplication to reduce the number of write operations) do not need to be re-designed or re-written from scratch. The same would hold true for any other feature that may be useful for Project X: security features (RSA), replication features (RecoverPoint), or storage management infrastructure components (e.g. Unisphere). These components could be integrated at any time within the project lifespan.
If this model sounds quite familiar, it is. The VNXe was built that way.
In the present day, however, the roughly 3 to 4 year time frame it took to build a storage array from scratch in the 80s and 90s has given way to much shorter time windows in the present-day high-tech market.
Feature re-use of best-in-class components is a great way to fit into this shrinking window. Project X will be delivered more quickly as a result of this approach.
Steve
Twitter: @SteveTodd
