Name
|
Configuration Resource Manager |
| Description |
This is an umbrella pattern covering several resource management patterns. The resource management patterns are generally used to provide one or more instances of a consumable resource to a requester as part of a configuration management system. |
| Alias |
|
| Intent |
This pattern describes an interface that can provide access to consumable resources via basic acquire and release operations. It is meant to address three categories of resource: singleton resource, resource pool, or generated resources. In addition, the pattern area also includes two types of resource usage: shared and owned. |
| 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 tracking, and requires a more sophisticated management system. IP addresses are a good example. In a non-virtualized world, they may have been manageable via spreadsheet, but when a single rack of systems may consume over 1000 IP addresses from different subnets and on different VLANs, a patterns for resource allocation automation are required. |
| 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. Examples questions are: "What IP address should be used?", "Which platform should this virtual OS be placed on?" or "What hostname should be used?" |
| 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. |
| Collaboration |
 |
| Consequences |
The primary benefit is that resources can be tracked and reported on, duplication of resource instances is managed, and 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 |
This is a meta-pattern, so is not meant to be implemented directly. It provides an overview of the interface and major structures required to manage a resource. For more implementation specific discussion, see one of the related patterns.
|
| Known uses |
|
| Related patterns |
Singleton Resource Manager, Pooled Resource Manager, Generated Resource Manager |
| Author |
John Stanford < john.stanford at sun.com > |
| Reviewer |
Ken Pepple <ken.pepple at sun dot com> |
Sign up or Log in to add a comment or watch this page.