A new standard for storage management promises to make integrators' lives easier
The long-awaited quest for standard APIs that allow storage-management software to link to any disk array is finally over"or maybe it's just beginning. The good news is SMI-S, the Storage Management Initiative-Specification, is now officially a standard.
However, like the first iteration of any standard, SMI-S has its limitations, and it could still take years before it provides true multivendor interoperability.
Before harping on where SMI-S falls short, it's important to note how far SMI-S, submitted to the American National Standards Institute by the Storage Networking Industry Association (SNIA), has come. Five years in the making, SMI-S is based on the Distributed Management Task Force's Common Information Model and Web-Based Enterprise Management standards. In the storage world, SMI-S is akin to the Simple Network Management Protocol, the standard for managing and monitoring network devices on a LAN or WAN. To date, more than 100 products are certified as SMI-S-compliant, and the number grows daily. Just about any vendor providing storage hardware and management software has voiced support for SMI-S. Among those are Brocade, CNT, EMC, Hitachi, HP, McData, Network Appliance, StorageTek and Sun.
The standardization and broad support for SMI-S is an important milestone because there is now a common schema for choosing storage-management applications and hardware. In other words, you can recommend one disk array now and a different vendor's SMI-S-compliant disk array down the road, knowing full well the management software can handle such tasks as the provisioning and monitoring of different suppliers' hardware. Likewise, if you want to use EMC's new Control Center 5.2 software or Tivoli SAN Manager at one location and HP OpenView at another site, that, too, becomes feasible.
The ability to mix and match should make it easier for a VAR to sell systems from, say, Hitachi, IBM or NetApp into an EMC shop because the new EMC Control Center 5.2 management interface can provision and monitor any SMI-S-compliant disk or storage subsystem.
"There's no lockout based on the fact that I'm not going to be able to manage the solution with the existing management application that I have," says Nancy Hurly, a senior analyst at Enterprise Strategy Group, a Milford, Mass.-based market research firm. Indeed, such a move had required proprietary interfaces, though SMI-S still presumes vendors will rely on proprietary extensions while the standard is still in development. Likewise, there are companies such as AppIQ that contend only native support for SMI-S, which it offers, will give customers the ability to view information in the management interfaces they use in the exact same formats.
The first implementation of the spec, SMI-S 1.01, provides common schema for the provisioning of a storage network, the monitoring and provisioning of storage subsystems, and for creating, mapping and masking LUNs. Among the key features not addressed in the current spec are snapshot management, replication, mirroring and support for NAS devices and tape libraries. To some extent, much of that will be pushed forward in the coming months as SNIA moves to advance the next release of SMI-S version 1.1. And just last month, SNIA began its SMI-Lab5 program at its Colorado Springs, Colo., test lab. The goal of the fifth SMI-Lab program is to move forward the SMI-S specification to address SMI-S 1.1. The program will extend through next April, but much of what makes it into version 1.1 will be determined this fall.
Whatever doesn't make it into that release will be put on the docket for the following release, 1.2, on tap for next year. Dunn says SNIA wants to hear from VARs and storage integrators to determine what could be added in the future.