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

Related articles:

• Who Will Be The First Solid State Vendor to Be Acquired?
• Solid State Arrays: Pure Storage Inc

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

Click here to view the embedded video.

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.

Background

Pure Storage was founded in 2009 by John “Coz” Colgrove and John Haynes, who have their background in Veritas and Yahoo respectively.  More details on their backgrounds can be found on the bios page of Pure’s website.  Other members of the team have worked in companies such as Netapp, Decru and Sun, including Michael Cornwall, who was the lead flash designer at Apple for the iPod and iPhone.  So far, the company has raised around $55m from investors, the most significant of which has to be Samsung, who provide all of the flash drives used in Pure Storage’s products.  We’ll touch on the relative merits or disadvantages of this later.

The Offering

So what are Pure Storage offering?  Well, it’s pretty simple; an all-flash storage array at a $/GB price that’s cheaper than traditional storage.  Today that consists of two models, the FA-310 and the FA320.  The FA-310 is a single controller with one storage shelf, providing up to 140,000 4K random write IOPS.  The FA-320 doubles the storage capacity and increases write IOPS to 180,000.

Focusing on the FA-310, the controller is based on two 6-core Intel Xeon processors with 48GB of memory.  Back-end connectivity is 6Gbs SAS and 40Gbs Infiniband, while front end connections are only based on Fibre Channel at this time (4x 8Gbs SFPs).  Storage is provided by 22x 256GB MLC flash drives, giving a raw capacity of around 5.5TB.  It’s not surprising that Fibre Channel is the only protocol available on the first models.  FCoE doesn’t have the adoption rate and iSCSI wouldn’t suitable for the type of traffic this array can support.  However the controller is detailed as having one spare expansion port, so we can speculate whether that is planned to be for Ethernet in the future.

The connectivity between the controller and disk is less than that offered at the front end.  This may seem odd but it reflects on one of the key features of the Pure Storage arrays.  Data entering the system is compressed and de-duplicated before being stored on disk, improving the overall efficiency of the array and reducing the volume of write I/O to physical media. The ability to perform data reduction before storing on media is the main way in which an acceptable price point can be met.  This is something many other vendors are also doing as most customers are clearly fixated on the $/GB formula as the only way to measure acquisition cost.  Pure quote a ratio of anything from 5-20x reduction and as anyone familiar with data reduction technologies will know, your mileage will vary depending on the type of data consumed.

Secret Sauce

Ultimately though, there has to be something that make Pure Storage stand out from the competition.  During our Field Day visit, we were lucky enough to have a presentation from Coz, without slides, using just the whiteboard.  He detailed what is probably the most important piece of Pure’s technology, and that’s the way they manage the SSDs themselves.

Solid state drives are fickle devices.  Every write wears them out and much effort has been put into technologies (like wear levelling, write amplification) to extend their lifetime.  MLC devices now have a much better reliability than they did a few years ago, allowing them to displace SLC in enterprise technology.  Understanding how to manage SSDs is Pure Storage’s secret sauce.  They work closely with the SSD manufacturers to understand the best ways to read and write from the devices in order to gain both maximum performance and maximum lifetime.  At the presentation they even claimed never to have had an SSD failure, something that was met with surprise by the audience present!

Part of the SSD management involves the use of RAID-3D, technology which manages the RAID stripe distributions across the disks.  RAID stripes are varied dynamically based on workload and the drive responses.  This allows failing drives to be avoided, increasing their lifetime.  It also means I/O response times can be made more predictable, avoiding random I/O spikes seen with individual SSDs as features like garbage collection kick in.

It makes sense to understand the best way to manage SSDs and having a relationship with the vendor of those devices certainly helps.  My only concern is whether single supplier relationships are ever good, from a cost, reliability and supply perspective.  Only time will tell.

Deployment Scenarios

So where would you deploy this kind of high performance array?  I don’t think simply replacing your traditional storage with a Pure array is the right approach.  One of the benefits of shared storage is that I/O demand consists of peaks and troughs, periods of high and low demand from many servers.  This means it isn’t necessary to deliver 100% full I/O performance to all servers all of the time, but only to meet peak demand, which is considerably cheaper to achieve than meeting maximum demand.

This isn’t the Pure approach.  Their arrays are capable of delivering 2000 IOPS for every TB of storage, even at 10:1 compression.  It means that the server environment driving this storage needs to have high I/O requirements across every TB of data.  Otherwise, the array is never running at peak efficiency.  It could be said that if the $/GB cost is at a parity with traditional arrays, then should this matter?  I think it does matter because there’s a perception that flash is an expensive technology and irrespective of the effective $/GB cost after data reduction, many customers will still focus on the raw storage and the cost of the device.

Summary

Pure Storage have done a great job in delivering a technology that brings solid state performance at an acceptable $/GB price.  There are some key features (data reduction, SSD management) that make this technology really work.  We have seen presentations of high I/O workload that can easily be managed by the Pure storage arrays, while continuing to deliver sub 1-millisecond responses.  None of the big storage vendors have technology that delivers I/O bandwidth in a way companies such as Pure Storage can.  All-flash versions of traditional arrays don’t have the added intelligence to manage SSD failures and peformance spikes.  I can therefore see that very quickly one of the three letter storage companies will be looking to acquire Pure or one of their many competitors.  For now, they need to focus on finding the right niche for their product, while educating customers in metrics other than $/GB.

Additional Resources

Pure were one of the companies at TFD#8 that were well organised in providing various pieces of media.  I’ve included some of them here, including a link to the entire presentation from the day.  There’s also a business-card sized set of instructions that Pure claim as their user manual.  It’s a fun way of demonstrating how simple their technology can be.

• Pure Storage Presentation from TFD#8
• Pure Storage Flash Array Datasheet
•  Pure Storage Flash Array Manual – Front
•  Pure Storage Flash Array Manual – Back

Click here to view the embedded video.

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.

Background

Solid state drives are nothing new.  I used them on the mainframe in the late 80s/early 90′s but they were hideously expensive.  In fact, they were so expensive that every single individual file was managed by hand, ensuring it was no bigger than necessary and only the files which could absolutely justify the low latency and response times resided on the technology.  The NAND flash we see today started with the same properties; SLC (Single Level Cell) solid state devices were very expensive, for example Intel’s X25-E SLC SSD device introduced in 4Q2008 had a list price of more than $22/GB.  That cost isn’t sustainable for all data in the Enterprise, however with advancements in technology, prices have dropped significantly.  SLC is being steadily replaced by eMLC (Enterprise Multi-Level Cell), which although lower cost technology, is delivering reliability at levels coming close to SLC.  Intel’s latest SSD710 Series comes in at just over $6/GB, a greater than three-fold reduction in just three years.

Cost reduction has meant solid state is more viable as a mainstream technology.  It has been added to the Enterprise as SSD drives in servers, PCIe cards in servers or as part of storage arrays either as an add on to existing technology, or as we’re seeing, as technology designed from the ground up to work with flash.  The last category is the most interesting and is one area where we’re seeing growth in the market.  Two approaches have been taken; incorporating SSD drives into arrays or integrating the flash directly into the array.  Whichever method is used (and both camps have their justifications as to why they are right), the additional intellectual property comes from both extending the life of the flash to commercially acceptable lengths and delivering consistent I/O response times that justify the increased cost.

Application

As I mentioned earlier, mainframe solid state was managed at the file level.  For solid state arrays to be successful, they need to be driven to the level they are capable of.  Normally cost justification is worked out on price per GB of storage, however that calculation now seems outdated, especially with the benefits of virtualisation.  Price per IOPS or even IOPS/GB are more relevant and the overall TCO, including space, power, cooling, hardware acquisition cost, maintenance and labour costs need to be included in working out whether the SSD array is right for deployment.  I’ll be discussing more on this over the coming weeks too.  In the meantime, let’s get back to the question in hand; who is likely to be the first to be acquired?

The Players

Here’s a brief rundown of some of the players (in no particular order):

• Texas Memory Systems
• Pure Storage Inc
• SolidFire
• Violin Memory
• Nimbus Data
• Whiptail Technologies

At this stage I don’t think anyone has a foothold in the market that guarantees their success.  Each vendor offers differentiating features or targets a specific market segment.  It’s too early to say who will dominate the market, equally who will be first to be acquired.  What we can be sure is that the big three letter storage vendors will be circling and watching this market space *very* closely.  Over the next few weeks I’ll talk about Violin, SolidFire and Pure Storage.  I’ve had briefings from each of these vendors, either directly or through TFD#8, so there’s some good stuff to learn.

Updated: Reviews will be listed here as they are written.

• Solid State Arrays: Pure Storage Inc

Background

Building arrays from pure memory isn’t new; Texas Memory Systems have had the RamSan series of products on the market for some time now (and there are others out there).  Of course, the problem for many large organisations is how to make use of such an expensive and relatively small device.  There are plenty of use cases where flash/SSD may be useful, however (a) it is difficult to target exactly which applications and (b) for those applications that can be identified, potentially only part of the data will benefit from acceleration.

One solution has been to follow the route of the traditional vendors and add SSD as an extra device within the same hardware chassis.  This isn’t a solution to using SSD but rather a sticking plaster over the problem; the SSD may give better read performance but it is unlikely that writes will be accelerated to the level justified by the additional costs of the SSD device itself.  In addition, the SSD is sitting behind a traditional storage array.  Vendors such as EMC, IBM and Hitachi have spent millions of man-hours and hundreds of millions of dollars on software developments to help smooth the impact and manage the unpredictable performance of hard drives.  Remember that when an I/O request is received, the storage array has no idea where a mechanical device like a hard drive is positioned and so cache, algorithms and that other clever intellectual property have been used to mask these physical inadequacies.

However, despite vendors’ best efforts, spikes and unpredictable response times do occur and there’s no way to remove them and guarantee completely consistent I/O responses.

The Violin Approach

So what happens if you can remove the cost issues and buy an SSD-based array for the same price as tier 1 storage?  This is the route Violin Memory are taking to market – make the SSD storage array as closely priced to tier 1 arrays as possible.  Remove the thought process and complications of determining what to place on SSD by making the price argument irrelevant.

In reality, Violin haven’t reached that price parity yet; prices are quoted around the $20/GB mark, which is around double what I’d expect to see for tier 1 storage (depending on volume).  However it is in the order of magnitude where organisations can look at those troublesome applications that decide that the cost of additional servers, disk spindles or re-writing the application is outweighed by simply moving the application to a Violin SSD device.

I think this is the ultimate tipping point for SSD use; where the cost of improving application performance is exceeded by the cost of moving to SSD, then SSD will win.  Where improving application performance is justified by increased business advantage, the business case is written.

Tech Specs

OK, let’s have a look at the technical specifications for the techies amongst you.  Firstly, today’s device capacity sits at 10TB in 3U and is expected to grow to 20TB in Q3.  I’ve also been told that this capacity is expected to be close to 5x greater by the end of 2010, which means 100TB of memory-based storage in a 3U unit.

The 3200 supports PCIe (x4 & x8)  as well as 4/8Gb Fibre Channel and 10Gb iSCSI and FCoE.  Latency is less than 100 microseconds.

Violin array use VIMMs (Violin’s name for their flash memory cards.  These are grouped together into 1TB units, using RAID-5 technology to manage failures.  Maintenance can be performed online periodically to replace failed VIMM devices.

There’s one major issue with Flash/memory-based arrays that Violin claim to have addressed.  That is the issue of degraded performance over time.  Have a look at the following graphic, showing saturated workload on the Crucial C300 versus X25M from Intel.  This graph and the associated review can be found on Anandtech’s website here.  Very quickly with heavy use, the performance for these devices drops off.  Violin claim their array doesn’t suffer similar issues and can deliver sustained performance.  Of course, we can believe that statement once we’ve seen a review of the product delivering the performance as promised.

Futures

A 10/20TB capacity in 3U isn’t huge by today’s standards.  If Violin Memory can deliver on their promises and bring a 3 to 5-fold increase in performance by year end (with a continual reduction in price) then things start to look interesting.  I’d like to see the results of some long-term stress tests on the 3200 series devices.  I have some more material to post in the coming days, once I can validate what’s open and not under NDA/embarbgo.  In the meantime, here are some questions to ponder:

• Do I have any I/O bound applications?
• Can I measure/determine my I/O bound applications?
• Is there direct businss advantage from increasing I/O throughput?

If you can start answering yes to the above questions, then perhaps SSD-based arrays are for you.