VMware Cloud Director Tenancy and Resource Isolation

To provide resources to an organization, one or more organization virtual data centers are created for the organization.

Provider Virtual Data Center

To make the vSphere compute, memory, and storage resources available to VMware Cloud Director, a provider Virtual Data Center (VDC) is required.

Before an organization deploys VMs or creates catalogs, the system administrator must create a provider VDC and the organization VDCs that consume its resources. The relationship of provider VDCs to the organization VDCs they support is an administrative decision. The decision can be based on the scope of your service offerings, the capacity and geographical distribution of your vSphere infrastructure, and similar considerations.

Because a provider VDC constrains the vSphere capacity and services available to tenants, system administrators commonly create provider VDCs that furnish different classes of service, as measured by performance, capacity, and features.

Tenants can then be provisioned with organization VDCs that deliver specific classes of service defined by the configuration of the backing provider VDC. Before you create a provider VDC, consider the set of vSphere capabilities that you plan to offer your tenants. Some of these capabilities can be implemented in the primary resource pool of the provider VDC.

Allocation Models

To allocate resources to an organization, you must create an organization VDC. An organization VDC obtains its resources from a provider VDC. One organization can have multiple organization VDCs.

An allocation model determines how and when the allocated compute and memory resources of provider VDC are committed to the organization VDC.

The following table shows the vSphere resource distribution settings at the VM or resource pool level based on the organization VDC allocation model:

	Flex Allocation Model	Elastic Allocation Pool Model	Non-Elastic Allocation Pool Model	Pay-As-You-Go Model	Reservation Pool Model
Elastic	The Elastic setting is based on the organization VDC configuration.	Yes	No	Yes	No
vCPU Speed	If a VM CPU limit is not defined in a VM sizing policy, vCPU speed might impact the VM CPU limit within the VDC.	Impacts the number of running vCPUs in the Organization VDC.	Not Applicable	Impacts the VM CPU limit.	Not Applicable
Resource Pool CPU Limit	The CPU limit of an Organization VDC is apportioned based on the number of VMs in the resource pool.	Organization VDC CPU allocation	Organization VDC CPU allocation	Unlimited	Organization VDC CPU allocation
Resource Pool CPU Reservation	The CPU reservation of an Organization VDC is apportioned based on the number of vCPUs in the resource pool. Organization VDC CPU reservation equals the organization VDC CPU allocation times the CPU guarantee.	Sum of powered on VMs and equals the CPU guarantee times the vCPU speed, times the number of vCPUs.	Organization VDC CPU allocation times the CPU guarantee	None, expandable	Organization VDC CPU allocation
Resource Pool Memory Limit	The memory limit of an Organization VDC is apportioned based on the number of VMs in the resource pool.	Unlimited	Organization VDC RAM allocation	Unlimited	Organization VDC RAM allocation
Resource Pool Memory Reservation	The RAM reservation of an Organization VDC is apportioned based on the number of VMs in the resource pool. The organization VDC RAM reservation equals the organization VDC RAM allocation times the RAM guarantee.	Sum of RAM guarantee times vRAM of all powered-on VMs in the resource pool. The resource pool RAM reservation is expandable.	Organization VDC RAM allocation times the RAM guarantee	None, expandable	Organization VDC RAM allocation
VM CPU Limit	Based on the VM sizing policy of the VM.	Unlimited	Unlimited	vCPU speed times the number of vCPUs	Custom
VM CPU Reservation	Based on the VM sizing policy of the VM.	0	0	Equals the CPU speed times the vCPU speed, times the number of vCPUs.	Custom
VM RAM Limit	Based on the VM sizing policy of the VM.	Unlimited	Unlimited	vRAM	Custom
VM RAM Reservation	Based on the VM sizing policy of the VM.	0	Equals vRAM times RAM guarantee plus RAM overhead.	Equals vRAM times RAM guarantee plus RAM overhead.	Custom

Each allocation model can be used for different levels of performance control and management. The suggested uses of each allocation model are as follows:

• Flex Allocation Model:

  • With the flex allocation model, you can achieve a fine-grained performance control at the workload level. VMware Cloud Director system administrators can manage the elasticity of individual organization VDCs. Cloud providers can have better control over memory overhead in an organization VDC and can enforce a strict burst capacity use for tenants.

    Note:

    The flex allocation model uses policy-based management of workloads.

• Allocation Pool Allocation Model:

  • Use the allocation pool allocation model for long-lived, stable workloads, where tenants subscribe to a fixed compute resource consumption and cloud providers can predict and manage the compute resource capacity. This model is optimal for workloads with diverse performance requirements.

  • With this model, all workloads share the allocated resources from the resource pools of vCenter Server.

  • Regardless of whether you activate or deactivate elasticity, tenants receive a limited amount of compute resources. Cloud providers can activate or deactivate the elasticity at the system level and the setting applies to all allocation pool organization VDCs. If you use the non-elastic allocation pool allocation, the organization VDC pre-reserves the VDC resource pool and tenants can overcommit vCPUs but cannot overcommit any memory. If you use the elastic pool allocation, the organization VDC does not pre-reserve any compute resources, and capacity can span through multiple clusters.

    Note:

    Cloud providers manage the overcommitment of physical compute resources and tenants cannot overcommit vCPUs and memory.

• Pay-as-You-Go Model:

  • Use the pay-as-you-go model when you do not have to allocate compute resources in vCenter Server upfront. Reservation, limit, and shares are applied on every workload that tenants deploy in the VDC.

  • With this model, every workload in the organization VDC receives the same percentage of the configured compute resources reserved. In VMware Cloud Director, the CPU speed of every vCPU for every workload is the same and you can only define the CPU speed at the organization VDC level. From a performance perspective, because the reservation settings of individual workloads cannot be changed, every workload receives the same preference.

  • This model is optimal for tenants that need workloads with different performance requirements to run within the same organization VDC.

  • Because of the elasticity, this model is suitable for generic, short-lived workloads that are part of autoscaling applications.

  • With this model, tenants can match spikes in compute resources demand within an organization VDC.

• Reservation Pool Allocation Model:

  • Use the reservation pool allocation model when you need a fine-grained control over the performance of workloads that are running in the organization VDC.

  • From a cloud provider perspective, this model requires an upfront allocation of all compute resources in vCenter Server.

    Note:

    This model is not elastic.

  • This model is optimal for workloads that run on hardware that is dedicated to a specific tenant. In such cases, tenant users can manage use and overcommitment of compute resources.

Figure 1. VMware Cloud Director with Multiple Organizations

Table 1. Recommended Tenancy and Resource Isolation Design

Design Recommendation	Design Justification	Design Implication
Create at least a single Provider VDC.	Required to create Organizations and corresponding Organization VDCs.	None
Create an Organization per vendor.	Ensures isolation between different vendors in the environment.	None
Create at least a single Organization VDC per Organization.	Allows the Organization to deploy workloads.	If not sized properly, an Organization VDC can have unused or overcommitted resources.
Use the Flex allocation model.	Allows for fine-grained control of resource allocations to each organization VDC.	None
Configure Storage and runtime leases for production VDCs to not expire.	Production workloads are meant to run until their end of life and then decommissioned manually.	By not setting any leases, workloads that are no longer being used could continue to run, resulting in wasted resources.