In December we announced our intent to acquire SolidFire. Today the deal has closed. SolidFire’s all-flash array is radically different from the EF-Series or AFF (All Flash FAS), so I want to dig into what exactly the architecture does and how it fits into our portfolio.
SolidFire clusters allow cloud-like scalability and simplicity. A cluster can have up to one-hundred nodes, each of which is a standard x86 system (1U rackmount with 10 internal SSDs). The entire cluster is a single pool of performance and capacity. SolidFire automatically handles all data placement, data protection, and performance. To provision a LUN, just specify the size and performance requirement (QOS). Writing 20 blocks may spray data onto 40 nodes. (SolidFire stores each block twice.) Need more space or speed? Throw in another node (or five or ten). In a few minutes, SolidFire automatically rebalances the data in your existing LUNs across the new nodes. If you have too much capacity or performance, it’s just as easy to pull nodes out. SolidFire is ideal for cloud service providers or for people building cloud-like infrastructure internally.
SolidFire’s architectural choices are elegant and made for a reason. (This is the geeky paragraph, so skip on if it is too much.) Why write twice instead of using RAID? First, it eliminates the performance reduction in degraded mode. Second, it allows commodity, single-attach SSDs instead of enterprise dual-attach drives. Way cheaper. And third, it eliminates HA pairs and shared RAID shelves. Nodes use internal drives, and Ethernet is the only interconnect. Way cheaper again. Together, these choices allow a shared-nothing cluster built from off-the-shelf x86 servers. How does SolidFire automatically balance capacity and load across the entire array? For each block written, it creates a “secure crypto-hash” of the block’s content and uses that as a “Block ID” to determine where the block goes. The crypto-hash also provides in-line deduplication across the entire cluster. In a loosely-coupled cluster, it is tricky to maintain consistent reference counts for deduplication, snapshots, and clones, so SolidFire uses garbage collection instead. This allows clone creation and deletion to be instant, even in very large clusters. I love how these design choices fit together and complement each other.
SolidFire fits nicely into our existing flash portfolio because it is so different from All Flash FAS (AFF) and the EF-Series. I think of EF as being like one of those racing cars built from aluminum tubes. It’s an exaggeration to say that EF has no windshield or doors, but you get the idea: it is super-fast and optimized for price-performance. By contrast, ONTAP has broad application integration and a rich set of enterprise-class data services.
It’s not that there’s zero overlap between the products. All three can run Oracle databases wonderfully. But they have very different design centers: bare-metal speed, simple cloud-like scale, and powerful data services. Over time, I expect flash to replace disk for primary storage. No single all-flash array can meet every requirement, but with this combination of products, we can help customers adopt flash for almost any use-case. Adding SolidFire to EF and AFF gives us the best and broadest flash portfolio in the industry.