DISK RESOURCE MANAGEMENT WORKGROUP.

CHARTER:

The Disk Resource Management group (DRMG) was created to focus on standard APIs for the high-end disk intelligent storage facilities to support the Enterprise Storage Resource Management (ESRM) disciplines such as:

* Asset Management

* Capacity Management

* Availability Management

* Performance Management

* Configuration Management

* Outboard Management

* Policy Management

Storage Networking Problem Area

Today, there are major initiatives to re-centralize the enterprise. Many of the large IT departments have well-managed centralized storage on the S/390 platforms. Yet, these same customers have thousands of servers spread throughout their enterprise that they can't even locate, let alone manage. Hundreds of recent storage studies have shown that there is a direct correspondence between the number of islands of storage and the cost of running that type of environment. The more islands of storage, the more space failures, the more performance problems, and the more people it takes to manage it.

High-end storage vendors are responding to this need by building very large capacity intelligent storage facilities which can connect to multiple OS platforms that are practically impossible to manage because each server or host only sees the view of the storage belonging to itself. Hardware vendors are providing software to respond to this problem but the software is vendor-centric which causes purchasers to buy specialized software for each vendor and to micromanage each vendor's device, costing them time and money they don't really have. IT departments want to move to Storage Area Networks (SANs) because they dramatically reduce the enterprise management costs while offering the promise of offloading routine storage management tasks without the drain of both CPU and people resources. The number one issue in implementing SANs is the ability to perform storage resource "discovery." Close behind it is the issue of being able to manage storage facilities connected to multiple operating systems--without this it will be impossible to get to true SAN management.

Proposed Method(s) Of Solution

Phase 1:

1. Get storage vendors to agree on building a common model and standard APIs for access to the information.

2. Create a white paper that defines the problem and the scope of the customer requirements.

3. Define a common management information model with the focus on commonality wherever possible.

4. Start with read-only information in the model; move to more complex areas (e.g., performance management and configuration management) in a later phase.

5. Influence standards bodies to define standard protocol interfaces to the common information model.

Phase 2:

1. Build a common prototype reference implementation to achieve the following:

* Validate the informational field content of the model.

* Verify the ability to access common information regardless of vendor.

* Document a guide for vendors to write "providers" to instantiate the information in the common model.

* Document a guide for ESRM software vendors to access information from the common model.

* Ascertain the performance and scalability aspects of the model and the access to it. Demonstrate to users the vendor's intent to work towards a common information model solution.

* Determine the necessary structures for continued definition of the model and the set of services/APIs necessary to perform the set of ESRM disciplines.

2. Develop a set of common code to enable all storage vendors from all SNMWG sub-groups to participate in the prototype implementation.

3. Document the methodology for building storage "providers" based on the prototype experience.

4. Generate a document to describe how to access the common model for ESRM application software.

Phase 3:

1. Update the model based on problems discovered with the prototype.

2. Define and model the remaining information content especially for the disciplines of capacity management, configuration management, and performance management.

3. Update the prototype as necessary to validate the additional model information.

4. Develop a set of requirements for storage resource "discovery." Possibly, add some technology to the prototype effort to try out some potential solutions.

5. Develop a plan for the information content and the APIs/services for SAN availability management with a high focus on automation enablement.

Phase 4:

1. Complete the remaining model definition, services, APIs, documentation as defined by Phase 3 above.