SMI Tutorial > Storage Management Initiative > History of Management Protocols

Back

History of Management Protocols

Next

History of Management Protocols | History of SMI

Until the adoption of SMI-S, management of a storage area network (SAN) used either the Simple Network Management Protocol (SNMP) or swapping of vendor specific Application Programming Interfaces (API). Neither meet current needs.

SNMP

The most common system management infrastructure is based upon SNMP. Its beginnings go back to the 1980's. Its original charter was to provide a common framework for managing the low level components of a computer network such as routers and bridges. Over time, SNMP became the accepted standard for discovering network topology and monitoring its status.

However, network technology has evolved. Enterprises have increasingly integrated computers into the operation of their business. Storage resources have become more distributed. Such trends impose greater demands on a company to efficiently manage its enterprise computing environment. Unfortunately, despite attempts to expand its capabilities, SNMP can no longer fulfill these demands. The reasons are many.

SNMP definitions and data are represented in a text file called a Management Information Base (MIB). Modeling a new object in SNMP requires defining a new MIB. One MIB has no inherent relationship to any other MIB. A separate MIB is needed for each defined SNMP managed object. Achieving industry interoperability requires that each participating vendor agrees to use the same MIBs in the same way.

One MIB has no inherent relationship to any other MIB. Although one MIB may contain some of the same properties as another MIB, no SNMP mechanism exists to take advantage of the commonality. Furthermore, SNMP cannot easily model objects in an enterprise or storage area network (SAN). SNMP was originally chartered to only manage low level network components, not the entire enterprise. Its naming scheme and infrastructure do not lend themselves to management of diverse enterprise environments. For example, SNMP cannot model non-computing elements such as corporate organizational units.

SNMP defines only four operations. They are Get, GetNext, Set and Trap. Get retrieves one or more MIB values. GetNext is used to sequentially retrieve data from a table of MIB values, one row at a time. A table is a logical structuring of MIB values into rows and columns. Set is used to update an individual MIB value. However, almost all SNMP management frameworks are read-only while SANs require active management. For example, an storage administrator must have the ability to create new storage capacity or to reconfigure existing storage capacity.

For these reasons, the Storage Management Initiative (SMI) chose the Common Information Model (CIM) because CIM is a much more extensible data model. The SMI chose Web Based Enterprise Management (WBEM) as the underlying infrastructure technology because it supplied a richer set of capabilities.

API Swapping

Current enterprise networks consist of systems, network and storage resources from many different vendors. Each vendor created their own private management application that used a private interface. Remote management even used private network protocols. Consequently, in the worst case scenario, a storage management administrator has to use a separate management application for each storage product.

One solution is create a management application that is knowledgeable of more than one private interface or protocol. However, creating such an application requires vendors to share information about their interfaces. Such sharing is called API swapping. Unfortunately, API swapping does not scale business-wise or engineering-wise. First, the two competitors must negotiate a mutually beneficial business arrangement. Next, the two competitors must integrate the new technology into each other's management applications. This time-intensive process must be repeated for each new device to be supported from a new vendor. Additionally, even after the initial integration, continual updates are required for each individual product release.

The SMI chose CIM and WBEM as the underlying technology because they were based on open standards and provided a normalized approach to the management of SAN resources. Using CIM and WBEM allows storage management application vendors and storage device vendors to interact in a common manner without knowledge of any private API's.

 

Back Next