So let’s start with what SMI-S means.  Here’s the official definition from the SNIA website:

“The Storage Management Initiative-Specification (SMI-S) is a standard designed with the purpose of standardizing and streamlining storage management functions and features into a common set of tools that address the day-to-day tasks of the IT environment.” – source http://www.snia.org/forums/smi/tech_programs/

So it’s all about standardising and streamlining storage management.  This makes perfect sense in some environments but not others, for example:

• Single Vendor, single product – where an organisation uses a single vendor and a single product (i.e. one type of storage device) then SMI-S provides no value as the user is almost certainly going to be using the vendor’s management tool.  This will have been provided free (or most likely bundled in the price).
• Single Vendor, multiple products – where an organisation takes more than one storage device from a vendor, then SMI-S is still going to be of limited value.  The customer will use either the individual management tools for each platform or a product from the vendor that supports multiple products, such as EMC’s ControlCenter or Hitachi HiCommand.
• Multi-vendor, multiple products – this scenario is where SMI-S is most useful.  In large, complex environments, there will be a range of different products with multiple management tools.

If SMI-S worked successfully, the complex multi-vendor infrastructures, would be the best fit.  Unfortunately by their very nature they have issues which prevent SMI-S working successfully.

Speed to Market

Here’s the timeline of SMI-S releases (source: http://en.wikipedia.org/wiki/SMI-S):

• • 2004 – SMI-S 1.0.2 (2 years to develop)
  • 2006 – SMI-S 1.0.3
  • 2007 – SMI-S 1.2.0
  • 2009 – SMI-S 1.3.0
  • 2010 – SMI-S 1.5.0

In this 8 year timeline, vendors have released whole families of new products, as well as multiple code updates and releases.  However, as this link shows, there are no storage array providers supporting SMI-S 1.5.0 and of the 27 vendors listed, only 9 have been confirmed as tested with version 1.4.0.  Netapp have no products tested higher than version 1.2.0.  Cisco have nothing higher than 1.1.  As for client software, no testing has been performed past version 1.1 (link).

Participation

It’s clear from some of the information presented above that not all vendors are participating fully in SMI-S, Netapp being a prominent example.  In addition, the client software certification, probably the most relevant part to end customers looking to use one single management “pane of glass” shows vendors aren’t putting forward their latest products.  For example:

• HDS’s latest version of HiCommand listed is 5.0 (v7 is already available)
• EMC’s latest version of ControlCenter is 6.0
• CA’s latest version of Storage Resource Manager is 11.6 (latest release is 11.8)

As soon as a dependency is put in place between the management software and the storage array, restrictions apply when deploying new products.  Customers want the confidence that when a new hardware product is released, the software support will follow quickly.  New hardware implies new features, likely to be only described in latest SMI-S specification releases.  If the software vendors aren’t supporting these, then the “single pane of glass” approach is flawed as the customer has to fall back to the management tool that shipped with the product.

The Message

Now of course the SNIA website could be out of date and in itself that is an issue if true.  However I think SNIA fundamentally has a problem with the message.  SNIA is an Industry Association and so is surely dedicated to improving the industry on behalf of their members – the vendors.  Where is the customer community participation?  On the technical council, all the members are vendor representatives (bar one).  Unfortunately SNIA doesn’t list the membership of the Technical Working Groups on their website but I suspect that customers are not well represented.  SNIA should have a clear and well documented process for engaging customers and conveying the message on what SMI-S actually does. Look at this definition of SMI-S from the SNIA website:

“SMI-S defines a method for the interoperable management of a heterogeneous Storage Area Network (SAN), and describes the information available to a WBEM Client from an SMI-S compliant CIM Server and an object-oriented, XML-based, messaging-based interface designed to support the specific requirements of managing devices in and through SANs.”

But what does this mean for me as a customer?  What functions can I do?  Reporting?  Provisioning?  Management of replication and snapshots?  What additional software to I need?  Is SMI-S supported using the same security model for each vendor?  Does it use the same access protocol for each vendor?  SNIA and their members need to provide clear and concise information on exactly what customers can expect, rather than having to wade through pages of specifications.

Summary

Today I still see the large, complex clients using the command line to do their storage management.  There’s still a dependency on spreadsheets for reporting and the “normalisation” of capacity data isn’t well presented.  Rather than having a common management model, we’re seeing the hardware vendors developing their own plug-ins for the virtualisation layer, something that should be unneeded if SMI-S support is truly ubiquitous.  The truth is that it isn’t and the industry will never adopt a common management framework anytime soon.

Now, it’s no secret that I’m keen on the idea of Cloud Computing (and to be more precise, cloud storage in particular), so the concept of evolving standardisation is extremely exciting.  Last year, I discussed RAIC (here and here) – the concept of using multiple clouds to form a redundant repository.

Too Early?

Whilst on the one hand I agree with Stephen that it may be too early for standards to be set, I would also contend that for certain pieces of the cloud storage infrastructure we do need standards, for example security and authentication.  It would be useful to have a consistent authentication model to be applied across cloud storage infrastructures, especially if in the future the ultimate evolution of cloud storage (and for that matter cloud computing) is the ability to dynamically switch workloads and data locations based on service quality (i.e. cost and performance) and availability.

Of course, there will always be the eternal tradeoff between standardisation (which suits the customer) and proprietary interfaces and functionality (which suits the vendor).  Get a customer hooked into proprietary technology and the inertia to change becomes much increased, so even if another vendor does offer a better solution, the cost and effort of change is too great to make the savings/benefits worthwhile.

New Business

Does this mean initiatives like Zend and Cloudloop offer an insight into new business opportunities?  I think they do.  Most, if not all of us will not interface directly with Amazon S3, Nirvanix, Atmos, Rackspace and the others that will spring up.  These companies are infrastructure, not application, providers.  Taking the UK as an example, do I care where or how my electricity is generated or where my gas comes from, as long as it is available when I need it?  No.  Whether the cloud storage infrastructure providers (CSIP) choose to standardise isn’t important.  The future is how easily we can interface into the cloud, and how services such as the following can be easily delivered:

• Create/Retrieve/Update/Delete (CRUD)
• Search
• Index
• Migrate

and of course the influencing factors will be:

• Cost
• Availability
• Performance

Today there are plenty of companies offering services based on cloud storage – exclusively targeting the consumer market or limited business features such as backup.  As things evolve, we’ll see opportunities to move into the Enterprise space.  These will take advantage of extending the data space into the cloud, giving us new and interesting ways of managing data.  Here are some ideas I want to explore in upcoming posts:

• Extending the Global Name Space into the Cloud
• Block-based array tiering and the Storage Cloud
• Using the Storage Cloud for data migration
• Archive, Backup and the storage cloud

Anyone have their own ideas they want to share?