Resource pool selection process by Elastic vDC in vCloud Director 1.5

Products

• VMware Cloud Director

Issue/Introduction

Elastic Virtual Datacenter (vDC) is a new feature in VMware vCloud Director v1.5.

This article provides information on the resource pool selection process while deploying a vApp using the Elastic vDC feature.

Environment

VMware Cloud Director 5.5.x
VMware Cloud Director 1.5.x
VMware Cloud Director 5.1.x

Resolution

Overview of Elastic vDC

One of the key defining characteristics of a cloud is elasticity, which means that the container through which a tenant consumes resources can grow and shrink. In vCloud Director 1.5, Pay-As-You-Go organization vDCs are made elastic. Now, multiple resource pools can be added to a single provider vDC and capacity from all of these resource pools can be made available to a single Pay-As-You-Go organization vDC.

This elasticity is restricted to:

• Only the Pay-As-You-Go organization vDCs. The Reservation Pool and Allocation Pool vDC are still bound to a single provider vDC resource pool.
• A single vCenter Server Datacenter (provider vDC resource pools cannot span multiple vCenter Server Datacenters)

The system administrator is allowed to add/remove multiple resource pools to/from an existing Provider vDC, thus making it possible for a Provider vDC to be backed by multiple resource pools. When the provider vDC is created, user selects a primary resource pool. Allocation Pool and Reservation Pool organization vDCs consume resources from this primary resource pool. After creating the provider vDC, additional resource pools can be added to the provider vDC, so that Pay-As-You-Go organization vDCs using that provider vDC can expand, as required, to accommodate more virtual machines.

Resource pool selection during vApp placement

When a vApp is deployed in the Pay-As-You-Go organization vDC, vCloud Director selects the appropriate resource pool from the list of resource pools available to the provider vDC.

Resource Pool Viability for vApp Placement

For a resource pool to be considered viable for vApp placement, it must satisfy these conditions:

• It should be in an enabled state.
• It should have connected and enabled datastores, with sufficient free capacity to place all virtual machines in the vApp. If the organization vDC is thin provisioned, this criterion is not applicable.
• It should be connected to the same networks as those available from the primary provider vDC resource pool. This is to ensure that vApps deployed within an Organization can communicate via the same network.
• It should have sufficient free CPU and Memory capacity to power-on the vApp. However, if no resource pools can be found satisfying this criterion, vApp creation is allowed on the “least worst” resource pool.

Selection mechanism from the viable resource pools

From all the viable resource pools, vCloud Director selects the least constrained resource pool for the vApp placement. The least constrained resource pool is determined using these resource metrics for each resource pool:

• Compute metric
  
  The compute metric is intuitively designed to reflect the number of vApps that can be provisioned on the given resource pool, based on the vApps’ compute requirement. It is computed as:
  
  Resource_pool_unreserved_Mhz / vApp_vCPU_Allocation_In_Mhz
  
  
• Memory metric
  
  The memory metric attempts to reflect the number of vApps that can be provisioned on the given resource pool, based on the vApps’ memory requirement. It is computed as:
  
  Resource_pool_unreserved_Memory_MB / vApp_Memory_Allocation_In_MB
  
  
• Storage metric
  
  The storage metric attempts to reflect the number of vApps that can be provisioned on the given resource pool, while comparing the sum of storage capacity available to the resource pool against the vApps’ expected storage requirement. It is computed as:
  
  Sum of storage capacity on datastores connected to Resource Pool in MB / vApp Storage requirement in MB

Each resource pool’s effective metric is determined as the smallest of the three metrics, and the resource pool with the highest effective metric is chosen as the target for placement. Important messages regarding this process are also printed in the debug log messages.

To understand this better, consider the following sample debug log messages that describe the information about two contending resource pools connected to a provider vDC for vApp placement:

• Resource pool resgroup-447 is viable, capacity metrics: {COMPUTE_MHZ=3.476, MEMORY_MB=2.33984375, STORAGE_MB=9.700439453125}
• Resource pool resgroup-76 is viable, capacity metrics: {COMPUTE_MHZ=3.952, MEMORY_MB=1.212890625, STORAGE_MB=13.506323242187499}

You can see that both the resource pools are viable for the vApp placement. vCloud Director determines the resource pool that is less constrained by computing the COMPUTE_MHZ, MEMORY_MB, and STORAGE_MB metrics as described earlier. From the log messages, it is clear that memory is the concern here as less percentage of memory will be available in both the resource pools than CPU/storage resources after the vApp placement.

Resource Pool	resgroup-447	resgroup-76
Effective Metric	2. 33984375	1. 212890625

If you compare these values, you can see that resgroup-76 is more constrained. Therefore, vCloud Director will place the vApp in resgroup-447.

Limitations

The limitations of the Elastic vDC feature in VMware vCloud Director v1.5 include:

• Only Pay-As-You-Go organization vDCs are elastic.
• All the virtual machines in a vApp are placed in the same resource pool. Therefore, after a vApp is deployed to a resource pool, subsequent virtual machine provisioning operations within that vApp always go to that same resource pool.

Best Practices and Deployment Recommendations

It is recommended that shared storage be used and made available to all clusters of an Elastic Provider vDC. This helps in avoiding fragmentation of storage resources as virtual machines are deployed to individual clusters. Also, this design enables greater mobility of virtual machines across different clusters in an Elastic Provider vDC.