Learn more About the WBEM architecture Storage Management Initiative Specification (SMI-S)

Learn more About the WBEM architecture Storage Management Initiative Specification (SMI-S)

WBEM describes the architecture of a WBEM management system using the three pillars CIM, xmlCIM and CIM operations over HTTP. To this end, WBEM defines the following elements (Figure 8.10):

• CIM managed object The object to be managed is called a CIM managed object. This can, for example, be

a storage device or an application.

• CIM provider The CIM provider supplies the management data of a managed object. In the terminology of CIM this means that it provides the instances of the object that are defined in the CIM model for the managed device. The interface between CIM provider and CIM managed object is not described by WBEM, with this interface being the starting point for the integration of other protocols such as SNMP.

• CIMOM – CIM object manager The CIM object manager implements the CIM repository and provides interfaces for CIM provider and CIM clients (e.g. central management applications). The specification of the interfaces between CIM provider and CIMOM is also not part of WBEM, so manufacturer-specific mechanisms are used here too.

• CIM repository The CIM repository contains templates for CIM models and object instances.

• CIM client The CIM client corresponds to a management system. The CIM client contacts the CIMOM in order to recognize managed objects and to receive management data from the CIM provider. The communication between CIM client and CIMOM is based upon the techniques xmlCIM and CIM operations over HTTP described above. These should facilitate interoperability between CIM clients and CIMOMs of different manufacturers.

The CIM specification also provides a mechanism for sounding an alert in case of a state  change of an object. The recognition of a state change such as creation, deletion, update or access of a class instance is called a Trigger. A Trigger will result in the creation of a short-living object called Indication which is used to communicate the state change information to a CIM client through the WBEM architecture. For that the CIM client needs to subscribe for indications with the CIMOM previously. The use of CIM and WBEM for the management of storage networks In the past, WBEM/CIM has proved itself useful in the management of homogeneous environments. For example, the management of Windows servers is based upon these

techniques. Storage networks, on the other hand, contain components from very different manufacturers. Experience from the past has shown that WBEM and CIM alone are not sufficient to guarantee the interoperability between CIM clients, i.e. management systems, and CIMOMs in the field of storage networks. In the next section we will introduce Bluefin, a technique that aims to fill this gap.

Storage Management Initiative Specification (SMI-S)

At the start of this chapter we sketched out the necessity of a central management system from which all components of a storage network can be managed from different points of view. The so-called Bluefin initiative aimed to close the gaps of WBEM/CIM with the objective of defining an open and manufacturer-neutral interface (API) for the discovery, monitoring and configuration of storage networks. Bluefin thus aimed to define

a standardized management interface for heterogeneous storage networks, so that they can be managed in a consistent manner. The Bluefin initiative was set up in 2001 by a group of manufacturers under the name of Partner Development Process (PDP). Since August 2002 the further development of Bluefin has been in the hands of the SNIA. The standardization itself is now being driven forward by the SNIA Storage Management Initiative (SMI) under the name Storage Management Initiative Specification (SMI-S). SMI-S is based upon the WBEM architecture and expands this in two directions. First, it refines the classes of the CIM Common Schemas to include classes for the management of storage networks. For example, it introduces classes for host, fabric, LUN, zoning, etc. Second, it extends the WBEM architecture by two new services: the Directory Manager and the Lock Manager (Figure 8.11). The Directory Manager aims to simplify discovery in a storage network. SMI-S also defines how resources (physical and virtual) report to the Directory Manager by means of the Service Location Protocol (SLP, IETF standard since 1997), so that management  systems can interrogate the resources in a storage network through a central service, i.e. the Directory Manager. The Lock Manager aims to assist the concurrent access to resources from different management applications in a storage network. Access to CIM objects can be protected by locks, so that a transaction model can be implemented. To this end, SMI-S-compliant management systems must demand the corresponding rights from the Lock Manager in the role of the lock management client, in order to be allowed to call up the protected methods. The SMI is a working group that co-ordinates the various subgroups of the SNIA that are working on the standardization of various aspects of storage networks. In the opinion of SNIA around 70% of the required functions for the management of a storage network have already been passed. The current standard (end of 2003) primarily describes the components of a Fibre Channel SAN. SMI-S still has to be expanded for techniques such as NAS and iSCSI. Reference implementations already exist for the Directory Manager, but there are still none for the Lock Manager. As the next step, the CIM classes

that are still lacking must be defined and the interoperability of the implementations from different manufacturers tested. Therefore SNIA has established the Interoperability Conformance Testing Program (ICTP), which provides unique test standards for all participating products to demonstrate proven interoperability and standard compliance.