Metrics are the cornerstone of data flow visualization. Obtaining metrics and determining what they mean in the context of your infrastructure and correlating this data to extend the logic of raw data is intricate, but essential to extracting true meaning. The statement "You can only change what you can measure" has never been more important than in the context of storage management metrics. Before we can change an environment, we must be able to visualize the metrics or "measure what we can see."
In part 1 of this tip, we discussed data flow and visualization. In this installment, we will look at the metrics available and considerations when choosing storage network elements to meet your management needs. We will also discuss how the movement toward industry standards will help to remove the barriers to true heterogeneous storage management.
Metrics: Measuring what you can see
At the core of measurement is the metrics themselves. For an HBA, it may be Kbs going through a port; switch -- frames through an ISL; array -- cache hits on writes...These metrics have evolved over time from basic SNMP to today's active Application Program Interface (API) modules available in most storage networking elements. While there is movement in cross-platform data sharing, we are a ways away. For example, the Brocade API is very rich with a total of 49 metrics available in real-time from Fabric OS, but when placed in compatibility-mode with McData switches, the metrics available from the mixed elements is minimal. Look for more of this mix as companies leverage their investment in Brocade, but require the confidence in the established McData director.
To obtain the raw metrics from storage elements and retain the riches of data in a heterogeneous environment, one has the choice of the following:
1. Storage vendor solution
2. Open standards-based solution
3. Independent third-party
Each option has its advantages and disadvantages. With a vendor solution such as WideSky (EMC) or True North (HDS), the metrics obtained from the vendor hardware typically work well, but there is little incentive for the vendor to adequately support a competing vendor's hardware.
Open standards will be the ultimate solution as they evolve, but progress is slow. The Common Information Model (CIM) has been in progress for over four years. With the continuing growth of data acerbating the need for storage management solutions, any delay in adoption will only become more burdensome.
Until a standard is supported across all storage networking elements, thus commoditizing the element interfaces, third-party companies using CIM as a base are the most attractive option.
When developing a storage management strategy, consider your options carefully to get the most out of the existing metrics available from storage networks. In most cases the best solution will be a standards-based third-party solution.
Removing barriers: APIs, CIM and WBEM
To remove barriers from true heterogeneous storage management, the application program interface (API) for the storage network elements is critical. Most storage elements provide some level of API functionality while cruder devices only support SNMP support. To actively management the storage networking environment, the degree of management is tied directly to the flexibility of the API. We will first look at device APIs, the Common Information Model (CIM) and finally the Web-Based Enterprise Management (WBEM) initiative.
I brushed earlier on the API metrics available for some switches, but there is an API for almost all storage network elements today. In storage there is HI-Command for HDS and SymAPI for EMC storage. These middleware software products will be part of the hardware offering as the technology matures.
Common Information Model (CIM)
The Common Information Model is an ambitious goal to codify the common data metrics across storage network elements so that storage management software can manage similar elements in the same way. Since its inception in 1997 CIM has continued to gain ground with support from the Distributed Management Task Force.
The two parts of CIM consist of the CIM specification and schemas. The specification maps the existing management techniques such as SNMP into a formal data model. The schemas provide organized frameworks that define systems, applications, networks, devices and physical elements.
When developing a storage management strategy, be aware that CIM is a strong, flexible storage management standard and if we hope to have true heterogeneous storage management, CIM is our best bet.
Web-Based Enterprise Management (WBEM)
Web-Based Enterprise Management (WBEM) is the umbrella covering the current CIM initiative. As the CIM standard evolves, WBEM will become vital in the development of XML encoding to share CIM data. The core elements of WBEM consist of CIM, xmlCIM, and CIM over HTTP. Moving forward, WBEM will emerge as the transport mechanism for a set of standard management data.
Detailed information on both CIM and WBEM can be found at the DMTF Web site.
1. When choosing storage network elements keep storage management in mind. Choose hardware/software that provides rich storage element metrics. The more data that you can obtain at each element within the storage network, the better chance there is to manage your environment.
2. Seek out storage software and hardware that works with the evolving CIM/WBEM standards to insure heterogeneous management as your infrastructure grows.