Post 5 of 6: Delivering IT as a Service with vCloud Director

Building your cloud infrastructure is only half the battle. Let’s just assume the notion of ‘cloud’ is now defined and well aligned with your business requirements, infrastructure is in place, best practices followed, and you’re ready to power this sucker up. Then what? The presence of the hypervisor has been assumed throughout this series — much is gained with vSphere adding that prerequisite abstraction of bare-metal resources. But virtualization is only half the battle when the end goal is delivering a cloud — or IT as a Service (ITaaS). To get there, you’ll need to take a moment to understand what exactly you’re trying to accomplish. What does cloud mean to your organization in the first place? Are you looking to streamline your IT infrastructure internally (i.e. Private Cloud) or perhaps deliver next-generation IT services externally (Public Cloud)…or both (Hybrid)? No matter your flavor of cloud, one thing holds true — you will be successful only if you employ the right enablement tools and technologies. You should also step back and take a moment to understand the concepts. I made a decision to embrace these concepts and technologies a little more than a year ago. So much so that I ended up here at VMware…living, eating, and breathing this stuff (almost obsessively). As a result, when I’m tasked with helping my customers through their cloud journey — advising them through the design of their infrastructures and helping them through the concepts they must tackle in order to be successful — I am able to take a holistic approach by aligning the right tools with the given requirements. And so can you. VMware’s vCloud Director (vCD) is the quickest and most efficient way to take the leap from datacenter virtualization to ITaaS. From the moment it is installed, vCD’s cloud services framework aligns with all the key characteristics of cloud computing.
One of these key characteristics is the pooling of resources. This should be an easy one considering vSphere has center stage. Pooling of bare-metal resource — CPU, memory, storage, networks — is the first step in cloud enablement, making vSphere’s best-in-breed virtualization a critical component of cloud. vCloud Director heavily utilizes several core vSphere technologies including HA, DRS, vMotion, dvSwitch, and Resource Pools (clusters), resulting in a highly-available and elastic cloud capable of meeting or exceeding the most stringent service levels. From the user’s perspective, the resources are just there — defined by the vCloud Administrator for secure access and consumption by that tenant. vCD provides this aggregate of resources to cloud tenants through a Provider / Organization model. The provider is the root resource pool that defines the total compute capacity available to tenants, called the Provider Virtual DataCenter (PvDC). Multple PvDC’s can be created based on different tiers of physical resources. The vCloud admin then determines what subset of resources are carved out for Orgs and allocates them by configuring one ore more Organizational Virtual DataCenters (OvDC). In the Private Cloud, an Org can be the entire enterprise, a business unit, a specific functional group, etc. In the Public Cloud model, the Org is typically an external customer or tenant. A look into the resources allocated from the PvDC and consumed by the OvDC is available using one of many vCD views. While the vCloud/Provider admin can assign and monitor resources across the cloud, an org user is limited only to the resources allocated to his/her Org.
Provider vDC – Resource Dashboard, a glimpse into total resources / PvDC:

Organization vDC – Usage Monitor, resources consumed by a single OvDC:













VMwareTV: Learn more about the steps needed to create a PvDC here.

The consumption of resources can be tied to a chargeback policy using vCenter Chargeback to determine costs associated with the provisioned cloud services. I won’t get into the integration of Chargeback in this post (check the link for more details), but understand it’s a powerful tool and often a key component of the cloud.
Moving on. Another characteristic of cloud computing is this concept of elasticity. Elasticity is the dynamic use and allocation of resources based on active demands. It’s a workload’s ability to expand beyond a fixed set of resources during peek usage and contract back during periods of low utilization. This is often called “bursting”. The concept is pretty straight forward, but understanding how it’s implemented and, more importantly, what it means for your cloud is the tricky part. We all know how vSphere accomplishes this on the back end — vMotion and DRS working hand-n-hand to ensure cpu and memory resource utilization are load balanced across hosts within a single PvDC. As I mentioned earlier, vCD takes advantage of everything vSphere has to offer and adds a bit of it’s own magic to overcome the locally-bound limits with these technologies. One of the ways vCD accomplishes this is by employing a free add-on tool called vCloud Connector (vCC). Cloud admins can use vCC to inter-connect several vCD instances (cells) and associated vCenters across geographical regions…or locally. Once connected, the admin can manipulate and shift workloads (vApps) between vClouds using a single-pane-of-glass (via the vSphere client). Note that this isn’t a vMotion across clouds — vCC serves as an export/import proxy between connected clouds using SSL communications. vCC is also one of the technologies behind Hybrid cloud enablement — you can connect a given vCloud cell to public and private vCloud alike. The most popular use case for this is the ability to connect your private vCloud with a hosted (vCloud-powered) offering, giving admins the ability to utilize resources and manage workloads across clouds…a.k.a. the Hybrid cloud. More to come on this enablement tool in an upcoming post that details the installation and use of vCC.
Now let’s take a moment to focus on our users. vCD’s user interface (UI) allows for further abstraction of the infrastructure behind your cloud by giving cloud admins and consumers the ability to self-provision, run, and manipulate workloads, which are governed by a set of boundaries (inter-Org), policies, and security roles. The vCloud UI allows those who have never touched a vCenter or provisioned a VM to easily deploy applications within their organization by utilizing pre-provisioned vApps (a vApp = 1 or more VMs treated as a single workload). This brings us to the next key Cloud characteristic,catalog-based self-service. Catalog contents can be shared with users within the cloud (or not) and published across clouds (or not). The vCloud admin can limit who can access the catalog at great granularity using built-in roles and permissions, control who can create catalog items, and specify into which vDC a vApp should be deployed. The vCloud admin can also import existing VMs directly from vCenter into a catalog for consumption. The catalog also provides storage and access to ISOs, which can be mounted as media to any VM within the cloud. This is also the mechanism in which a user can build a new vApp.
Catalog-Based, Self-Service Provisioning in vCloud Director
We’ve covered pooling, elasticity, and self-service…but there is one more key characteristic of cloud computing that is a fundamental component of all things cloud — automation. Without automation, you’ll simply have virtualization with a fancy UI. What we’re trying to achieve with automation at this layer is true self-service of resources and hands-free provisioning of workloads. I’ll spare you the nitty-gritty of how vSphere plays a significant roll in back-end automation, hoping I’ve made that crystal clear by now. But, basically, vCloud Director embraces vSphere’s native technologies for much of it’s out-of-the-box automation. vCD’s UI introduces many additional levels of automation from point-and-click provisioning of workloads to custom orchestration using vCenter Orchestrator’s vCloud add-ons, which a) is free, and b) ships with 400+ pre-packaged workflows — a must-have for your cloud toolkit.
There is yet another layer of automation beyond vCloud’s built-in functionality and extensible API’s. This comes in the form of an add-on product calledvCloud Request Manager (vRM). vRM further separates users from admin responsibilities within your cloud by providing a web interface for those users to request workloads from any catalog available to them. It also adds additional control and a layer of governance between users and their cloud resources. For example, rather than a user requesting a workload — let’s just say it’s a RHEL 5.5 x64 VM with a defined set of cpu/mem resources — through a typical helpdesk system, the user logs into the vRM web portal, is authenticated against LDAP or Active Directory, and is automatically presented with catalog offerings from the cloud(s) he/she has access to.
Add Application: vRM uses the user’s credentials to determine which vApps they can deploy: 















User’s Dashboard: users can view deployed vApps and track request status








Once a request is submitted, vRM’s highly-customizable workflow engine kicks into high gear. An email is sent to the requestor’s manager (or other defined approver) for review. If approved, vRM initiates the next step in the workflow, which is to initiate the provisioning of the requested vApp into the specified cloud. If rejected for whatever reason, the rejection workflow commences and the requestor receives a friendly email highlighting why. Behind the scenes, vRM can track licensing for deployed apps, build reports on inbound requests, provisioning details, etc. Users can also use the vRM portal to request entire clouds. Again, if/when approved, vRM handles the entire provisioning process — completely hands-off — up until the time the user needs to access the new vApp for customization.

vRM Automates: Sample (customizable) vApp Request Workflow:



When you consider all of this plus the power of vCloud’s open API’s and management framework, it should be easy to understand why vCD’s automation capabilities are a game changer and will help accelerate cloud adoption.

Although not necessarily a cloud characteristic, security and multi-tenancy can be just as important to your cloud initiative as all these other characteristics. Fortunately, vCloud Director tackles that potential barrier as well. vCD ships with vShield Edge for vCloud, an automatically provisioned security appliance that can provide network isolation, NAT services, and DHCP within the vCloud construct. vShield Edge can also create a security boundry around a vApp for total isolation from other vApps, also known as fencing. Imagine the ability to create multiple replicas of a vApp for test/dev purposes. The VMs in each vApp instance can have the same IP and MAC addresses but not conflict with one another. App owners can console directly into these vApps for development using vCD’s UI without the need for direct network access. The appropriate vApp can then be deployed into the production network. This is just one of many use cases for securing cloud resources. vShield Edge adds an incredibly powerful capability in environments that have stringent security requirements and/or support a multi-tenant cloud.
To wrap things up…when all is said and done, you will have successfully taken the journey from datacenter virtualization to cloud using some of industry’s leading cloud enablement tools. vCloud Director enables cloud and helps organizations embrace ITaaS as the next logical step in IT infrastructure services, resulting in new levels of business resilience, efficiency, and automation…all powered by vSphere and accessed/orchestrated by vCloud’s intuitive user interface.
vCloud User Interface: Tenant Dashboard: 


In this Series:
5 – Delivering IT as a service with vCloud Director
6 – Get a Grip! – managing your cloud