The primary capacity management concerns of the vCloud administrator are as follows:

The VMware vCloud solution makes extensive use of reservations. As such, previous approaches to capacity management used in vSphere are not as applicable to a vCloud. For example, CPU and memory over-commitment cannot be applied as extensively as it was in a multitenant environment.

Unlike managing capacity for vSphere, in a vCloud, the virtual machine is no longer the basis for resource consumption from a service provider perspective. The organization virtual datacenter is the basis for resource consumption in a vCloud.

Capacity management is further impacted by the introduction of multiple consumption models in the vCloud model. Each model requires its own capacity management approach. As a result, this appendix provides guidance for capacity management from a service provider vCloud administrator perspective as it applies to each of the consumption models: Pay As You Go, Allocation Pool, and Reservation Pool.

Regardless of the particular consumption model applied in a provider virtual datacenter, the common starting point of vCloud Capacity Management is to calculate the total amount of CPU and memory resources available for consumption. Because the underlying infrastructure provisioning unit of a provider virtual datacenter is an ESXi host, the first step is to determine the total CPU and memory at the vSphere host level.

The following table shows the key vSphere host variables needed to calculate capacity, along with example values.

 

Calculating the total available memory is straightforward. It is the total amount of RAM for the vSphere host. Total CPU resources are calculated using the following formula:

Using the example values from the table, the total CPU resource is equal to 19.2GHz.

After the vSphere host capacity model is defined, the next step is to determine the provider virtual datacenter (vSphere cluster) capacity. Determining the provider virtual datacenter capacity is critical, as vCloud Capacity Management should be performed at the provider virtual datacenter level, not the vSphere host level.

When considering vCloud provider virtual datacenter capacity, an additional step is required to make sure that redundancy is accounted for. The provider virtual datacenter cluster redundancy may vary depending upon service levels offered. For the next example, we assume N+2 cluster redundancy. This means that the provider virtual datacenter can absorb up to two vSphere host failures and continue to support all hosted virtual machines at the same level of performance. To accomplish this, there must be capacity available on the remaining vSphere hosts to take over all workloads.