Implementing SMI-S in the real world.

From the day storage networking was born, there were two basic interoperability issues to overcome. First, components that make up the physical network (disk arrays, switches and host connections) would have to work together in stable and predictable ways. Second, the software entities intended to manage those components would have to work in seamless, easily understandable ways to mask administrative complexity and minimize risk as networks scaled upwards.

Getting past the software management interoperability issues requires communications between networked storage devices and management applications. Typically, devices communicate their condition or "state" to a management application through an application-programming interface (API). With hundreds of devices and management applications available, and more coming to market each month, the number of specific device-to-management application API connections could multiply into the thousands. The Standard Management Interface was established to minimize the complexity and provide a consistent interface through which all networked storage devices can communicate. The specification developed by the Storage Networking Industry Association (SNIA) to define the interface is called the SMI Specification or SMI-S.

SMI-S Basics

SMI-S is based on the Common Information Model (CIM) and Web Based Enterprise Management (WBEM) standards developed by the Distributed Management Task Force (DMTF). For IT administrators confronting SMI-S, there are some basic notions to keep in mind:

* SMI-S is a model: SMI-S is a guide to managing storage networks using standard connectors that "plug" together and function in consistent, predictable ways, regardless of who built the connectors.

* SMI-S is object-oriented: Anything storage-related, physical or logical, from disk array to tape robots, from volumes to snapshots, can be defined as an object. In addition, any object known now or yet to be invented can be defined and encompassed within the model. SMI-S' object orientation allows storage fabrics to adapt to changes in technology over time without blowing up the model and starting over again.

* SMI-S is command-and control-oriented: Unlike SNMP which is now commonly used to monitor the state of devices at a basic level, SMI-S is both passive (like SNMP) and active. SMI-S offers a common way for management applications to not only monitor devices within a storage fabric, but dynamically configure/reconfigure devices as well. Command and control of both devices and fabrics can be automated using SMI-S-enabled storage management applications. SMI-S helps to unlock the benefits of intelligent storage fabrics in ways that SNMP cannot.

Clients, Providers and Agents

SMI-S defines profiles for both physical and logical entities. Physical objects include disk arrays, switches, HBAs, etc. Logical entities include files, volumes, zones within a SAN, etc. A profile exposes data about an object-"hooks"--that are important from a management standpoint. These hooks can be used to actively manipulate objects under management.

Profiles are divided into two major categories: clients and providers. SMI-S defines software management tools as "clients," and networked storage devices as "providers" (Figure 1). Clients can be diverse applications such as SRM tools, logical volume managers, and backup and recovery applications. Providers can represent both physical and logical entities, as well. Disk arrays, for example, can be providers, as can each data volume defined within an array.

[FIGURE 1 OMITTED]

SMI-S clients and providers communicate with one another using standard protocols. SMI-S specifies a protocol stack consisting of CIMxml to describe object and management actions, http to manage session traffic, and TCP/IP as the transport and interconnect media.

To make it easier for software developers to write SMI-S-compliant providers, the SNIA is developing an open SMI-S-based object model repository for device information. The repository includes different classes of managed devices such as disk arrays, tape transports, NAS appliances, and switches.

The SNIA has made SMI-S easy to adopt and implement for vendors of both clients and providers. Device vendors can get SMI-S-compliant products to market quickly using proxies that convert or "map" existing device management APIs into SMI-S interfaces. Eventually, vendors can build "native" agents into new products.

The SNIA clearly understands that its vendor members must be able to innovate and differentiate. SMI-S cannot reduce all products to a least common denominator. To that end, SMI-S object models are extensible--vendors can add new devices and value-added functionality to the existing model.

The Impact of SMI-S

For independent vendors, SMI-S greatly simplifies software development and support efforts, while enabling vendors to extend the scope of product support for applications and storage devices. For instance, Storability Software (a provider of Enterprise Storage Resource Management solutions) developed Global Storage Manager, a storage management solution for multi-vendor environments. Rather than creating dozens of vendor-specific device agents, the company can create a single SMI-S-compliance client per device type (host, array, switch, etc). That single client can then communicate with each vendor's SMI-S provider or proxy and return consistent data across mixed-vendor environments. SMI-S also allows Storability and other vendors to extend their product offerings to deliver next-generation tools that deliver automated business-driven storage management solutions that address critical enterprise information lifecycle management (ILM) strategies.

The Global Storage Manager is also a prime example of how IT administrators can benefit from SMI-S. By requiring SMI-S providers in the devices they purchase, administrators eliminate the need to deploy and maintain agents for each managed device. The ability to forego agents on servers, in particular, will be a huge benefit because a typical enterprise has thousands deployed. In addition, the consistency of the data returned, enforced through the common data model, reduces the vendor lock-in associated with today's proprietary management interfaces. SMI-S also eliminates the need for administrators to implement and support a growing list of device and management-specific APIs. Proprietary APIs are replaced by a standard set of software-based "plugs and sockets."

Adapting SMI-S to the Data Center

Initially, IT administrators will see storage devices that present SMI-S profiles to management applications, using the proxy model shown in Figure 2. Realistically, users can begin to deploy a limited number of SMI-S-enabled storage management functions starting in the fourth quarter of 2003 and extending through the duration of 2004.

[FIGURE 2 OMITTED]

Beginning in 2005, vendors such as Storability and other members of SNIA's SMI Forum will have adapted more products to SMI-S, and devices supporting native SMI-S providers will be more commonly available. At that point, a wider range of devices will be SMI-S manageable, and the list of supported functions will have grown as well.

IT administrators can begin a phased implementation of SMI-S starting now with management applications that support both proprietary and MI-S enabled APIs. As time goes on, devices supporting only proprietary APIs can be phased out while the management application is easily adapted to newer SMI-S-compliant devices.

The Importance of Certification

To achieve true storage management application interoperability within real-world operating environments, client and provider implementations for specific devices and management applications must be tested and certified as compliant with the specification. The SNIA has inaugurated an Interoperability and Conformance Testing Program (ICTP) and is currently building test suites for measuring vendor product compliance as well as testing the consistency and maturity of the evolving specification development process.

The SNIA has also inaugurated the SMI-lab to provide vendors with the means to test client and provider implementations with those produced by other vendors. The goal is to reproduce a real-life operational environment in which to measure SMI-S compliance.

Next Steps for IT Administrators

The future success of SMI-S depends heavily on how well it is received by IT users and how well administrators communicate their requirements to vendors. So far, the user community has indicated strong support for SMI-S objectives through surveys and enthusiastic response to SMI-S concepts at industry events. Now, this community must communicate its desire to see widespread adoption of SMI-S by storage vendors.

One way to do this is through the Request for Proposal (RFP) process. IT administrators can begin to specify that storage devices have built-in SMI-S providers. Ideally these should be embedded, but for now proxy models should be acceptable as vendors roll out upgrades to their existing product lines. Important details to verify in an RFP include:

* Management applications: Is support included for both SMI-S clients and proprietary device APIs?

* Storage devices: is the SMI-S provider native or based on the proxy model? When will a native version become available?

* Is SMI-S support included as a standard product capability, or is it priced separately as an option?

* What functionality is included with SMI-S support?

* If implemented, what extensions have been made to SMI-S-based functionality?

* Has the product been certified as SMI-S compliant by the SNIA's ICTP?

Conclusion

Storage networks are defined by their infrastructure components and the software management applications that provide a human interface. They are complex entities requiring an ability to adapt to change over time. Standard interfaces such as SMI-S allow administrators to add and replace storage networking components without fear of disruption. In addition, SMI-S provides a standard means to automate many of the tedious and error-prone tasks that storage administrators are required to perform today. SMI-S allows IT administrators to meet a storage networking imperative--that the software entities intended to manage storage networks perform in seamless and easily understandable ways in order to mask administrative complexity and minimize risk as storage networks expand.

www.datamobilitygroup.com

www.storability.com

John Webster is senior analyst and founder of Data Mobility Group (Nashua, NH)