Everything you need to know about SMI-S

Posted on May 01, 2004

RssImageAltText

SNIA's storage management standard promises to facilitate the integration of both hardware and software.

By John Webster

Judging from last month's Storage Networking World conference, storage administrators are generally behind the efforts of the Storage Networking Industry Association (SNIA) to develop a common, open storage management interface based on the Distributed Management Task Force's (DMTF's) Common Information Model (CIM), now known as the Storage Management Initiative Specification (SMI-S). And storage vendors now report an increasing number of request for proposals (RFPs) mandating SMI-S-compliant storage devices and management applications.

Storage networking users understand that the value of open standards—for both users and vendors—stems from a user's ability to select the most suitable products for a particular application or set of applications and then easily integrate those products into their computing environments. SMI-S provides a uniform way to integrate storage devices with storage management applications, as well as storage management applications with each other.

Today, device and management applications vendors are building, testing, and introducing SMI-S-compliant storage products, allowing users to begin matching SMI-S-compliant arrays, for example, with SMI-S-compliant management applications. However, it is important to note that not all SMI-S-compliant solutions are created equal. There are key differences in the way the standard is being implemented—distinctions that will become important as time goes on. To fully appreciate the significance of such differences, users must be able to discern between solutions that are CIM-compliant and those that are truly CIM-built.

The basics

SMI-S is a vendor-neutral application programming interface (API ) specification that can be built into networked storage devices and management applications. SMI-S is based on the DMTF Web-Based Enterprise Management (WBEM) architecture, a set of standards for the management of disparate devices residing on an enterprise computing network. The WBEM "pyramid" is supported by three open standards:

  • The DMTF's Common Information Model (CIM);
  • XmlCIM—an XML coding specification created specifically for CIM; and
  • HTTP—a transport mechanism that enables open, interoperable communications among management applications and managed devices that conform to CIM.

The WBEM architecture has been adapted to networked storage environments. In its first iteration, SMI-S will support a number of storage area network (SAN) management functions in an open, device-neutral way:

  • Discovery—The automatic identification and registration of devices (host bus adapters [HBAs], switches, arrays, and tape drives) on a SAN.
  • Monitoring—A continuous observation by a management application of SAN fabric health and the operation of each device within a SAN.
  • Device management—The active control, configuration, and reconfiguration of SAN-attached devices.

While individual device control can be performed manually by IT administrators today, one of the goals of SMI-S is to automate this management in a heterogeneous SAN fabric. Another goal is to establish a Web-based interface that is common to all devices in a SAN. Without SMI-S, this type of communication and management is only possible through a variety of different and proprietary interfaces.

Users looking at SMI-S for the first time should keep the following basic concepts in mind:

SMI-S is a model—SMI-S is a guide to building systems using modules that "plug" together. SMI-S-compliant storage modules interoperate in a system (in this case, a storage fabric) regardless of which vendor built them, provided that the modules use CIM "language" and adhere to sets of specifications called CIM schema.

SMI-S is object-oriented—Virtually anything storage-related—physical or abstract (from complex device management applications to bad sectors on a disk platter)—can be defined as a CIM object. A system (e.g., a storage fabric) is modeled using objects that have defined attributes. In addition, any object known now or yet to be developed can be defined and encompassed within the model. The SMI-S object orientation allows storage fabrics to scale and adapt to changes in technology over time.

SMI-S is command- and control-oriented—Unlike SNMP (which is now commonly used to integrate storage management applications at a basic level), SMI-S is both passive (like SNMP) and active, allowing management applications to not only monitor devices within a storage fabric, but also to dynamically configure/reconfigure devices. Command and control of both devices and fabrics can be automated using SMI-S-enabled storage management applications. SMI-S helps to unlock some of the unrealized benefits of intelligent storage fabrics in ways that SNMP cannot.

SMI-S provides a single unified view of a SAN—SANs are often thought of as single entities, commonly depicted as clouds or referred to as fabrics. SMI-S allows developers to model a SAN as a single, abstracted entity.

Providers, clients, and agents

At a very basic level, SMI-S entities are divided into two categories: clients and providers. Clients are management software applications that can reside virtually anywhere within a network provided they have a physical link (either within the data path or outside the data path) to providers. Providers are the devices under management within the storage fabric. Clients can be host-based management applications (e.g., storage resource management, or SRM), enterprise management applications (e.g., frameworks), or SAN appliance-based management applications (e.g., virtualization engines). Providers can be disk arrays, host bus adapters, switches, tape drives, etc.

Providers communicate with clients via agents that perform a number of functions:

  • Act as a repository for information about a specific device;
  • Enable the discovery of the device by management applications;
  • Communicate events and perform status monitoring; and
  • Enable interoperable configuration and control.

The SMI-S model also describes two additional entities: object managers and lock managers. Object managers can be used as extensible agents by aggregating multiple devices under the control of a single agent. They can also be used as persistent repositories for information about multiple devices. Lock managers allow multiple clients to concurrently communicate with a single provider. The lock manager reserves a provider-associated agent at a given moment in time so that a particular client can perform an operation (e.g., a query or a command); it then releases the agent to another client.

For vendors: A direct route

The SNIA's Storage Management Forum, which is tasked with development of the SMI-S standard, provides two different routes for vendors to achieve SMI-S compliance. One route allows vendors to attach a "proxy" interface that "translates" an existing product interface into an SMI-S-compliant interface. The proxy approach is used by vendors to make existing products SMI-S-compliant without significant re-engineering of the product's management interface.

The more direct route to SMI-S is through the creation of a "native" SMI-S-compliant interface. In this case, the product's management interface is both SMI-S- and CIM-compliant by design. Because a native implementation is likely a more robust implementation of the CIM model, it makes it easier to take advantage of future releases of SMI-S. Advantages of native providers include

  • Faster delivery of new products and features—Native SMI-S support enables shorter development cycles because vendors do not have to maintain proprietary interfaces.
  • Extensibility—Native SMI-S providers can be easily extended to support new SMI-S features.
  • Easier manageability and lower TCO—Native SMI-S providers do not have to be mapped to a proprietary data model, making them less complex and costly to maintain over time.


Figure 1: SNIA's Storage Management Forum provides two routes to SMI-S compliance: via a native interface (left) or a proxy interface (right).
Click here to enlarge image

The two approaches to SMI-S compliance are shown in Figure 1.

For management applications: Flexibility

Constructs defined by CIM can be applied to three different storage management layers: the device layer (which includes all devices under management), the management data layer (which contains management-related data that can be used by any storage management application), and the management application layer.

SMI-S can adapt CIM constructs to all three layers such that storage management applications from multiple vendors can use all three layers in common ways. This allows vendors to integrate applications without swapping proprietary APIs.

Device layer

The SNIA Storage Management Forum has developed CIM-based device management interfaces described in the previous section as "providers." Providers present a standard interface that is the same for all SMI-S-compliant management applications.

Management data layer

Data relating to infrastructure, configuration, policy, etc., can be collected in a CIM-compliant repository, which can then be used by any management application capable of supporting the repository to store and retrieve management data. The data within the repository is presented to the management application layer in a format that all management applications can understand.

Management application layer

Storage management applications interface directly with devices under management (the device layer) and use management data contained within a common repository (the management data layer) to perform management tasks. CIM can be used to create a common management application-to-application interface, allowing the services of one application to be "exported" to another. (An example would be an archiving application that uses a separate data mover application to transfer data from one device to another.)

CIM-compliant vs. CIM-built

To achieve these services "export" capabilities, the management application should be CIM-built, as opposed to CIM-compliant.


Figure 2: A CIM-built management application (left) writes data from an SMI-S client directly into a CIM-compliant data source. In contrast, a CIM-compliant management application (right) translates data from an SMI-S client into a proprietary data source.
Click here to enlarge image

As shown in Figure 2, the CIM-built management application on the left writes data from the SMI-S client directly into a CIM-compliant data source. This enables other CIM/SMI-S management applications to work directly with its data source and enables its "services" to be driven by other management applications. The CIM-compliant management application on the right in Figure 2 translates the data from its SMI-S client into its own proprietary data source. Other CIM/SMI-S management applications are not able to use this data source and are not able to access its services because these services are not modeled after CIM. For end users, the potential benefits of CIM-built management applications include the following:

  • Flexibility—The pure CIM data source of a CIM-built management application can be accessed by any other CIM-built management application, enabling management architectures such as information life-cycle management (ILM) and unique features of best-of-breed solutions to be easily leveraged. At the same time, support for both SMI-S-enabled and non-SMI-S-enabled devices can be accomplished.
  • Less risk of vendor lock-in—New management applications can be substituted easily without losing any capacity, performance, history, or discovery information.
  • Extensibility and scalability—CIM-built management applications can be easily extended to support new SMI-S and CIM features, without requiring a significant translation effort to map these features to proprietary formats.
  • Lower cost—CIM-built management applications model all physical and logical storage resources in a normalized way, resulting in lower training costs, faster ramp-up by storage administrators, and lower ongoing ownership costs.

IT administrators looking to adopt SMI-S as their standard storage management interface will want to build a solid SMI-S foundation. This means that early on in the process of product selection, they will need to identify devices that are SMI-S-compliant and management applications that are both SMI-S-compliant and CIM-compliant on all three of the levels outlined above. Doing so will allow them to integrate "best-of-breed" management applications for a particular set of tasks, regardless of vendor. (See "Recommendations for users," p. 28.)

Integration of disparate but related storage management applications will likely be required by IT administrators wishing to architect future storage environments to incorporate ILM concepts and processes. Users may be reluctant to adopt an ILM strategy that forces them to rip out existing but disparate data and infrastructure management applications simply to replace them with ones that can be integrated only if they come from a single vendor.

Rather, IT administrators are likely to implement ILM processes from "best-of-breed" products that can be functionally integrated, which is enabled by CIM-built management applications. It also addresses other requirements that are important to storage administrators, including the following:

  • The ability to manage all devices on a SAN with a single, consistent, Web-based user interface;
  • The ability to add devices to a SAN in "plug-and-play" fashion so that administrators can continue to scale the storage infrastructure as well as add diverse technologies without breaking the existing storage management framework;
  • The ability to go beyond passively monitoring a SAN to an environment where devices can be actively controlled and configured by automated management agents;
  • Further integration of SAN management functions with enterprise management frameworks; and
  • The ability to manage Fibre Channel SANs and IP SANs with the same management application.

In addition, SMI-S promises to reduce SAN costs both directly and indirectly. Providing an open, standard API model reduces management application development costs. Management software vendors are relieved of the financial burden resulting from sourcing, adapting, and supporting a collection of proprietary APIs. The reduction in development and support costs can be passed on to users. SMI-S also promises to significantly reduce the storage management burden on administrators. In short, an intelligent storage fabric allows IT administrators to manage more data with fewer staff.

Adoption of SMI-S technology could also result in a reduction in SAN costs. While large enterprises have been the primary adopters of SANs, small to medium-sized businesses (SMBs) represent a large, untapped opportunity for SAN vendors. SMI-S makes SANs easier for SMBs to deploy and support over time.

John Webster is founder and senior analyst at the Data Mobility Group (www.data mobilitygroup.com) in Nashua, NH.


Recommendations for users

For users interested in building an SMI-S-based management foundation—one that will allow a number of storage management applications to be integrated into a coherent framework—we recommend asking the following questions before you select storage infrastructure and management applications:

For storage devices:

  • Is the SMI-S provider native, or based on a proxy model?
  • If a proxy is used, when will a native version be available?
  • Can the proxy version be replaced by a native version? How easily?

For management applications:

  • Does an SMI-S client write directly to the management application database using the CIM data model?
  • If so, can other CIM-built applications use the database without exporting it to other formats or modifying the data?
  • Are hosts, HBAs, fabric switches, and disk subsystems from different vendors represented in exactly the same way, according to SMI-S, for common management?
  • Is SMI-S support included as a standard product capability, or is it priced separately as an option?
  • Has the management application been used to demonstrate SMI-S compliance at interoperability plugfests?

For both:

  • To what degree has the vendor implemented the functionality in SMI-S?
  • Has the product passed SNIA's certification process?

SNIAonstorage

Recent SMI-S developments

By Ray Dunn

The Storage Management Initiative Specification (SMI-S) recently reached several significant milestones. Over the last two months, SMI-S has been

  • Submitted to ANSI through the International Committee for IT Standards (INCITS) "fast track" to become an official industry standard;
  • Implemented in more than 100 products announced at Storage Networking World (SNW) in early April; and
  • Tested for conformance in more. than 100 products by the SNIA-Conformance Testing Program (SNIA-CTP), which means the products are conformant to the SMI-S version 1.0.2 specification.

SMI-S was developed to deliver a reliable interface that allows storage management systems to identify, classify, monitor, and control physical and logical storage resources.

The present scope of SMI-S version 1.0.2 includes the entire set of devices that connect to a storage area network (SAN), such as disk arrays, tape libraries, switches, and host bus adapters (HBAs). The specification covers fundamental management operations between storage devices and storage management applications in a storage network. These include auto-

discovery, access, security, the ability to provision volumes and disk resources, LUN mapping and masking, and other active management operations.

The functionality focus of version 1.0.2 of the specification targets the day-to-day activities of storage administrators. Products that implement the specification will reduce the complexity of managing complex storage networks.

The SNIA-CTP is the testing process used to validate the implementation of SMI-S v1.0.2 and ensure that products conform to the SNIA standard.

At SNW, 14 companies announced more than 100 products that have passed the SNIA-CTP conformance test. These companies include Brocade, CNT, Dell, EMC, Hewlett-Packard, Hitachi Data Systems, IBM, LSI Logic, McDATA, Network Appliance, QLogic, SGI, StorageTek, and Sun Microsystems.

Presently, SMI-S is being implemented in "storage providers," which are mechanisms for representing

hardware devices to management applications.

Storage management software applications are the consumers—"clients"—of the SMI-S interface. Software vendors have been involved in the development and testing of SMI-S through SNIA's SMI-Labs at the SNIA Technology Center in Colorado Springs. Storage management software vendors have been using the SMI-Lab to accelerate SMI-S client development in a collaborative testing environment.

End users looking to ensure that a vendor's SMI-S implementation conforms to the SNIA standard should look for officially "badged" and tested products, and they can check the www.snia.org Website for additional details.

Ray Dunn is chair of the SNIA Storage Management Forum.


Comment and Contribute
(Maximum characters: 1200). You have
characters left.

InfoStor Article Categories:

SAN - Storage Area Network   Disk Arrays
NAS - Network Attached Storage   Storage Blogs
Storage Management   Archived Issues
Backup and Recovery   Data Storage Archives