Probably the most annoying and frustrating part of being a storage manager in the 1990s was the lack of decent management and automation tools.  Each storage vendor had some good and some bad software for managing their arrays.  EMC’s Symmetrix/DMX/VMAX range, for example, had a great and well thought out CLI management tool; Solutions Enabler.  Others like Hitachi’s Command Suite were not so great, but to be fair have significantly improved.  Some vendors looked to build SRM (storage resource management) platforms that could manage all vendor hardware.  We had Creekpath Systems (acquired by OpsWare in 2006), AppIQ (acquired by HP in 2005 and became Storage Essentials), a range of SRM products from EMC (Control Center, SRM Suite, etc), EMC ViPR, plus a host of storage “analytics” tools that looked at, but didn’t change the configuration itself.  These tools were all proprietary and in their own way had many flaws in design.

SMI-S, the Storage Management Initiative – Specification was an attempt (initially by vendors under the codename Bluefin) to pull together an agreed standard on how storage platforms should be managed.  Started in 2000, Bluefin was managed via SNIA (Storage Networking Industry Association) from 2002 onwards, where it still lives today.  SMI-S never really worked as an overarching management solution, in my opinion for a number of reasons:

  • The specification was unwieldy, with slow progress in integrating new features that were outpaced by the market.
  • Vendors had no vested interest in offering support for other tools, as they wanted to make money selling their own, so in many cases SMI-S support was limited or unusable.
  • Storage platforms hadn’t discovered XML or HTTP-based management and still relied on middleware software running on management stations.
  • Many storage platforms couldn’t be administered from an IP network and still had in-band management tools.
  • The storage provisioning process for many platforms was a “single threaded” task that couldn’t manage many concurrent provisioning tasks.

Redfish

So, in all practical terms, SMI-S is dead.  In replacement we now have Swordfish, a new management API that brings storage management into the modern world, using HTTP/REST-based APIs.  Swordfish is based on Redfish, the DTMF API for managing data center hardware (e.g. servers) that is starting to gain traction across the industry.  Rather than use proprietary APIs, vendors support standard API calls that can be run from tools like Python and obtain JSON-based results that are parseable and much easier to read than XML ever was.  More important here is that we’re talking about API-based management using HTTP, so having our devices accessible and managed via the network using a practical protocol.

SwordFish 1.0

Version 1.0 of the API specification covers block storage (provisioning, volume mapping/masking, replication, capacity/health metrics), file storage (creating file systems/shares) and initial support for object storage.  The release is currently up for public review – you can find details here (link and here).  At this stage I have no idea what the roadmap is for future development.  Note that Swordfish is an extension to Redfish, rather than being a schema in its own right.

The Architect’s View

I’ve spent some time looking through the draft Swordfish specifications and there’s little in there to capture the imagination of the end user.  There’s a lack of diagrams to show how the API maps to standard management functions, how they might be grouped, the kinds of data the system is likely to return and so on.  I’ve also not seen a list of companies promising to support the API.  OK, there’s a list of organisations that are engaged in technical development, but that’s not the same.  Probably the biggest problem here is the lack of any obvious SDS players.  Almost all of the vendors involved are traditional hardware box shippers.

I like the idea of having a revised version of SMI-S, as long as it isn’t simply a REST-based API implementation of the same functionality that was written in SMI-S.  The promotion of the standard needs some serious work to make it more customer appealing, because without customer demand, vendors won’t support Swordfish and the result will be another failed standard that nobody uses.  So far, there’s been no “S3 API” equivalent for the block and file world, so SNIA have a chance here.  I just hope they don’t waste what could be great opportunity to fix a long standard storage industry problem.

Footnote: Yes, the image associated with this post is a Tiger Shark, not a Swordfish.  :-)

Related Links

Comments are always welcome; please read our Comments Policy first.  If you have any related links of interest, please feel free to add them as a comment for consideration.  

Copyright (c) 2009-2016 – Chris M Evans, first published on https://blog.architecting.it, do not reproduce without permission.

Please consider sharing!Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInBuffer this pageEmail this to someoneShare on RedditShare on StumbleUpon

Written by Chris Evans