Recently a customer reached out to me and informed me about an issue they ran into while managing a VSA ROBO environment with the vSphere Web Client and Google Chrome browser and I wanted to inform everyone about the issue and how to resolve it.
When using the vSphere Web Client with the Google Chrome browser the error message illustrated below is produced whenever an attempt is made to access the VSA Manager for the first time.
This is a known issue and its not a vSphere Web Client issue per say. This is due to the way the Google Chrome browser behavior with self signed security certificates. The workaround to this issue is listed below:
- Copy the entire url portion of the produced “This webpage is not available” error message and paste it to a new tab in Google Chrome.
- Click the option to proceed to the website when Google Chrome produces the security warning.
- Reload the vSPhere Web Client and now the VSA Manager should be accessible and displayed correctly.
Hope folks find this useful
For future updates, be sure to follow me on Twitter at @PunchingClouds
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