During this edition of VMworld Europe I followed only a few sessions, included two focusing on the new vCloud Hybrid Service directly offered by VMware, one presented by Massimo Re Ferre’ and another one by Chris Colotti and David Hill on “How to build a Hybrid Cloud in less than a day”.
In this post I will present Massimo’s session: PHC5070 – vCloud Hybrid Service: Architecture and Consumption Principles. This session was the first of a five part series, completely focused on vCHS.
Massimo did a great job in presenting vCHS and how it works, from a customer point of view. First of all, vCHS is not the same as vCloud Director: sure, it is based on it, but vCD is not its only building block. According to Massimo, vCHS is more like a “Cloud Of Clouds“, this because in VMware’s design, vCHS is a collection of vCD instances (the cloud of clouds) put together using as-hoc automation and integration tools specifically developed by VMware to orchestrate and deliver the platform (Massimo calls these tools “VMware’s secret sauce”). This allows for scaling-out (more vCD instances are added as more customers subscribe to the service) and for fault domain containment (only those customers hosted on one vCD instance would eventually be affected by a failure).
The customers are not supposed to feel the complexity of the infrastructure presented to them: actually, when they subscribe to vCHS they are presented with a very simple User Interface, accessible through a browser, from where, in a very synthetic manner, they can manage the Cloud Services associated with their Virtual Data Center. Switching between a series of tabs, the customer can easily manage:
- Usage and allocation of purchased resources
- Virtual Machines
- Gateways
- Networks
- Users
This is obviously not the only way to access and consume the vCHS services, as there is also the option to use APIs: check this post and this post on Massimo’s blog for more details.
So now the point is: what kind of service can be purchased with vCHS? Well, there are basically two options: Virtual Private Clouds (VPCs) and Dedicated Clouds (DCs). The main difference there is that when purchasing VPCs, customers get a slice of a shared vSphere infrastructure through a shared vCloud Director instance: VMware will deploy and set up a Virtual Private Cloud for the customer and will put it behind an Edge Gateway to isolate it from other tenants. Done, “The Cloud” is ready to be used, or as Massimo correctly points out… “consumed”.
When the customer instead opts for a Dedicated Cloud, he gets a dedicated instance of vCD (not only logically, but also physically separated from anything else and running on a dedicated vSphere infrastructure). In this case it is not VMware, but the customer himself who will setup his infrastructure by distributing the purchased resources within one or more Virtual Data Centers, each one with their Virtual Networks and so on.
We already mentioned that all of this is based upon existing and generally available VMware technologies (vSphere, vCloud Director and vCloud Networking and Security) and it’s “glued together” by “VMware’s secret sauce”, i.e. the code developed by VMware to manage and orchestrate vCHS services. Massimo, although not going into much detail, highlighted the fact that thanks to this orchestrating code, the relocation and distribution of vCHS workloads between different sites should be extremely easy and transparent. It is worth to point out that at the moment VMware is hosting several vCHS DataCenters (sites) in the USA and it is about to launch the service in Europe soon (with the first site located in the UK).
One of the major points in vCHS consumption models is how Catalogs work. Catalogs are a collection of VMs and vApps readily available to cloud consumers to be deployed in their vDCs. A Catalog can be populated and/or consumed, depending on its “type”.
In vCHS you can have a “Global Catalog”, which is created by VMware and populated with a broad set of ready-made vApps available to all their customers (i.e to all vDCs). In this case the subscribers only have the “catalog consumer” role.
Besides using the Global Catalog provided by VMware, each subscriber can create their own catalog(s), with their own vApps, specific to each Virtual Data Center, and not shared with anyone else. These Catalogs, that can be found under the “My Catalog” tab, are populated and consumed by the tenant. There is no mixing of content between catalogs in different vDCs (even if they owned by the same tenant).
Of course tenants can create users within their vDCs and assign them roles. Depending on the mix and match of roles and scopes, these users can have access to all the vDCs owned by the subscriber or only to a subset of them.
Although not yet implemented, it is worth noting that – in VMware’s vision – vCHS should become and could be used as a DR target for workloads running on the subscriber’s private infrastructure so that, in case of disasters, they can be fired up and accessed directly from vCHS, making it a viable, reliable and cost-effective alternative to home-brewed DR solutions. The extension of this concept could be the DR of the Cloud, i.e. the replica of a vCHS vDC to another one. But I am surely digressing here…
I hope this post on vCHS was interesting for you. More information and content can be found on Massimo’s Blog and on VMware’s YouTube channel, in the vCHS section.
Thanks to Massimo for allowing me to reproduce here some content from his presentation.