It looks like the open storage management project Aperi has finally been put to rest. See this link.
Previously I've discussed writing SRM software and I've done just that with a company I've been working with for some months: http://www.storagefusion.com/. Whilst this might be a shameless plug, I can honestly say that as a product (in the reporting space at least) SRA will harmonise storage reporting more than anything else out there today. Here's why:- It doesn't rely on generic standards for reporting, but gets the full detail on each platform.
- It uses element managers or management console/CLIs to retrieve data.
- It doesn't need additional servers or effort to deploy or manage.
- It normalises all data to provide a simple consistent framework for capacity reporting.
Now reporting is good, but management is hard by comparison. Reporting on hardware doesn't necessarily break it - SRM software which changes the array could - therefore it needs to know exactly how to interact with an array and therefore requires decent API access.
Vendors aren't going to give this out to each other, so here's a proposal:
Vendors fund a single organisation to develop a unified global SRM tool. They provide API access under licence which doesn't permit sharing of that API with competitors. As the product is licensed to end users, each vendor gets paid a fee per array per GB managed so thay have some financial recompense for putting skin into the game.
Anyone interested?
Posts
7 comments:
Chris,
Its an interesting idea, but it makes no incentive for vendors to open up their APIs - in fact it does the opposite.
Chris,
As a former SE Director at Storability Software (first purchased by STK and then SUN) I'm curious as to why you think the customers are any more willing to spend the time, money and the effort for SRM reporting? When we were in business, we got killed over the fact that we didn't really do "management" which was fundamentally about provisioning. The fact that when STK was purchased by SUN and we sold AppIQ along with GSM didn't make any difference.
The second thing we got beat up on was the deployment of agents. We got a lot of push back. And of course the "agent-less" approach couldn't give file level details nor could it see into the vol managers to correlate what was allocated from the array to how is was actually dpeloyed in the vol manager to seeing what was on the file systems themselves.
But maybe the most significant issue was that customers resisted change, didn't want to establish broad-reaching policies and procedures to take advantage of the tons of data that were being collected by the SRM solution.
What has changed? (and don't say the economy because we were selling back when the bubble burst in 2001)
Care to expand Marc?
Marco
Good points:
1. Time/Money/Effort. SRA needs no deployment of hardware or software onsite. Configuration is collected by simple script and emailed/uploaded to a secure website. Results are available in minutes - and the charge is per TB analysed. Want to use it once and see what wasted resources you could reclaim? Fine.
2. All arrays have element managers which provide sufficient data. Same applies for fabric switches which can be collected by command line. Windows provides everything you need via WMI with a simple scripts. Other O/S can be collected in a similar manner.
What's changed? Nothing. Customers still want to save money and do it easily. SRA does exactly that, with the minimum of effort and cost. No CapEx, all Opex.
If you want more details, let me know.
Chris, If companies can generate incremental revenue from their closed APIs, why would they ever publish them openly and lose that revenue potential?
Chris,
I respectfully disgree with most of what you are saying.
From a technical perspective first:
WMI - last time I looked, WMI had no ability beyond reporting on used/available capacity of filesystems. There were no hooks that allowed you to look at the logical volume manager nor file-level details of those filesystems. So I don't think WMI was very useful. I have not looked at it in over a year so maybe that has changed.
On arrays and their details, the typical response from f500 customers was, so what? They already had their element tools providing that info. What they wanted to know was how the server admins were using the storage from the arrays. Again, w/out the server side perspective, there was no way to identify storage hidden in the Volume managers, orphaned storage or any other stranded storage out there.
As far as script collection, that's exactly what my customers wanted to avoid back then. Perhaps the scripts are much easier to write and keep updated these days.
The second point, and probably the more salient point is that of the end-users demeanor. They don't want to change, they don't want new processes and procedures and they don't want the hassle of dealing with their customers (business units, end users etc) about storage reclamation. I remember scanning a very large filer w/ home directories on it and I found terabytes of contraband and useless files they could have deleted. They didn't...they are probably still there :-) Until the customers change, SRM will never be relevant.
Marco
I appreciate your comments and I understand your point of view. Admittedly there will be customers who don't want to change and there are customers who are convinced they are managing their equipment efficiently. Unfortunately many of those customers aren't using their resources effectively and they could make considerable savings. Agreed, working with the business customer is tough, but we can't go on simply putting bigger, faster storage in and not address how/why it is being used.
Thanks again for the comments; opposing views certainly generates food for thought.
Post a Comment