Home | Storage | SolidFire Update: New Products and Review
SolidFire Update: New Products and Review

SolidFire Update: New Products and Review

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×

Last week SolidFire Inc announced the release of the latest evolution of their all-flash storage platform, the SF9010.  This new system uses 960GB 2.5″ using the same 1U form factor as previous models, however internally memory has been upgraded to 256GB and the dual processors are now 8-core 2.6Ghz models.  SolidFire supports up to 100 nodes in a single cluster, with a minimum of 5 nodes to start with.  In terms of scale, with the release of the SF9010, a single node can scale to 3.4PB of storage in 100RU, which is around 2.5 racks, depending on your rack size.  

It wasn’t that long ago I was bemoaning the need to have a single 4PB storage array (EMC had just released their latest VMAX platform that scaled to 3200 drives and 4PB capacity).  I continue to believe that 4PB in a single array is folly; a single infrastructure of this size is difficult to support as it has major implications to so many hosts if problems are experienced, or if maintenance has to be performed.  Although a single SolidFire cluster can scale to close to this amount, the use of a scalable node architecture means most of the issues seen with a single monolithic array don’t occur.  For example, in the SolidFire system, no dedicated node is in charge of the cluster, however one node does act as the master (with three nodes or more in something called an ensemble for resilience).  This means nodes can be added or taken out of action without impacting overall cluster activity, bearing in mind the impact on performance).  This also means any single node failure doesn’t affect the availability of the cluster.  On the subject of performance, the more nodes in a cluster, the smaller the impact the failure of a single drive or node, so scale can actually be an advantage.

QoS and API

SF Scalability

I hear occasional rumblings from other parts of the IT media that storage is way behind the rest of the industry and hasn’t changed in the last 20 years.  Whilst that statement couldn’t be further from the truth (and could equally be applied to areas like networking), I can see if folks are only focusing on the legacy vendors like EMC, why this might be the perception of where storage is today.  However platforms like the SF9010 have evolved and there are two key features that differentiate them from the competition.

  • QoS – quality of service allows the administrator to specify a service level to a storage LUN, setting the minimum, maximum and burst IOPS allowed at the LUN level.  These values can be changed dynamically during normal operation, with the system reacting instantly to the new parameters.  QoS is important as it allows service differentiation, rather than “best efforts”.  Traditional arrays attempt to deliver their I/O as fast as possible, which means the latency experience on a new lightly loaded system will be very different to that on a heavily used array.  QoS means the I/O experience is consistent, despite the load.  In addition, implementing QoS helps to reduce or eliminate the “noisy neighbour” scenario where another server monopolises the array resources, due to a software bug or perhaps bad programming.  
  • API – Application Programming Interface management means all functions of the storage array can be handled programatically and integrated into an orchestration framework.  This is extremely important in cloud-based infrastructures where LUN creation, assignment, decommissioning, monitoring and alerting all need to happen without the intervention of a system administrator.  Without the API feature, cloud environments will not scale and still remain cumbersome to administer.  Having to involve an administrator in provisioning is a legacy approach.  Although many vendors will claim to offer an API, very few of them have native API support.  
Both of the above features are designed into the SolidFire platform.  I recently had a presentation of how both of these features worked and was impressed at how well they have been implemented.  Firstly, all interaction with the SF series arrays is by API call.  This includes the web management interface which basically makes API calls in the background and presents the results on a webpage.  During the demonstration, “debug mode” was enabled, which presented a window showing all the API calls and responses.  The window scrolled too quickly to keep up, however I’ve included some screenshots at the end of this post which shows examples of the API calls in action.  I’ve also included a couple of screenshots showing QoS parameters.  During the demo, a single LUN was heavily loaded with I/O, then constrained to a set IOPS limit.  Within seconds the system changed to meet the new settings.  It’s very difficult to present how simple this function is achieved, but I can say I was impressed with how seamlessly this function worked.

The Architect’s View

With three node sizes to choose from, there’s flexibility in capacity and performance.  Under the current Boron release of code, node types can’t yet be mixed but that is being addressed in the Carbon release at the end of this year.

SolidFire are targeting the ISP marketplace with their storage platform.  It’s a good fit for those environments as it offers granular scaling, low management effort, easy integration into orchestration frameworks and opportunities to build in service differentiation without having to implement this at the physical level.  There is of course, no reason to restrict these arrays to ISPs – any enterprise looking to deploy a cloud solution will find them a perfect fit.  However like everything, seeing is believing and I recommend taking up the offer of a live demo to see exactly how these systems perform.

Storage has evolved and doesn’t need to be cumbersome.  Just take the time to look at what’s out there and available. 

Related Links

Comments are always welcome; please indicate if you work for a vendor as it’s only fair.  If you have any related links of interest, please feel free to add them as a comment for consideration.

Subscribe to the newsletter! – simply follow this link and enter your basic details (email addresses not shared with any other site).

Copyright (c) 2013 – Brookend Ltd, first published on http://architecting.it, do not reproduce without permission.

About Chris M Evans

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×