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

Autonomic Provisioning Mechanism

IP.com Disclosure Number: IPCOM000018612D
Original Publication Date: 2003-Jul-28
Included in the Prior Art Database: 2003-Jul-28
Document File: 2 page(s) / 6K

Publishing Venue

IBM

Abstract

We disclose an improved resource provisioning mechanism. While prior art systems simply report that service level guarantees are not being met, this system also reports on its determination of why the guarantee is not being met. This allows the system component responsible for the provisioning to take targeted action to resolve the root cause of the failure to meet the guarantee, resulting in improved system behavior.

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

Page 1 of 2

Autonomic Provisioning Mechanism

Provisioning has been widely studied and disclosed. In the standard approach, a set of resource managers (RMs) each control a set of resources. When a resource manager A determines that it cannot handle the load facing it, it requests additional manager from a higher-lever RM. We call this higher level RM a RM Coordinator, or RMC. The RMC has the ability to force another, lower-lever, RM B to yield resources to RM A, assuming the RMC determines that there is sufficient value in reprovisioning resource from A to B.

The drawback to this approach is that information is lost in the request from the RM (A) to the RMC, specifically, in prior art approaches, A only sends a indication that it needs additional resources, not why it needs those resources, thereby constraining the response by the RMC to a "yes/no" decision regarding whether to meet A's request. However, in many cases, the RMC controls not just the resources requested by A, but other resources of type not known to A, such as disk, network, etc.

In short, we disclose a mechanism in which the RM, rather than simply requesting additional resource, reports a problem to an RMC, optionally containing a suggested action.

To further illustrate the idea, we present this example: an RM might determine that it is not meeting its service goals. We assume that the RM manages a pool of servers. In prior art solutions, the RM would request one or more additional servers from the RMC. However, if the issue with response time was caused not by a server shortage, but by an issue relating to the speed of access to storage, adding an additional server would, at best, not help the problem and might...