Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Adaptive / Evolving Error Recovery Procedure (ERP) mechanism within Storage Virtualization Appliance

IP.com Disclosure Number: IPCOM000031631D
Original Publication Date: 2004-Oct-01
Included in the Prior Art Database: 2004-Oct-01
Document File: 2 page(s) / 45K

Publishing Venue

IBM

Abstract

Learning system for Subsystem ERP within Virtualized Storage Environments

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Adaptive / Evolving Error Recovery Procedure (ERP) mechanism within Storage Virtualization Appliance

With the evolution of Symmetric Storage Virtualization Appliances, a single box now has to understand and cope with the vendor specific error recovery procedures (ERP) implemented by the storage subsystems to which it is attached.

    Traditionally this problem has been solved by either obtaining functional specifications from the vendors (usually very difficult unless there is a close working relationship between the two vendors) or by purchasing the vendors box and testing it to validate the correct ERP to use under a given scenario.

    A secondary problem is that once this has been determined, the Virtualization Appliance needs to have specific code written to handle the ERP for the given subsystem / scenario.

The basic invention being disclosed is the idea of building a toolkit of simple error recovery procedures that can be built upon, and initiated in a collective (batch) style to solve the more complex error recovery procedure.

    When a new vendors subsystem is detected, and a specific error scenario is encountered, an expert system is started that picks the most likely ERP that will resolve the problem - e.g. one that is known to solve the problem on a well understood subsystem. If this ERP fixes the problem, then the expert system remembers this for subsequent use with this subsystem and scenario. If not, then the system attempts other known ERPs until either a single ERP, or group of ERPs are successful.

    Using this technique you end up with a system that is able to diagnose and fix new error scenarios on unknown hardware.

    Depending on where this expert system is deployed this can simplify the testing / support of a new subsystem (if used inhouse) or aid the support of an unknown subsystem in the field population. (The system would need the capability of returning the updated expert system knowledge base to the Virtualization Appliance vendor)

To describe the invention, an example is provided that illustrates how the system works.

    A Virtualization Appliance such as the IBM* SVC is virtualizing the storage presented to a SAN. The virtual disks are being presented to a variety of hosts. The back-end storage subsystems comprise of 3 different vendors storage subsystems. Two of these subsystems are known by the system, the third has just been attached and is at this time unknown to the Appliance.

    The Appliance...