In model 1, each Provider VDC (mapped 1:1 with resource cluster tier) has been configured with a vSAN datastore that meets the specific capability requirements set out by the service provider's service level agreement (SLA) for that tier of service.

As illustrated in the following figure, the vCloud Director design contains two Provider VDCs offering different tiers of storage:

The compute consolidation ratio and vSAN capability, based on the disk group configuration and storage policy, defines how these offerings perform for a consumer. In addition, not shown in the figure, NIOC and QoS are being employed by the service provider so that an appropriate balance of network resources are assigned, based on tier of service.

This example illustrates how two different tiers of storage can be manually configured. However, the exact disk configuration varies depending on hardware manufacturer and provider SLAs.

As you would expect, the VMware Cloud Provider configures individual cost models and rate factors specific to each storage tier to accurately charge for the utilization of the storage resources by the various vCloud Director vApps within the organization.

By employing this design strategy, the vCloud Director administrator can take advantage of the multiple tiers of storage offered through vSAN. Different tiers of storage can also be easily mapped to cost models, which can be configured to reflect the level of storage being offered and consumed within the organization.

Typically, tiered service offerings such as these are defined by more than storage capability. vCPU consolidation ratios, levels of guaranteed memory and network resources, backups, and so on, are employed by a service provider to define the SLAs. These aspects are addressed in more detail later in this document.

The following figure shows how the solution is constructed on VMware technologies. The core vSphere platform provides the storage capability through vSAN, which in turn is abstracted through vCloud Director. The vSAN disk group configuration, along with the storage policy, is configured at the vSphere level and automatically presented to the vCloud Director layer. These constructs define the performance, availability, and capacity capabilities of the vSAN datastore, which in turn is employed to define the SLAs for this tier of the cloud offering.

 

As illustrated in the figure, the vSphere resources are abstracted by vCloud Director into a Provider Virtual Data Center (PVDC). These resources are then further carved up into individual Virtual Data Centers (VDC) assigned to Organizational tenants. The overall result is that the vApps that reside within the Organizational VDCs represent the vSAN storage capability defined by the service provider.

When employing this model, storage tiering within a Provider VDC resource cluster is not possible. Where vSAN is providing the storage resources, only a single type of storage can be configured within each vSphere cluster.

However, for a vApp author, building a typical multi-tier application often requires Tier 0 storage for a database and Tier 1 storage for the web components and middle or application layer. This might present a problem that cannot be solved with this design.

The reason for this issue is, while vCloud Director has been able to employ storage policies since the 5.1 release, and storage policies can be employed to identify the performance characteristics, as defined at the vSphere layer, the storage policies associated with vSAN are predominantly focused on availability, and not performance. Therefore, this means that different performance characteristics cannot be assigned within a single resource cluster, and as discussed earlier in this paper, an Org VDC may only map to a single PVDC’s resources. This lack of available storage types within the Provider VDC means that a vApp author cannot deploy their multitier application within a single Org VDC where multiple different tiers of storage are required.

However, as illustrated in the previous figure, it is common for Org VDCs to support different vApp types or functions, such as databases and applications, or test and development. Each of these application types might have different performance requirements for their respective vApps. The vCloud Director administrator, however, cannot map the Org VDC to the most appropriate Provider VDC based on their requirements.

For instance, the vApp author might want the databases to reside on the fast tier (all-flash) vSAN storage, while the web and application workloads utilize the hybrid SAS-based standard tier vSAN storage. However, allowing the vCloud Director administrator to manually tier the storage in this way when employing this model is not possible. Therefore, for each of the Org VDCs illustrated, the vApp and associated virtual workloads are based on the single storage type supporting that Org VDC through its Provider VDC.