The following concepts are important for understanding how Resource Manager operates in Microsoft® Provisioning Framework (MPF).
Consumers and resources are the fundamental components of any resource management equation. A consumer is a user (a person or a thing). A resource is a consumable entity such as disk space, network bandwidth, or software licenses. However, in practice, consumer types and resource types define sets of attributes common to particular kinds of resources, and consumer groups and resource groups categorize instances that share some similarity that is important to management. For example, servers could be a resource type, but the servers in a particular data center would probably be managed as a resource group, and a particular server would be considered an instance. A consumer in one situation can be a resource in another, but each usage must be defined separately. Instances inherit their default properties from their respective types.
An allocation is a claim that a consumer instance has on the capacity, or amount of usefulness, of a resource instance. Capacity attributes are defined by resource type for propagation to resource instances. Capacity can be expressed in terms of megabytes, bandwidth, or any other unit of measure. Allocations in Resource Manager are based on a block model in which each resource instance has a maximum capacity, and each consumer instance is allocated a given percentage of that capacity. The block-model algorithm evaluates each consumer and attempts to allocate it to the highest-ranked resource instance. If that resource is already fully allocated, the allocation function tries the next highest-ranked resource instance, and so on, for all resource instances and all consumers. Whenever multiple resources share the same rank, consumers are allocated to the first resource with sufficient capacity.
Note Resource Manager does not consume allocation (that is, it does not dynamically adjust allocations up or down based on actual consumption). It will notify you if you over- or under-allocate, but not if you over- or under-consume an allocation.
Allocations can be based on either virtual used or actual used capacity. Virtual used capacity is the maximum amount that a consumer is entitled to have, such as an amount that would be guaranteed in a service-level agreement. Conversely, actual used capacity is a forecast of average actual consumption, perhaps derived from consumption statistics collected over time. For example, in a Microsoft® Exchange installation, each user might be entitled to 30 MB of disk space but in actuality, the average user might consume only 15 MB. To represent this situation in Resource Manager, you could specify 30 MB as the virtual used amount and a fill ratio of 50% to calculate an actual used amount of 15 MB. Alternately, you could simply base your allocation on either the actual or the virtual used amount (in which case it would be unnecessary to define a fill ratio to relate the two).
Whenever you operate on instances or groups of resources or consumers, you first define a candidate set of eligible candidates to include in the operation. Many operations have both a source and a target candidate set. For clarity, it is better to keep consumer and resource candidates in separate candidate sets, although the system does not enforce this convention.
Candidates are added to, found, kept, or removed from candidate sets either directly or indirectly via their mappings. Mappings are optional associations between:
Resource Manager generates notifications whenever a resource is over-allocated or over-consumed. A resource is considered over-allocated whenever the total amount allocated exceeds the resource's warning percentage (as defined by the warningPc node of a call to ). A resource is considered over-consumed when a call to Verify Resource Capacity reports that the actual resource capacity is less than the capacity previously defined in the . Notifications can be queried either as XML (using Retrieve Notifications) or as Windows events (using Raise Notifications as Events).