During the CTO panel At SNW three weeks ago, I was asked by Geoffrey Moore, why HDS was not a part of Aperi, the open source initiative that IBM is proposing for Storage Area Management.

My response was that While HDS will support initiatives to drive open standards like SMI-S, we did not know enough about Aperi to make a decision at this time.

Aperi was announced at a press conference last Fall, with much attention as to which vendors were in and which were out. Joining IBM were Brocade, CA, CISCO, Engenio, Fujitsu, NetApp, McData, and SUN. Those not on the list were EMC, HP, HDS, Microsoft, and Symantec/Veritas. It is worth noting that most of the vendors that joined IBM would benefit from open source code that could be used to develop software to manage other vendors SAN products. Those that did not join Aperi already have this type of heterogeneous,Storage Area Management software which is based on standard interfaces known as SMI-S providers.

Today most storage and SAN hardware vendors make available an SMI-S provider which is based on a CIM model,to provide a standard interface for storage area management. Management software that uses these SMI-S providers are also known as SMI-S clients. These "clients", like IBM TSM, EMC ControlCenter, HP AppIQ, HDS HSSM, Symantec/Veritas, and Microsoft, discover, visualize, and provision heterogeneous storage products based on these SMI-S providers

Basically, what Aperi has proposed is an "open Source" code base for an SMI-S client. HDS' SMI-S client is HSSM, Hitachi Storage Systems Manager, which was developed through a partnership with AppIQ, now HP. We chose to work with AppIQ because it was the first Storage Area Manager that was developed on an open SMI-S/CIM architecture. Since its introduction in 2002, it has proven to be a flexible and extensible architecture which enables easy consolidation of heterogeneous SRM, SAN Management, provisioning, and application management. A major benefit is its ability to correlate the availability of business-critical applications with storage network capacity and performance, providing logical-to-physical application path management. 

While many will say that "Open source" code is goodness since it is made up of contributions that are free, a lot depends on the functionality, quality, and maintainability of that code. Vendors will benefit from free code, since it can shorten their development, and qualification effort. However, free code may not be free to the end user. Installing, using, and maintaining this code may require ongoing services charges from a vendor or service provider. A good summary of pros and cons of open source is provided by SearchCIO columnist, Paul Gillan in "Five Open Source Factors for CIOs

Speaking as an individual and not as an official HDS spokes person, my concern is more about the content and capabilities of this "open source" code. The details of the Aperi initiative are still to be known, but if IBM is the only SMI-S client code donor, this would push their implementation of the SMI-s client as some kind of de facto standard over other clients. Since this client would be the storage services interface to other applications, it is  a concern to me if IBM's implementation is the only base.

While open source code like Linux can run on commodity Intel servers and provide value to the user, storage is much more complex than a server and there are many more hardware architectures to deal with. Modular, two controller, storage arrays are generally pretty similar in functionality, (except for our AMS storage with adds cache partitioning) and may be provisioned in a standard way. However, high end arrays, are vastly different in architecture and functionality such as replication, provisioning, logging, partitioning, virtualization, etc, and will require multiple code bases or extensions. 

Since then, I have learned from our SNIA representatives, Vincent Franceschini and Ken Wood, that Aperi has approached the SNIA Board of Directors to be an initiative under SNIA. This  would require a change to SNIA's charter to enable SNIA to develop code. As you can imagine, there are a lot of details to be worked out in terms of charter, fees, IP, and other legal matters. This could be very interesting if the program is truly open and supports multiple open source bases. In the mean time we look for more details around Aperi.

Bookmark/Search this post with:
| | | | | | | |