Martin (Storagebod) has an interesting post today. Rather than post a long reply, I've chosen to steal his thunder and post specifically on the subject - of SRM tools.
Apart from when I worked in the mainframe storage arena, I've always struggled with SRM tools. Just for reference, the mainframe was great - SMS did the job, although there were a few shortcomings like the lack of quota tools. In the open world, things are so, so different. I think the reason open systems is a problem relates to the fact that although standards exist, technology is all different.
Look back at my recent post; there are two fundamental issues happening here. First of all, each vendor has a different implementation of technology - EMC/HDS/IBM/3Par/Pillar/Equallogic, the list goes on. Why are they different? Because there has to be something to create a USP, a differentiator. Sure, front-end technology might be consistent; each vendor will implement LUNs and the fibre channel standards, but in reality the back-end deployment will be different as each manufacturer competes on features and functionality. The same applies for the switch vendors, NAS vendors, and so on.
SMI-S was meant to address these problems but never would as it basically dumbs down each vendor to a single set of features and doesn't address the platform specific functionality. Try using IBM and HDS arrays from ECC (in fact, try managing EMC arrays like Clariion from ECC) and you'll fall at the first post. I won't even suggest trying to use any other product like HiCommand...
Some software vendors have tried to do cross-platform SRM. Think of Creekpath. It failed miserably to offer cross platform support because (as Martin rightly states) they never understood how Storage Admins did their work.
The answer to the lack of an SRM tool would be for an independent to develop one. However there's one major barrier to entry and that's the vendors themselves. All the major vendors make a tidy profit (Martin's cash cow) from their SRM tools - software without which you could do *nothing* but for which you are obliged to pay. Why would those vendors give up that monopoly position?
I've been working on a tool for some months (see here) which will provide cross-platform reporting, but full SRM is another step again. Without full vendor support, and by that I mean full knowledge of the APIs and interfaces to their products, not just the standard SMI-S providers - and advance notice and access to new features -then developing an SRM tool will be impossible.
However if anyone is prepared to pony up the cash, I'm still up for it!!
Tuesday, 2 December 2008
The SRM Conundrum
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
But why need it be complicated?
The end user wants to :
a) provision X amount of storage
b) to host Y
c) with SLA Z
I think, coming back to MartinG's post, that "we" as storage device implementors expose too much of the complexity to the end storage device users.
SMI-S should be able to cover these, and dare I say it, I was involved in the original 'Bluefin' spec as it was, back in ~2000.
We are actively looking to address this in SVC+ land, and simplify things, as well as IBM's other SRM toolkits.
As we move more to the online, (i can't bring myself to use the rain-bearing-things-in-the-sky) world, simplicity is the key.
Sounds simple doesn't it, but surely the guys that think up the little tweaks here and there at a low level should be the ones to make the decision if it would benefit LUN x or LUN y, or rather a LUN with an SLA of x or y?
Barry
Yes, that's true things should be simple, however, if storage arrays were genuinely self tuning, then we would be able to this. Some arrays today are that simple and capable (I guess you're alluding to XIV/Nextra in your comments) however most are not. Add in complicated requirements like three way replication, replication with multiple PIT copies, tiered data, thin provisioning and all of a sudden the SMI-S simplistic model falls down.
I have my own ideas which perhaps could be the subject of a future post.
Post a Comment