I recently posted an article about Architecting Storage Offering for vCloud Director 5.1. In the article I discussed new architecture considerations for the latest version of vCloud Director.
The middle of the article focuses around the use of Storage Profiles among other vSphere features that can now be leveraged by vCloud Director.
When I referenced the use of Storage Profiles I stated the following:
“The “*(Any)” storage profile is there by default, but it should not be included as part of any PVDC without considering the possible performance and operational risks.”
The reason for my statement was due to the possible risks any vCloud Director infrastructure can be exposed to without the correct use and understanding of the new storage features and capabilities discussed in the article.
As I’ve said before, vCloud Director is now capable of leveraging some of the vSphere storage technologies. For the most part, a majority of the storage related configurations are defined outside of the vCloud Director interface i.e. VM Storage Profile, Storage Clusters, etc. Cormac Hogan wrote an excellent article about the configuration and use of Storage Profiles. It’s a Must Read!
Storage Profiles are defined, organized, and configured in vSphere. The majority of the time we tend to label them by referencing precious metals. An example of that is illustrated in the figure below.
Prior to the release of the vCloud Suite and vCloud Director 5.1, the discussions for architecting cloud as it relates to vCloud Director and storage offerings were based around tiered models focused on performance and capacity.
The access to tiered offerings was previously achieved by creating multiple provider virtual datacenters (PVDC) that would consist of different storage characteristics that could be offered to different tenants.
Storage offerings revolve around disk types, protocols, capacity, performance, and other items which are then bundled into a service level grouping. The majority of the time they are packaged and labeled as a precious metal or tiered level (e.g Gold, Silver, Bronze, or Tier 1, Tier 2, Tier 3).
Predominantly the goal is to design storage offerings comprised of multiple or even a single service that would satisfy any tenants application’s requirements. In the previous version of vCloud Director multi-tier storage offerings were designed and made accessible via separate PVDC constructs. The illustration below is an example of the approach utilized with the previous version of vCloud Director.
Because vCloud Director 5.1 is now able to leverage some of the vSphere storage features such as Storage Profiles and Datastore Clusters, the approach for architecting storage offerings should be revised. Storage Profiles and Storage Clusters are native features of the vSphere core platform but not of vCloud Director. This means that most of the decisions made related to storage features and storage hardware design are made at the vSphere layer to a certain degree.
Multiple PVDC Design
By leveraging Storage Profiles and Datastore Clusters it’s now possible to design single instances of vCloud Director PVDC capable of providing multi-tier storage offerings. This approach could reduce the complexity previously experienced by using multiple PVDC designs for multi-tier storage offerings. This new approach could also have an impact by improving operation efficiency and deployment accuracy.
From a manageability standpoint, the use of both storage features could possibly have an impact with initial implementation effort. The storage array properties and capabilities can be systematically identified with use of the vSphere Storage API for Storage Awareness (VASA). VASA can take care of the datastore classification profile from a performance standpoint, but in the event that the vSphere Storage API for Storage Awareness are not leveraged, then manually user defined storage capabilities is the other option to get the job done, and this will incur a bigger effort.
Leveraging both features at the vSphere layer would allow vCloud Director to simply utilize that multi-tier storage design. Storage Profiles will take care of the vApp/workload performance related part of the design, while Datastore Clusters can be utilized to organize or group datastores based on their specific Storage Profiles or Tiers. Another possible benefit of this is that this approach could also serve as a risk mitigation strategy for the deployment of vApps and their respective workloads, as vApps/workloads will be forced to stay or move to a predefined storage cluster and remain on compliant datastores. The image below illustrates the use of Storage Profiles and Storage Clusters in the vSphere Web Client.
Storage Profiles, and Storage Clusters in vSphere Web Client
The three Storage Profiles and Datatore clusters illustrated above will be available in vCloud Director during the creation a PVDC. When creating a PVDC you can select the options that are applicable to a specific service offering. The image below illustrates the options presented to vCloud Director during the creation of a PVDC.
Provider VDC Creation in vCloud Director 5.1
The “*(Any)” storage profile is there by default, but it should not be included as part of any PVDC without considering the possible performance and operational risks. This is something that I will cover in a future and separate blog post. Once the PVDC’s have been created, the utilization and capacity metrics can be tracked directly in vCloud Director as well as in vSphere. The images below illustrate the Storage Profiles and Datastore Cluster view within vCloud Director 5.1.
vCloud Director Storage Profile View
vCloud Director Datastore Cluster View
One of the goals for any architecture design is to always try to reduce the level of complexity whenever and wherever possible. It’s always good to balance how the technology used will impact design from an operations perspective. You can now explore the possibilities of streamlining storage offering designs by considering vCloud Director’s capabilities to leverage vSphere features and end up with less complex solutions as the one discussed here and illustrated below.
New PVDC Design
I hope some of you folks out there finds this post helpful and useful in your cloud design journeys.
Get notification of my blog postings by following me on Twitter: @PunchingClouds