The SolidFire Storage System: Reducing Complexity at Scale

A few weeks ago, I had the opportunity to get to know SolidFire and its Storage System product, an all-flash array designed for on-premises use but with some attractive cloud functionality. At first glance, the array looks like many of those in the all-flash space. It’s built out of discrete nodes; uses 10 Gbps networking to present iSCSI; does inline deduplication, compression, and best-effort real-time background replication; has copy-on-write, space-efficient snapshots; and scales linearly.

SolidFire Storage System
SolidFire Storage System

Where SolidFire differs, though, is in its focus. It has made decisions with its product to reduce what I like to call “mental friction,” or the ongoing drag on IT staff from operational complexity. A good example of this is its scaling: you can scale up to 100 nodes with 3.4 petabytes of storage and 7.5 million IOPS. This is quite a bit larger than the scaling of other competitors in this area, and it’s intentional. Multiple arrays means more complexity, more management, and more orphaned and lost space. It is almost always better to have one large pool of resources to deal with rather than five or six.

Like everybody else’s nodes, SolidFire’s three sizes of 1U nodes are built from custom hardware sourced from Dell. (It’s either that or Supermicro nowadays for underlying hardware, it seems.) The 3010 and 6010 models have 300 and 600 GB disks, respectively, and supply 50,000 IOPS each. The 9010 has 960 GB disks and more CPU and RAM, and it brings 75,000 IOPS to the table. There are no controllers—the iSCSI volumes are accessed through a virtual IP, and I/O is redirected to different nodes. The array speaks iSCSI internally over the inter-node 10 Gbps links. SolidFire doesn’t supply a network switch, preferring to have customers purchase whatever meets their own needs. That’s a wise choice. Silos in IT aren’t disappearing as fast as we’d like, and so often these deployments get entangled in politics when an array ships with Arista network switches but the customer is a Cisco shop. The new Fibre Channel capabilities released with SolidFire’s Element OS 6 update provide a bolt-on active/active gateway that translates the array’s native iSCSI into Fibre Channel, but that’s helpful in environments that want to continue using their Fibre Channel SANs for performance or political reasons. Fibre Channel is a connection option that operates in parallel with iSCSI; the two are not an either/or.

SolidFire’s node architecture is shared-nothing, providing a RAID-free, highly available environment with algorithms called SolidFire Helix. Helix is built to survive the loss of drives and whole nodes, and spreads data from every allocated volume evenly across all drives clustered in the whole system. This lends itself well to excellent utilization, and it also allows SolidFire to guarantee performance even when the system is degraded. Performance guarantees set SolidFire apart from most of the storage market, flash or not. SolidFire is able to ensure quality-of-service on a per-volume level, guaranteeing tiers of I/O availability and preventing noisy neighbors from destroying performance. This is a critical feature for cloud providers and multitenant setups, best implemented at the array level (unlike concepts such as VMware Storage I/O Control), and is sorely missing from almost every storage array in existence.

SolidFire Helix
SolidFire Helix

Generally, when a vendor does QoS at a volume level, that means a lot of additional complexity in management, as each workload will likely need its own volume. To combat this, SolidFire has a powerful REST API that is exposed to customers and automation tools. In fact, SolidFire’s own management UI is built on top of the REST API, proving that, unlike many other products’ interfaces, SolidFire’s automation interfaces are neither an afterthought nor second-class citizens. Additionally, SolidFire provides AWS S3 and OpenStack Swift APIs for use as an object store and backup, too. This is incredibly attractive for cloud providers as well as for large, on-premises deployments, since many third-party tools can leverage these APIs.

SolidFire is very honest about not being built for the mid-market, as it feels that most of the middle of the market is headed toward cloud providers anyhow. Some may consider this a weakness, but I consider it a great strength. It has allowed SolidFire to focus on the pain points of organizations with large storage and storage performance needs, to do so with great scale, and to do so in a way that greatly reduces operational complexity and all the mental friction that usually accompanies that scale.

One reply on “The SolidFire Storage System: Reducing Complexity at Scale”

Comments are closed.