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 |
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.
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 continue to run, resulting in wasted resources. |