Overview

The billing models for vDCs are based on resource allocation and management modes configured at the VMware hypervisor level. These modes are as follows:

• PAYG (Pay As You Go)
• Allocation Pool

PAYG

This is the most commonly used model when VMs are often stopped and occasionally started. Use cases that justify this model choice include:

• VMs operating under specific seasonality (year-end sales, month-end calculations, promotional periods for a website, for example)
• Labs, demos, and prototypes with a short lifespan
• Training environments

For example, consider a vDC in PAYG, sized at 10 vCPUs. Upon creation, it will be sized at 22 GHz, as the vCPU Speed parameter is set by default to a value equal to that of the physical processors, which is 2.2 GHz in this case.

In our example, we have 4 VMs: 3 VMs with 2 vCPUs and 1 VM with 4 vCPUs. In PAYG, it is necessary to size the VMs adequately to ensure they have the necessary resources when needed. Regardless of the actual computing power needs of the VMs (GHz), they have a defined allocation that is fixed per VM and depends on the parameters chosen in their configuration.

For instance, a VM hosting a database will be sized with 4 vCPUs to handle the load during peak application activity, even if the application operates at 20% CPU load 99% of the time. Thus, the sizing of the VMs is paramount compared to the sizing of the vDC.

Allocation Pool

This is the preferred model when the majority of VMs are powered on continuously. In addition to optimizing consumed resources, this model is financially more advantageous.

Now, consider a vDC in Allocation Pool, sized at 18 GHz. The vCPU Speed parameter, set at 1.8 GHz, determines the number of vCPUs that the vDC can start, which here is 10 vCPUs.

For this example, we keep our 4 VMs, and it is necessary to size the VMs adequately to ensure they have the necessary resources when needed. However, resources are allocated at the vDC level (rather than at each VM level as in PAYG), allowing VMs to consume the GHz not used by other VMs.

In this principle, the sizing of the vDC must take into account:

• The number of vCPUs that one wishes to be able to start
• The number of GHz that one wishes to provide to all VMs, knowing that they will not consume all the GHz continuously.

This mechanism ensures that there is always a reserve of GHz available for VMs that may have high demands.

Note that since the vDC in Allocation Pool utilizes GHz resources more efficiently, it does not need to be sized as much as in PAYG.

Thus, the sizing of the vDC is paramount compared to the sizing of the VMs.

---