5.2 Model 2: Single Provider VDC Hosting Multiple Tiered Resource Clusters
The second design model takes advantage of elastic VDC, and the ability to span a Provider VDC across multiple vSAN enabled resource clusters.
vCloud Director gives VMware Cloud Providers the ability to create elastic VDCs, which allow an Org VDC to consume resources from multiple vSAN enabled clusters. By having the Provider VDC abstract the resources from multiple vSAN clusters, it not only becomes simpler to grow capacity when needed, but also allows providers to design multiple storage performance and availability capabilities through storage policies, and deliver them to a single Org VDC. However, in this model the compute resources remain consistent throughout the Provider VDC.
In the following figure, there are three different tiers of storage available to the Org VDC, supporting Organization A. An all-flash based vSAN cluster, a 10k SAS-backed tier, and a NL-SAS backed capacity tier.
Figure 12. vCloud Elastic Provider VDC vSAN Logical Architecture
Note that the way in which vCloud administrators extend a Provider VDC requires the creation of a Provider VDC primary vSphere resource pool before additional cluster resources can be added. The additional vSphere resource pools clusters must be added in subsequent steps.
To add additional clusters, go to the Manage & Monitor tab and select Provider VDCs.
Figure 13. Adding Clusters Through vCloud Director (1 of 2)
Select the provider VDC and click the Resource Pools tab.
Figure 14. Adding Clusters Through vCloud Director (2 of 2)
Then select the green plus icon to add another vSAN enabled cluster.
Note A provider VDC can only span clusters managed by the same vCenter Server in the same vCenter Server data center.
The Provider VDC is now able to provide compute and storage resources from multiple vSAN clusters. In vCloud Director, both the pay-as-you-go and allocation pool model Org VDCs are able to consume resources from an elastic Provider VDC.
An additional approach that can be employed with both design models is the inclusion of Storage Policy-Based Management to enable multiple levels of storage offerings within each tier based on availability and SPBM performance capabilities. For instance, if employed, the common storage devices, across the resource clusters, can be assigned multiple storage policies to reflect availability characteristics, such as the number of failures to tolerate (FTT) capability, as illustrated in
Figure 12. These storage profiles can then be categorized as Enhanced Availability (FTT=2), Standard Availability (FTT=1), or even No Enhanced Availability, (FTT=0) (not illustrated), with all storage policies configured across a common shared storage class, such as a hybrid configuration backed by 10k SAS drives.
Figure 15. Provider VDC with Mixed Storage Availability Policy Capabilities
The storage policies, which must be configured at the vSphere layer, before being imported into vCloud Director at the Provider VDC level, can be manually assigned by the vSphere / vCloud Director administrator.
For instance, within the Org VDC, the vApp can be deployed on a single storage type, but by leveraging the storage policies, multiple availability capabilities can be chosen. The next section provides more in-depth information on Storage Policy-Based Management capabilities found in vSAN.
Using Storage Policy-Based Management, the vApps and associated virtual workloads operating in the vCloud Director Provider VDC have their data located in one, two or three locations across the vSAN datastore. Although vSAN, and therefore vCloud Director, offers no control over the dynamic placement of the vApp data, the underlining vSAN storage in the Provider VDC is employing its native replication technologies at the back end to meet the appropriate availability requirement defined in the policy.
