In a recent post (this one on SRM), Wayne M Adams from SNIA took the time to comment as to why he believed SMI-S is alive and well. Rather than simply reply on that comment thread, I thought I would take the time to put together a summary of why SMI-S (in my opinion) hasn’t worked and will never work in the current incarnation.
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).
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.
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.
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.