vCloud Director Allocation Models

VMware vCloud Director comes with three different allocation models - Allocation Pool, Pay-As-You-Go, and Reservation Pool. I am going to give a brief overview of the allocation models, and give you my perspective on the best option for an internal corporate environment.

Within an organization vDC you have multiple resource allocation methods each with their own inherent characteristics that can be placed in one of two categories: VM or resource pool.

Allocation Pool Model

The allocation model permits an organization to acquire a given amount of resource, yet has the capability to “burst” higher. Because the allocation pool only guarantees a specified percentage of the allocated resource, the remainder is not guaranteed and there is potential for contention with demand from other consumers.

With the Allocation Pool Model:

• There is a pool of resources which a percentage can be guaranteed.
• The default reservations are 0% for CPU and 100% for memory.
• A consumer can expand and contract their resources at any time, but only through the provider.
• Lowering the guarantee of resources allows for more vApps to fit into the pre-allocation, but this may impact the ability for the vApp to get the resources it asks for.
• The provider controls resource over-commit by setting a % guaranteed commitment of the allocation for any vApps deployed. vApps can compete for resources above this guaranteed reservation.
• No CPU reservations are set on a per-VM level
• A reservation is set per-VM for memory resources based on the percentage of guaranteed resources.

This model:

• There is no quality of service (QOS) in this model, which means that over-commitment is possible.

Reservation Pool Model  

The Reservation Pool Model is a very straight forward fixed pool model that provides the consumer a guaranteed amount of resources. This model is good for steady state workloads.
 
With the Reservation Pool model:  

• There is a guaranteed pool of resources that are set on a resource pool level.
• The provider cannot over-commit resources. This model guarantees 100% commitment of the vDC allocation.
• It offers the consumers the capability of setting reservations, shares, and limits on a per-VM level for CPU and memory.

 Pay-As-You-Go Model

When using the Pay-As-You-Go model (also referred to as the Allocation vApp Model), you manage the resource consumption at the vApp virtual machine level. Like the allocation pool model, the provider controls resource over commitment by defining a percentage guarantee for CPU, memory resources, and a maximum virtual machine limit.

 
With the Pay-As-You-Go model:

• Resources are guaranteed on a per-VM level.
• The default reservations are 0% for CPU and 100% for memory.
• The resource pool is an accrual for all the reservations set on the per-VM level.
• The limit setting on the resource pool is unlimited which facilitates an unrestrained approach to resource consumption within the constraints of the Provider vDC.

The different flavors break down to a committed offering, a dedicated offering, and a basic offering.  

• The committed offering (allocation pool) provides reserved compute resources (subscription model) with the ability to burst above committed levels, if additional capacity is available.
• The dedicated offering (reservation pool) provides dedicated compute resources which gives predictable performance by reserving dedicated resources.
•  The basic offering (pay-as-you-go) is designed for environments that are transient, early development models where a vApp will be deployed and taken down shortly after to test software that does not require a reservation and isn't high performance.

It could work in very nicely with certain SLA based offerings:

From the perspective of a corporate IT professional this is over complicated. I am a firm believer in creating an internal IaaS compute cloud, it provides agility and business innovation; but this level of detail simply isn't needed unless you are a pure hosting organization.

The developers I work with on a day-to-day basis want an allocation of resources that are available for self-service provisioning of VMs. They are focused on an operating system (Windows or Linux), 1 - 8 vCPUs, and 512 MB to 8 GB of memory; they think of their VMs in terms of a physical server. They don't care about reservations, shares, limits, guarantees, and CPU allocations based on MHZ.

If you are using this as a replacement for VMware Lab Manager, your best solution is the reservation pool model.