Has SNIA’s SMI-S failed?

“We’re not enamored of truth. It is too often painful, discouraging and it tends to undermine our self-image. We prefer comfort. Reassurance. Well being. Good Cheer. Naked optimism. Nobody wants to hear the facts when they clash with a happily imagined reality. It is after all, a terrible thing to be the only person in town who can see what’s really happening" [from “Odyssey” by Jack mcDevitt].

To IT data center storage vendors: Are you fooling yourselves about SMI-S? Is SMI-S relevant anymore? Is anybody really implementing it? And where is that mystical standards-based storage management console? All difficult questions and, I fear, with unpleasant answers. It’s been over 5 years since SMI-S was first kicked off. The truth must be faced. I’m not seeing truly complete standards-based storage management implementations. I mean implementations that completely manage a storage system or device within the confines of SMI-S, even assuming a few vendor unique extensions – which, btw, are allowed by the spec.

At this point, you may be scratching your head and wondering what SMI-S stands for. If you don’t know, stop reading this blog unless you relish the anticipation of a possible train wreck. For those who do, you may be wondering about my sanity or nodding your head in agreement.

Let us digress. For some education, go to this link and take a look at the SMI-S document. I'll wait. It might be awhile - the spec is over 1000 pages.

SMI-S is very complicated with a lot of loose ends but it CAN BE MADE to work.

The promise of SMI-S is simple: By getting storage vendors to instrument their gear in a standard way, theoretically, a single management infrastructure with a single console could manage multi-vendor storage environments in a common way. Sounds great doesn’t it? We all dream about this interoperability.

Trouble is, no-one-bothers in a serious fashion.

Sure, some of the top tier players - two, three, and four letter names – do implement some of SMI-S in their products. But it’s the “some” part that’s the rub. I frequently tele-conference with enterprise class storage subsystem vendors– large and small – to hear their latest, and I usually ask this question: Do you implement or plan to implement SMI-S? If so, how much and when? …Far and away, there’s a pause, I hear some shuffling and throats clearing, and get one of two answers: “we are watching that space and will provide an implementation when our customers ask for it”. In other words: forget about it.

Or I get told: “Yes, we do!”

And I ask: “Completely? Does that mean I don’t need your management application to configure and monitor your gear?”

And they respond: “Well, ah, no…”, again paper shuffling and whispering….

Back in June, Burton Group held its annual Catalyst Conference. During the conference, Drue Reeves (VP & Research Director) challenged the industry with his “count-down to interoperability”. He asked, “when will truly interoperable, standards-based storage management applications and instrumented systems be available?” He gave a one-year time frame – I fear he will be disappointed.

So has SMI-S failed? Will vendors seriously implement it? Vendors please let me know. Tell me you are nearly there. After all, as a matter of confession, I and others at Burton Group contributed to the spec and know many very smart people who have worked long and hard on it.

I want to see it succeed.

But what do I tell my clients asking for a unified storage management environment?

If SMI-S has failed then what went wrong? Did vendors realize or anticipate that cooperating to make their equipment interoperable - at a management level - hurt revenues? Did storage systems get so complex and feature rich, that the modeling approach taken is too detailed? Or, is it simply that SMI-S is too complicated and vendors don’t see the payback for investing precious development dollars on it?

I suspect it’s all of the above.

Perhaps a new approach is needed.

Enterprise class storage subsystems have become feature rich over the past few years – what top tier vendor doesn’t do thin provisioning, tiering, replication, etc. All these features are uniquely implemented and a cause for vendor differentiation. The real value of these new features is the delivery of a Quality of Service (QOS) such as data protection, scalability in the face of data growth, performance, and the like. Unfortunately, SMI-S focuses on the down and dirty modeling of the internal specifics of these features – the place where vendors innovate and add their secret sauces.

I’d suggest a new approach: model storage management based on QOS or, more simply, service delivery. For example, rather than modeling the intricacies of thin provisioning or RAID sets, instead, through standard api’s, identify that the equipment supports specific features characterized by key standardized parameters associated with each feature. Why should users specify what disks go into a RAID set? Instead, let them define the level of redundancy and expected performance, letting the equipment figure it out from there. Some vendors already do this in a proprietary way – it's not a new idea. This can be conveniently modeled with XML.

So, back to the main question: Has SMI-S failed? What do you think? Is there hope or should the storage industry rethink how to achieve interoperability in IT data centers or, more to the point, do vendors want to do it to begin with? Where does the SNIA board stand on this issue? After all, the members represent the vendors whom this blog is addressed to.

I know one truth for sure: IT data center customers want storage management interoperability and they want it now.

Posted by Gene Ruth

Comments

[Steven Schwartz - The SAN Technologist]

I think SMI-S is alive and well, just as WMI and SNMP are. Is it the silver bullet for storage management that SNIA attempted to proliferate? Nope, but there are many products that still support it.

I think the biggest problem with CIM and SMI-S was the original problems with providers, many of them requiring software to interact with API sets rather then having native internal support. Just my .02$

[Gene Ruth]

The problem is, while technical folks have worked hard on the spec, there are no comprehensive products that use it. Users still are forced into the vendor proprietary tools to completely manage storage devices. How many years must we wait for this effort to be realized?

[Drue Reeves]

Hi Steven,

Thanks for the comment.

It's hard to say that SMI-S is alive and well when 1) the providers that do exist support only the mandatory portion of the profile. Sure, that passes the SMI-S compliance test (which is a joke), but it hardly qualifies as something another console vendor would use to achieve interoperable management. 2) Storage vendors without an SMI-S provider outnumber those that do. Yes, larger vendors have a provider, but what about the hundreds of smaller vendors out there? 3) Few, if any, storage management consoles use SMI-S such that they can claim cross-vendor interoperability (the original value prop for CIM and SMI-S). Can we think of one that uses SMI-S to do any type of configuration (just one) on HP, HDS, EMC, Dell and IBM arrays, NAS, or Host-based RAID controllers?

Providers are the go-between that translate proprietary APIs and data models into the CIM namespace. Sure, they could be "embedded" within the device, but some devices don't have the CPU or memory to house a CIM provider (and some vendors don't want to put CIM inside their device), and that's why the proxy model lives on.

In the end, it's a lack of vendor incentive that hurts SMI-S and CIM. The technical issues are substantial, but the lack of vendor incentive and customer demand is worse.

[Robert Wipfel]

> I’d suggest a new approach: model
> storage management based on QOS or,
> more simply, service delivery.

Service delivery as defined by ITILv3?

Perhaps a storage mgmt API that's designed for IT services? not necessarily needing to expose the underlying resources (until one needs to correlate resource relationships for e.g. impact analysis when the Service Level Agreement is violated by a resource specific failure)? where services are aggregations of resources; and CIM and CIM based SMI-S are actually resource (not service) models. Higher order schema and APIs are required for IT service management. Something like this:

CreateVolume(name, qos)
AssociateVolumeToService(volName, svcName)

BTW, seems like I remember that Jiro; the Federated Management Architecture; which led to SMI-S, had some of these ideas too.