SolidFire is one of several players in the highly-competitive all-Flash storage array arena. Despite the fact that their products have been being sold for two years now, and that Gartner scores them very highly in this space, I’m always surprised that people don’t seem to be more familiar with them.
I’ll attempt to fix this by giving an overview of SolidFire before I get into the details of today’s announcements.
SolidFire is block storage. Originally, they only offered iSCSI (over 10GbE). Recently they started offering FC connectivity
via the addition of a gateway node. (Take my advice: Don’t call it a “gateway” in front of the SolidFire folks. They really don’t like that term…) FC connectivity is provided to a SolidFire cluster by adding an “SF Fibre Channel” node. This node contains no drives, but adds 4 x 16Gbps FC ports (you know, like a gateway would). For true HA, you’d need to add two of these nodes. (To the storage layman, this might look like a redundant gateway pair.)
(OK, I promise to stop poking the SolidFire folks for the rest of this post. Disagreements over naming conventions aside, I really like their solution and think it incorporates a great set of features.)
As stated, SolidFire is an all-Flash array. It includes all the “standard” features that any all-Flash vendor who hopes to compete must have. It also includes a great set of “advanced” features, some of which some of the other vendors have. Lastly, it has a few differentiating features that — in my mind at least — separate SolidFire from the other all-Flash players.
First among the “required” features is a non-RAID scheme for data protection. At storage extremes — either with expensive cost/GB drives like SSDs or with huge high-capacity drives — the overhead of RAID protection becomes too costly and/or unwieldy. I won’t go so far as to say “RAID is dead” or even that its days are numbered, just that it doesn’t fit in an all-Flash architecture.
Second, due to the high cost/GB of SSDs, an all-Flash array requires space-saving features. SolidFire accomplishes this with automatic thin provisioning and with always-on inline data deduplication and compression.
Lastly, as you’d expect from any all-Flash array, SolidFire offers very efficient and very fast clones and snapshots.
For me, this includes other things needed for a truly-efficient and effective all-Flash array. While the “standard” features list is met by all of the all-Flash vendors, most have only a subset of the “advanced” features.
The first is always-on data-at-rest encryption. SolidFire accomplishes this using 256-bit AES encryption. With this feature, any drives that somehow find their way out of the array into the bad guys’ hands can’t be read.
Second is native backup and restore capability via automated snapshots. Now, I’m still old-school enough that I don’t consider snapshots on the same hardware to be true backups (backups are the copy of your data you go to when the array is unavailable), but enough storage vendors now refer to “snapshot-based backup” that it rates a mention in the list.
Third is real-time replication to a remote array. Some all-Flash vendors don’t offer this, some do via an add-on product, and very few offer it built-in at no extra cost. SolidFire is among that last group.
Fourth is management via REST-based APIs. With the advent of Cloud and remote-operated “lights-out” data centers, the entire industry is moving in this direction. SolidFire is among the vendors who are already there.
Lastly, the availability of a VMware vCenter plug-in for managing the storage when it’s used for virtualization. (C’mon, you didn’t really expect me to get through an entire storage post without mentioning VMware at least once, did you?) It seems like this feature ought to be on the “standard” list, not the “advanced” one, but not everybody’s there yet. SolidFire is, though.
These features are what, in my mind anyway, separate SolidFire from the rest of the all-Flash vendors out there. As of this writing, I’m unaware of any other all-Flash vendor that offers any of the features in this list. (Roadmaps don’t count here — I’m interested in stuff my customers and I can use today.)
First is a built-in Microsoft VSS provider for application consistent snapshots. Most storage vendors can do this, but it’s usually through some add-on piece of software. SolidFire has it built-in at no extra charge.
Second, is built-in OpenStack, and CloudStack drivers. More cusotmers are exploring the *Stack options, and SolidFire is ready for them.
Third is built-in quality of service controls. With these controls, SolidFire administrators have complete control over their storage system. They have very fine-grain controls for setting minimum and maximum response times, as well as controls over how bursts are handled. These features are great for environments that have — or would like to offer — performance-based service-level agreements. SolidFire’s QoS allows administrators to adjust performance allocations on-the-fly, with no interruption of services.
Lastly, SolidFire is the only all-Flash vendor offering a true scale-out cluster architecture. This architecture allows customers to scale both performance and capacity simultaneously, and to upgrade a cluster (adding nodes) with no disruption.
SolidFire scales from 4 nodes up to 100 nodes in a single cluster. I spoke with a few folks at SolidFire about the 100-node limit and received pretty much the same answer from all of them independently:
- There’s no theoretical limit to the number of nodes you could have in a cluster, provided you have large enough network switches and address space.
- Given that a cluster of 100 of SolidFire’s highest-capacity nodes would have 960TB of raw Flash capacity and about 3.5PB effective capacity, SolidFire saw no point in going beyond 100 nodes until there’s a market demand (and use case) for it.
Within a cluster, different node hardware models can be mixed as the customer desires.
The cluster architecture is very elegant and ends the “forklift upgrade”. It would be possible to replace an entire cluster’s hardware with newer hardware versions with zero downtime to your end-users. You’d simply add the new hardware to the existing cluster, then put the old nodes in “maintenance mode”. The cluster would automatically migrate data off of the older nodes in the background, allowing you to shut them down and remove them once the migration was complete, leaving your end-users unaware that anything had happened.
Series D Round of Funding
Today, it became clear that investors are believers in SolidFire’s architecture and offerings. SolidFire announced the completion of a Series D round of funding of $83 Millon.
Prior to this round, SolidFire had four investors: NEA, Novak Biddle, Samsung Ventures, and Valhalla Partners. All four of these investors contributed to Round D, along with three new investors: Greenspring Associates, Silicon Valley Bank, and an unnamed sovereign hedge fund.
This round brings SolidFire’s total funding to $150 Million.
New Hardware Offerings
The new nodes are the SF2405 and SF4805. The SF4805 uses drives twice the size of those used in the SF2405 while offering the same number of IOPS that it does. The new nodes use smaller-capacity SSDs than the second-generation SF3010 and SF6010 hardware. It’s unclear to me if the new nodes will be replacing the SF3010 and SF6010 in SolidFire’s lineup or are being offered in addition to them.
What is clear to me, however, is that SolidFire intends to use these lower-capacity nodes to expand into the “lower end” of the all-Flash market. A “starter set” (4-node cluster) of SF2405 nodes offers 35TB of effective capacity at 200,000 IOPS for less than $100,000.
As mentioned in the architecture overview above, these new nodes can be non-disruptively added to existing SolidFire clusters.
Details on the new nodes, plus more of the SolidFire family of offerings are in the table below.
The SF2405 nodes will be available at the end of October.
The SF4805 nodes are expected to start shipping in mid-November.