“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