Every new technology brings with it a whole different lexicon of terminology, and VMware’s vCloud Director is a good example of a technology that comes with its own terms and concepts. Some terms are not VMware-specific, but I’ll try to include the company’s spin.
Virtual data center
I’ve used the term "virtual data center" for some time now. As a VMware Certified Instructor, I used it to describe the ability to link remotely into a teaching environment for vCenter and ESX. Now, of course, the term means a whole lot more.
Users should understand and appreciate these concepts before embarking on the initial configuration of vCloud Director.
There are two types of virtual data centers (VDC) in VMware vCloud Director -- the Provider VDC and the Organization VDC. The Provider VDC lets you logically carve up physical resources. To some degree, you can see them as another layer on top of clusters and resource pools.
The key mistake folks make is to think they are related to the
datacenter object in vCenter. Despite similar names, they are actually quite different. You can think of the Provider VDC as being a container of clusters or resource pools that users can run their virtual machines (VMs) on. These VDCs introduce another layer of abstraction to the vSphere model because the consumers of the cloud do not see the clusters and resource pools.
The Provider VDC is also the first point at which you can start categorizing vCloud Director to offer different qualities of service (QoS). It’s possible to create gold, silver and bronze types of Provider VDCs, which feature varying levels of performance or availability.
What end users actually see is the Organization VDC. These allow the cloud to be partitioned however users like, without being constrained by the physical resources beneath; that’s the job of the Provider VDC. In public cloud usage of vCloud Director, each Organization VDC will represent each business hosted through that provider. In a large corporation, each Organization VDC can represent each business within the group or holding company.
Alternatively, there’s nothing stopping the vCloud administrator from creating Organization VDCs based on business functions like R&D, distribution or finance. An Organization VDC can be mapped to just one Provider VDC or many; this allows the users in the Organization VDC to select what QoS their particular set of VMs or vApps require.
Once end users log on to vCloud Director, all they can see is their own organization. They have no visibility or access to others without it being specifically granted, and they cannot see which cluster or resource pool their specific VMs are running. As you can see from the above screen grab, within the VDC you can control the "Organization & Resources," "Content" and "User & Groups"; each Organization VDC contains a couple of other key terms and concepts like vApps, Catalogs and so on. The best way to view an Organization VDC is as a security boundary that keeps one unit separate from another.
Once that isolation has been set, users can decide how to consume the resources presented in the Organization VDC. This relationship allows for a "pay as you go" model with no upfront guaranteed allocation of resources in the first instance. There are, however, limits to stop unchecked usage. The Organization VDC can be configured with a "reservation pool" that offers a guaranteed but set amount of resources for end-consumers to eat up. Finally, the "allocation pool" model allows for a guaranteed amount of resources, along with an option to "burst" above the allocation pool settings as needed.
The term "vApp" is used in vCloud Director and vSphere, but the two objects are not the same thing. If you create a vApp in vSphere, don’t expect it to magically appear in vCloud Director . They are, however, very similar.
vApps are a collection of VMs that make up a single IT service. The VMs in a vApp can communicate to each other and, if configured correctly, to the outside world as well. They can also be packaged up using the Open Virtualization Format (OVF).
You might be wondering, "If vApps in vSphere are so similar to those in vCloud Director. why did VMware allow for them to live separately?" The main reason is the folks who manage the "cloud layer" might be totally different from those who manage the "vSphere layer" -- and for security reasons they wanted to enforce that separation -- so the cloud administrators could provide pre-packaged VMs without needing high-level access to the vSphere layer.
The use of the term "catalog" is not exclusive to VMware. If you take a brief look at other cloud automation software vendors, you will find they will use it in some shape or form; most refer to it as a "service catalog."
The catalog holds generic content that the end user will need during daily tasks. They can contain templates of individual VMs or templates of vApps and, if required, they can also hold other media like ISO images of CD/DVDs and floppy images in an FLP format. These could be used to build VMs manually or add additional application software into pre-existing templates of VMs.
Catalogs can either be shared or published. If a catalog is shared, it’s available within the end user’s organization; if published, it’s available between organizations. If there is a common set of vApps (or, more likely, ISOs) that all Organization VDCs need access to, it’s much simpler to publish the catalog across the board.
While VMware is keen to keep clear blue water between vCloud Director and vSphere, it is possible to import ISO and FLP files into vCloud Director from an existing vSphere data store. It’s also possible to import (aka copy) an existing VM from vSphere and have it become a template or vApp in vCloud Director. So you won’t have to start building everything from scratch, but your existing virtual resources won’t just pop up in vCloud Director.
You can view the term “user cloud” as being a subset of Organization VDCs; I look at it as the application owner’s view of an organization. For example, when the DBA administrator of the Finance Organization VDC logs in, all that’s visible are the VMs and vApps associated with their job task.
As you can see, vCloud Director is a very tiered product; each layer exposes fewer and fewer privileges and rights. So the view the end user sees is quite narrow, especially when compared to what a vCloud Administrator who has the task of creating and defining VDCs might see. It’s not unlike how the view of a virtual machine administrator, who sees only VMs, is different than the vCenter administrator’s, who has rights over the entire system.
Provisioning policy terms
No system would be complete without policy systems designed to control who can do what, when and where. Of course, they’re also coupled closely with vCloud Director’s built-in roles that assign those privileges.
Provisioning policies are designed to prevent end users from creating more and more VMs and vApps without thinking about costs or the fact that physical resources are needed to make them run. If virtualization is not free, neither is the cloud .
There are three types of provisioning controls: leases, quotas and limits. The lease controls how long a VM or vApp can run for; they can also apply to how long vApp and vApp template storage is available. For example, a development-based environment might only allow a VM or vApp to live for 14 days. After that time, a lease extension must be reapplied for.
Quotas, on the other hand, are counters for the amount of VMs or vApps an end user can have. These can include VMs that are powered on and running, or VMs that are not powered on but still consume storage.
Limits control how resource-intensive VMs run; these limits can be imposed per-user or per-Organization VDC. They can also be used to limit the number of simultaneous inbound connections each VM is allowed.
vCloud Director roles
There are six main predefined roles in vCloud Director:
- The system administrator, or what I sometimes call the vCloud administrator, is able to create and manage Provider and Organization VDCs, networks and catalogs.
- The organization administrator has rights over Organization VDCs and, as such, can manage access to catalogs and vApps.
- The catalog author is role purely designed to manage catalogs, and the vApp author manages vApps.
- As for the end user, two roles apply to them; vApp user and console access only . The vApp user can leverage vApps have that have been already created; but he or she cannot modify their CPU/memory or disk resources. Similarly, the console access only role allows an end user to open a window on a VM or a vApp and interact with the operating system.
Although the terms can seem somewhat daunting, users should understand and appreciate these concepts before embarking on the initial configuration of vCloud Director.
ABOUT THE AUTHOR:
Mike Laverick (VCP) has been involved with the VMware community since 2003. Laverick is a VMware forum moderator and member of the London VMware User Group Steering Committee. Laverick is the owner and author of the virtualization website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users, and has recently joined SearchVMware.com as an Editor at Large. In 2009, Laverick received the VMware vExpert award and helped found the Irish and Scottish VMware user groups. Laverick has had books published on VMware Virtual Infrastructure 3, VMware vSphere4 and VMware Site Recovery Manager.