| Name (Title) |
Pooled Resource Manager |
| Description |
This pattern can be used to manage resources that have a predefined values. |
| Alias |
|
| Intent |
The pattern describes three main interfaces to satisfy consumer, internal state maintenance, and resource pool management needs. The resource state table keep track of the pooled resources, and consumers who have acquired the resource. The resource pool manager interface allows an administrator to add or delete resources from the pool.
|
| Motivation |
In automated distributed systems management, there are several resources that are consumed and released throughout the life of a service (generally as parameters to a provisioning or state change operation). In large-scale environment such as clouds, the complexity of these resources easily goes beyond paper or spreadsheet management, and requires an automated management system. |
| Applicability |
This pattern applies when you want to automate some or all of a service lifecycle, and the service requires initialization or configuration questions to be dynamically answered. The specific types of questions addressed by this pattern are ones where the answer is part of a fixed set of possible answers which are known ahead of time, and are more easily created externally than generated internally. Some possible examples are IP addresses, VLAN numbers,or TCP ports.
|
| Structure |
 |
| Participants |
Resource consumers request resources for their configuration needs. The resource allocation manager is responsible for satisfying the resource requests. The resource state manager is responsible for tracking the available resources and their respective states. The sorter is responsible for organizing the available resources. The resource pool manager is responsible for adding and removing resource instances from the system.
|
| Collaboration |
The collaboration for acquiring an instance of a resource is shown below:
 |
| Consequences |
The primary benefit is that resources can be tracked and reported on. There is no duplication of resource instances. Deeper system automation is enabled. The primary risks relate to proper definition of the rules that define and control the resource state, and the reliance on the external requester to properly communicate the release of resource instances. |
| Implementation |
Resource instances are defined externally to the system. Care must be taken to verify that resources to be added to the system are unique. Care should be taken when defining the sorter algorithm to ensure that resource allocation occurs in the intended fashion. Finally, since you are addressing a finite pool of resources, properly handling the return of resources is important. There may be a need for an auditor of resource usage in the environment to account for misbehaving clients.
|
| Known uses |
|
| Related patterns |
Configuration Resource Manager, Singleton Resource Manager, Generated Resource Manager |
| Author |
John Stanford < john.stanford at sun.com > |
| Reviewer |
Name and email of Cloud Pattern COE reviewer |
Sign up or Log in to add a comment or watch this page.