Introduction

VMware vCloud Director enables customers to build secure, multitenant hybrid clouds by pooling infrastructure resources into virtual datacenters. and enabling those resources to be consumed by users on-demand. vCloud Director pools datacenter resources, including compute, storage and network, along with their relevant policies into virtual data centers. Fully encapsulated multitier virtual machine services are delivered as vApps, using the Open Virtualization Format (OVF). End users and their associated policies are captured in organizations. With programmatic and policy-based pooling of infrastructure, users and services, VMware vCloud Director enforces policy intelligently and creates unprecedented flexibility and portability.

vCD (vCloud Director) is a layer on top of vCenter and abstracts all the resources vCenter manages. All these resources are combined into large pools for your customers - i.e., tenants - to consume. VMware vCloud Director not only abstracts and pools resources it also adds a self service portal. As stated before, it is more or less bolted on top of vCenter/ESX(i). The diagram below provides a simplistic, high-level overview of this architecture:

architecture-final

Figure 1 : Architecture of the vCloud Director

The VMware vCloud Director Cluster is a cluster formed by multiple vCD servers or “cells” as they are commonly referred to. The cells are responsible for the abstraction of the resources and the portal.

There are currently three types of resources that can be used by a tenant. They are as follows:

  • Compute - refers to clusters and resource pools managed by vCenter
  • Network - refers to dvSwitches and/or portgroups
  • Storage - refers to VMFS datastores and NFS shares

These resources will be offered through a self-service portal which is part of vCD. As a vCD Administrator you can use the vCD portal to carve up these resources as required and assign these to a customer or department, often referred to in vCD as an “Organization”.

In order to carve up these resources a container will need to be created and this is what we call a Virtual Datacenter. There are two different types of Virtual Datacenters:

  • Provider Virtual Datacenter (Provider vDC)
  • Organization Virtual Datacenter (Org vDC)

A Provider Virtual Datacenter is the foundation for your Compute Resources. When creating a Provider Virtual Datacenter you will need to select a resource pool; however, this can also be the root resource pool aka your vSphere cluster. At the same time, you will need to associate a set of datastores with the Provider vDC; generally speaking, this will be all LUNs masked to your cluster.

After you have created a Provider vDC you can create an Org vDC and tie that Org vDC to a vCD Organization. An Organization can have multiple Org vDCs associated to it. The Org vDCs so configured can then be consumed by creating vApps. A vApp is just a logical container for 1 or more virtual machines. This vApp could for instance contain a three tiered app which has an internal network and a firewalled outbound connection for a single VM.

If users to applications launched on a cloud complaint of slowdowns, then cloud administrators need to determine whether the vCloud Director Cell is able to pool and provision sufficient resources for the users to consume. If not, you need to be able to determine why the problem is happening – is it because the vCloud Director Cell is unavailable? is it because the vCloud Director Cell is unable to connect to the vCenter server for resource abstraction and pooling? is it because no pVDCs and org vDCs are currently enabled for use with the Cell? or is it due to one/more resource-hungry VMs/vApps in an org vDC? The action you take depends on what you diagnose as being the root-cause of the problem.