TABLE OF CONTENTS
• VMware vCloud Director: Ready for launch
• Software and licensing requirements for vCloud Director
• Setting up VMware vCloud Director
Setting up VMware vCloud Director (vCD) looks to be quite a simple affair. Where some customers might find it a little hairy, however, is trying to get their mind around the new networking concepts it introduces. Once it is set up, the management user interface (UI) looks and feels very much like VMware Lab Manager and the new View 4.5 management interface.
The first step is a relatively simple one: giving vCD the names and authentication details of your vCenter and vSphere environment. This is pretty much a standard task for any application like vCD that has a dependency on vCenter to map its allocated resources. During this process, vCD installs an agent into each ESX host in the clusters discovered. The process also creates what VMware call the "provider" virtual data center (VDC) object. It is a separate construct from the "data center" object in vCenter that you may already be familiar with. It's possible to create multiple VDCs by utilizing VMware clusters and resource pools provided by many vCenter instances and aggregating them into a single vCloud.
Once this "provider" VDC is created, it is then possible to partition it into small units called "organization" VDCs. These virtual data centers could represent different companies in a multi-tenancy scenario. The "provider" VDC objects should allow the cloud administrator to offer different classes or tiers of performance and resiliency based on different qualities of compute or storage.
Each business hosted by vSphere will be presented as an "organization" VDC, and each organization will receive its own unique URL when they login to see their virtual machines (VMs). Organizations don't need to represent businesses in a multi-tenancy configuration; each organization could be a different unit within a business, such as Finance, Distribution and Sales.
VMware is envisioning three different type of organization VDCs. To some degree, these reflect different ways of buying the VM, or different ideological positions that companies will have towards their management. It's most likely that this will be a combination of both, as the first will frequently dictate the second. The first model is a pay-as-you-go approach where there is no upfront resource allocation; resources are consumed on the fly as the environment grows. This model does allow the vCloud administrator to set limits and reserve a percentage of resources to the organization VDC to guarantee quality of service (QoS) agreements.
VMware calls the second model the "reservation pool," where each VDC is given a "container" of resources. These containers are 100% guaranteed to have resources allocated to them. This model does allow the organization administrator to adjust the reservation level as he/she sees fit and use the vSphere "shares" system to triage their resources appropriately. To some degree, I see this "reservation pool" as an extension of the vSphere resource pool feature that has been in existence since Vi3.
The last model for managing resources to the organization is called the "allocation pool." It is very similar in features and attributes to the reservation pool, except with one key distinction: responsibility for setting the reservation and share values is handed over to the vCloud Administrator, with the organization offloading its responsibilities to its provider.
Defining your internal and external networks
The next stage is to define your networks. There are two main types, external and internal. External networks are layer 2 networks, created by VLANs or physical separation, that allows for access to worlds outside of the organization's VDC. Internal networks are ones that map to the networks, which allow the VMs to talk to each other on different VLANs.
There's been a lot of talk about cloud, and it's a relief to finally have a product and tools that actually allow the talk to become reality.
Of course, the concept of the standard vSwitch and the distributed vSwitch haven't been supplanted. Instead, they are augmented with a layer of abstraction, which means the end-user doesn't have to be concerned with the nitty-gritty of which portgroup on vSwitch represents the VLAN they need to use. In addition to these internal networks, the organization VDC also has a brand new feature: network pools. These allow users to spin up a new VM and have it sit on its own isolated network on-demand, whilst it's still able to communicate to the outside world. These networks are created using on a distributed vSwitch, so depending on whether you are an Enterprise Plus customer, this functionality may not be available to you.
Network pools themselves come in three main types: portgroup-backed, VLAN-backed and VMware vCloud Director Network Isolation-backed (VCDNI). With the portgroup-backed type, portgroups are used to represent each network, and they are then manually attached to network pool by the vCloud administrator. With the VLAN-backed network pool, portgroups are dynamically created on-demand, and VLAN tagging is used for security and separation. The VCDNI is very similar but it uses proprietary network isolation technology to add an additional layer of security, in addition to the separation created with VLANs. The important thing to note here is that only the portgroup-backed network pool can be managed with the Cisco Nexus 1000V system; the other two VLAN-backed and VCDNI-backed work natively with vCenter distributed vSwitches.
Enforcing restrictions on VMs and vApps
Once the organization VDC and network pools have been created, it is possible to enforce restrictions in the shape of leases, quotas and limits. The lease value allows the organization administrator to set a time-to-live value on a VM or vApp. You could say that a vApp was only allowed to run for a month, and then its status would have to be reviewed and set to "continue to run." I can see VMware fitting this feature into their Chargeback system so "customers" are billed on a monthly basis for their usage. The lease controls both the time the VM is running and the amount of storage it is consuming. The quota system allows the administrator to set limits on the number of VMs allowed.
For example, a runtime quota of 10 would allow you to run a maximum of 10 machines at one time, although you could have a library of 20. If the quota were configured by store, even if you were running just 10 VMs and had a library of 20, you would pay for the twenty. After all, whether a VM is powered off or on, it is still consuming disk space. The final control of limits allows the organization administrator to set restrictions on the number of simultaneous connections. This should stop some people from spinning up a VM and then inviting a million hits, thus degrading performance for all in a multi-tenancy environment.
The VCD management user interface looks and feels very much like VMware Lab Manager and the new View 4.5 management interface.
Once this process is completed, you can then begin to think about delegating control and allowing access to end users. Currently, vCD has just three different roles or personas: cloud administrator, organization administrator and end user. The cloud administrator manages vCD and can create the provider or organization-based virtual data centers (VDCs), external networks and network pools. The organization administrator can delegate responsibility to end users at the organization level, along with creating catalogs and setting quotas, leases and limits on the VMs or vApps. Finally, end users are allowed to use vApps from the published catalogs and create dynamic vApp networks.
As you would expect with something as big as a cloud environment, VMware has taken steps to be more flexible in handling the authentication of these users. You can use Active Directory (AD), but there is also support for using a central database in the vDC that is totally sealed off from the AD environment. They also support authentication from a LDAP service running in the cloud, as well as allowing a centralized LDAP service that is behind the firewall of each organization VDC.
Talking vCD beta with users
So far, so good. I also decided to reach out to folks who have been involved in the vCD beta, including Charles Gautreaux of thickclouds.com. Gautreaux is one of VMware's big customers, with thousands of VMs. He's also a vExpert like me; I really respect his views, and he's become a bit of touchstone for me in recent years.
Right now, his focus is on automation and workflows. Gautreaux pointed out a limitation in the relationship between vCD and the orchestration layer, specifically VMware Orchestrator (vCO). Right now, vCD and vCO lack two-way communication. vCO is pretty critical in automating certain workflows that are presented up to vCD. Whilst the Orchestrator layer can communicate to the vCloud Director, the vCloud Director cannot send instructions to the vCO to trigger an automated workflow. This two-way communication is really needed to create feedback on whether these jobs have or haven't completed.
Additionally, Gautreaux outlined that the emphasis from VMware has so far been on creating a hybrid cloud model by integrating the public cloud and the private cloud together. This has been at the expense of building a more cohesive suite of management applications. VMware has been very aggressive in acquiring management tools, which don't always integrate seamlessly to each other.
So what's my verdict? I'm very positive. There's been a lot of talk about cloud, and it's a relief to finally have a product and tools that actually allow the talk to become reality. It kind of feels like October of 2003, which was when I first installed vCenter 1.0. I hope that, after VMworld, I'll make another note in my diary of the date I first installed VMware vCloud Director 1.0; my only personal regret is that I didn't make the cut for the beta program.