Solid State Arrays: SolidFire

One of the attendees at TFD#8 was SolidFire Inc, another startup company focusing on selling entirely solid-state disk arrays. As you’d expect, they have their own niche and part of the market they are targeting with their all-flash drive product. So how do they compare to the competition and what’s their “unique selling point” compared to the likes of Violin Memory and Pure Storage?

Background

Solidfire was founded in 2009 by Dave Wright, who previously had created Jungledisk, a cloud backup provider. When Jungledisk was acquired by Rackspace, Dave had an epiphany around the way in which storage arrays were being used by cloud IaaS (Infrastructure as a Service) providers. This is the genesis of SolidFire and forms the basis for some of the specific features the SolidFire arrays offer.

The Offering

SolidFire have taken a slightly different approach to similar vendors in this space and chosen to deliver their product as a cluster of computing nodes. Each node contains processing, memory and disk in a fixed format, with scalability achieved by adding nodes in a clustered configuration. Performance is claimed to grow linearly across the cluster, as data is spread across all cluster nodes for both capacity and I/O load. This distribution mechanism provides for both consistent performance but also adds redundancy, with data replicated between nodes at the block level. A failure in a disk or node is handled automatically, re-establishing data redundancy.

SolidFire currently sell one model of storage node, the SF3010. This is a 1U “pizza box” rack-mount server with two Intel Xeon 2.4Ghz 6-core processors, 8GB of NVRAM (write cache) and 72GB of memory. Each node has ten 300GB 2.5″ SSD drives for a total of 3TB of raw storage. SolidFire have chosen the iSCSI protocol for front-end connectivity, with each node having two 10GbE connections. This choice of protocol is probably due to the clustered design; Fibre Channel isn’t easy to cluster without suitable multi-path software on the host servers. A single SolidFire cluster can scale from 3 to 100 nodes. Clearly a single node is not enough to run a resilient system, hence the recommendation for a minimum of three as the smallest configuration.

With a large amount of processing power per node, data entering a SolidFire cluster is de-duplicated and compressed inline. All LUNs are also thin provisioned. None of these features are user configurable and are all enabled by default. As a result, the 3TB raw per node translates to 12TB usable. We are seeing other SSD array vendors making similar claims that the usable capacity is more than the raw capacity due to data optimisation techniques. Designing these features into an array from the outset (especially with lots of CPU performance, memory and fast disk access) is something traditional vendors will struggle to emulate.

Secret Sauce

Every vendor needs to have their own “secret sauce” and SolidFire are no exception. It’s important to look at their target market, which is cloud-based service provision. This can mean both internal and external clouds, however the key message is that traditional provisioning methodologies don’t scale and don’t fit in automated environments. This is pretty easy to see this when looking at traditional storage management provisioning tools. SRM software is focused on interaction with the administrator, providing only point in time current views of storage and very few tools do concurrent provisioning well.

SolidFire have taken the approach of developing a REST-ful API for array management. This provides for all of the standard tasks of LUN creation, mapping and destruction with the ability to handle hundreds of API calls per second across a cluster. API integration is essential for any organisation looking to develop an automated cloud-syle provisioning process and this is an area where traditional array vendors simply can’t compete. API functionality can be integrated into existing processes and removes the need for large numbers of storage administrators – something that may be a worry to many, but we’re moving past the days of managing individual files and LUNs.

Another part of the “secret sauce” comes in managing I/O workload. Traditional arrays work on the assumption that all I/O needs to be delivered as quickly as possible and in the order in which it is received. There are some (but very few) arrays today that enable an administrator to prioritise workload. At best, all that is achieved is literally that – prioritisation rather than quality of service (QOS). I/O is still delivered as fast as possible, without regard for the service level needed for the I/O request. SolidFire have addresses the QOS issue by allowing individual LUNs to have minimum, maximum and burst levels of performance applied. This means LUNs created on day 1 of a new cluster deployment should receive exactly the same QOS and I/O performance when the cluster is fully loaded.

Deployment Scenarios

The ability to implement QOS features in cloud computing can’t be stressed highly enough. The first wave of IaaS (infrastructure as a service) enabled functional deployment – that is, proving workload could be moved to the cloud. The next wave will offer more QOS options other than simple processor and memory increments and storage will be one of those features. SolidFire arrays enables cloud providers to deliver differentiated levels of performance without having to deploy multiple tiers of storage. This is an important point. As soon as storage tiering is implemented, then efficiency drops, as there are always tiers that remain partially used. Block level tiering fixes some of these issues, but requires data to be moved around as part of performance re-balancing and still needs storage arrays to be monitored and assessed when adding additional storage. In addition, traditional arrays deliver I/O as quickly as possible, which can result in servers receiving more throughput than expected when an array is lightly loaded, but lower performance over time, which can be perceived by the end user as a performance problem.

The SolidFire solution will definitely see deployment in those organisations who have adopted a service-based approach to delivering computing services. With the API, QOS and node-scalable functionality, it is tailor-made for cloud deployments.

Summary

Solidfire started shipping in 2Q2011 with a $/GB price “similar” to that of traditional arrays. As with other vendors, the use of inline compression and compaction is being used to achieve an aggressive price point. Delivering for the cloud market is a smart move, as is the use of a scale-out node architecture that can grow as storage demand increases within an organisation. Cloud deployments use templated configurations, so the ability to configure and map LUNs via an API with no user intervention fits with automated orchestration requirements. I can see SolidFire arrays being widely used in many places over the next few years.

Additional Resources

The following video of Dave Wright was recorded at TFD#8.

Disclaimer: I attended TFD#8 as an invited blogger. My accommodation, some transportation and most meals were paid for. I was not compensated for my time, nor required to blog on any of the presentations. None of my blog entries, or other postings receive any pre-approval or viewings from vendors before publication.