« HP - what are they up to with the LeftHand purchase? | Main | AMD Takes A Gamble »

October 09, 2008

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83514402453ef0105356e0c1c970b

Listed below are links to weblogs that reference Has SNIA’s SMI-S failed?:

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.

The comments to this entry are closed.

  • Burton Group Free Resources Stay Connected Stay Connected Stay Connected Stay Connected



Blog powered by Typepad