In the first two parts of this series, we've discussed the initial setup and the first four steps of VMware vCloud Director configuration. Let's now embark on the last stage of the process: defining the resources available to the Organization Virtual Data Center (vDC). These final four steps cover what organizations have access to in the previously created Provider vDC and network pools. I will also introduce a new resource that can be allocated called the catalog.
Imagine the catalog as an IT brochure that includes the parts you need in your infrastructure. It contains different vApps and media that can be used to build virtual environments.
Step 5: Create a new organization
One of the somewhat misunderstood concepts in vCloud Director is the organization (the organization and the Organization vDC are two separate objects). The organization is a logical construct that represents a functional unit in the business, and there can be many virtual data centers contained in the organization. Organizations may need these different virtual data center resources for their production virtual machines (VMs), proof-of-concepts, and test and development. Each of these Organization vDCs would be backed by the appropriate Provider vDC to offer the correct quality of service necessary.
As you might recall from the first part of this series, Corp, Inc. is our holding company that contains three businesses. Keep in mind, though, that there's nothing enforcing this approach in vCloud Director. You could always partition your data center along functional units such as purchasing, distribution and so on.
Organizational names can only contain alphanumeric characters; this creates virtual direction on the vCloud Director server. The full name is what most folks would call the "friendly name," and it's what will be seen on the Welcome screen when logging in for the first time. Alongside creating the organizational object in vCloud Director, you will also be-given the opportunity to control authentication, permissions, rights and email notifications.
Authentication settings present the ability to create users locally on the vCloud Director server. It's recommended that even if you configure vCloud Director to communicate with an LDAP service, there should be at least one local user configured with the "organization administrator" role. That way, control can still be delivered even if the LDAP service is unavailable.
LDAP access configuration depends greatly on the relationships involved. If the organization is a member of the same company as the provider, you would use the "Custom LDAP Service" option and the LDAP Distinguished Name syntax. If, on the other hand, the organization was entirely separate -- as would be the case with a public cloud service provider -- it is possible to link the service provider into the customer's vDC using "vCloud Director system LDAP service."
After creating the local organization administrator, you can then control the organization's rights and privileges. You won't see the ability to assign these privileges in the wizard, but it is possible to "import" the LDAP information and allocate users once the organization has been defined.
It is possible for an organization to have and maintain its own "catalog" separately from the central published catalog of the vCloud Director. Again, this might be more appropriate in a situation where all organizations are unrelated. In that case, each organization would be an entirely separate entity.
In this situation, I wanted to create a centralized catalog that each organizational unit can refer to and to give the vCloud Director administrator control over what is available to each organization. To do this, Corp, Inc. would need to have an organization and Organization vDC with a "published" catalog, which makes it available to the other Organization vDCs.
The wizard for creating a new Organization vDC includes an option to enable the sending of emails from vCloud Director to the organization administrators, including automatically generated systems emails, and allowing the vCloud administrator to send emails as well. This is a fairly simple routine, similar to other management systems, of inputting the correct SMTP settings.
Controls on Organization vDC use can act as a policy system designed to stop the incorrect use of cloud resources while also allowing for the setup of leases, quotas and limits. The "lease" controls how long a particular vApp is allowed to run for; "quotas" control the number of VMs the user can run and store; and "limits" prevents certain tasks from overwhelming the system with simultaneous requests.
A combination of lease, quota and limits prevents any users in the Organization vDC from trying to create thousands of vApps at one time. They act as additional controls on top of the limits implicit in the difference between a "gold" Provider vDC and a "silver" Provider vDC. Of course, these controls are likely to be much more stringent in a organization designed for use by developers as compared to the ones applied to an Organization vDC, which is running production VMs that are accessed by users on a regular basis.
Step 6: Allocate resources to an organization
Now that the organizations are created, we can begin the process of allocating resources to them. If you remember, those resources are represented by previously created Provider vDCs (Gold, Silver and Bronze). This is the first time that organizations will have access to their own virtual data center. One organization can have many Organization vDCs and each Organization vDC can also be backed by a Provider vDC, so the model is very flexible. It is also possible to move vApps from one Organization vDC to another, but you would have power down the vApp to complete the move.
When creating an Organization vDC, you will be asked a number of questions. Decide which Provider vDC will back it and what allocation model you will use. There are three choices in this case:
- Allocation pool
- Reservation pool
All three will create a vSphere resource pool from the cluster that backs the Provider vDC. With the allocation pool, you can specify a percentage of allocated resources that will commit to the Organization vDC. This makes it possible to overcommit resources and allocate more CPU and memory than whatever is physically available. Meanwhile, the reservation pool can also overcommit resources, as it directs all allocated resources to the Organization vDC. This is very similar to when VMs are created with a greater allocation of resources than what is necessary.
Pay-as-you go, on the other hand, creates a resource pool and then allocates flat chunks of memory and CPU to each VM in the pool. And if you are using a chargeback model, it only collects chargeback data when the vApp is powered on and in use (although you are still charged for any storage consumed). In my case, I chose an allocation pool for one Organization vDC and used a pay-as-you-go model for the two others.
Begin by selecting the "Allocate resources to an organization" link and selecting which organization will receive the resources.
After selecting both the Provider vDC and the allocation model, you will also be able to assign the amount of storage use and thin provisioning support.
Next, you will be able to assign the already-defined network pool and name the Organization vDC. If you have used either the VLAN-backed or VCD network isolation-backed network pools, you will be able to set a quota of networks to the Organization vDC. It's possible to overcommit the amount of networks, but my network pool contains only three.
Repeat this process for each organization by creating an Organization vDC for each type of activity that takes place. This process of adding Organization vDCs will create a resource pool on the cluster selected as part of the Provider vDC's definition. Because I was forced to use resource pools, they actually appear as child resources pools.
Figure 10: The available resource pools
Step 7: Add a network to an organization
The next step involves stitching the various network components together that make up vCloud Director implementation. So far, we have created both external networks and network pools. These need to be brought together and allocated to the appropriate organizations that have recently been established. In a very helpful way, the vCloud Director wizard gives you a diagram of the possible network configurations:
Figure 11: Setting up a network (Click to enlarge)
Note: Technically, the term "routed connection" is somewhat inaccurate. vShield's is not a router; it actually uses "network address translation" to allow traffic out of the internal network.
By default, vCloud Director will assume you want an internal network provided by the resources in the network pool, as well as access to the external network. It will also assume that you will use the vShield appliance to connect these two separate networks. This is indicated by the red brick icon in the blue circle and can be enabled by selecting "routed connection" in the pull-down list.
If you instead choose "direct connection," you will see this icon disappear. This indicates that you will let the vApps speak directly to the external network. Essentially, this controls whether or not you wish to use the vShield's appliance in this particular configuration.
Other configurations are also available. For example, if you wanted this network to have no access to the external network, you could simply remove the checkmark next to "Create an external network." This would create a network where someone could build vApps but not connect them to the corporate network or the Internet. In my case, I accepted the default settings so I could later use all the vShield features, including the MAC-in-MAC encapsulation to create discrete networks.
After you have selected the correct network pool for the organization in question, you can then create an IP configuration for the internal network. vCloud Director automatically adds the 192.168.1.x network, along with a range of internal IP address from 192.168.1.100 to 192.168.3.199. All that you have to do is provide business-related information like primary and secondary DNS IP addresses and the domain name. This process will be repeated later for the external network.
Finally, select the external and internal networks that will communicate with the model you selected earlier.
Step 8: Add a catalog to an organization
This is the final step: creating and allocating a catalog. If you remember, the catalog is like a brochure of vApps for the end user, and there are a number of ways to manage it. Each organization can have a catalog of its own that others cannot see, which must be set when you first create the organization. This makes the most sense in a public cloud environment where each business in the vCloud Director environment is entirely separate from the others and where they would need to independently manage their own library of vApps.
The important thing to remember about catalogs is that, to create one, you must have an organization and at least one Organization vDC available. It's not possible to create a catalog that lives independently from the organization and Organization vDC.
I think it is easier to create a centralized catalog using the management pages rather than the wizard, as this will allow you to modify the permissions and make it available to other organizations. Start by confirming that the organization in question has the rights to publish its catalog. Click "Manage & Monitor," then "Organizations." Right-click the organization in question, select "Properties" and choose the "Catalog Publishing" tab:
Next select the organization and the "Catalog" tab. Once there, click the green button to add a catalog. Once you have given the catalog a name, you can allocate members. You have the choice of granting access to everyone in the organization or to specific user and groups. You can also decide if the catalog will be read only, read/write or full control.
Once the catalog is created, it can be populated. You can use the export function in vSphere to extract existing VMs in an OVF format and import them into vCloud Director, or you could select VMs directly in vSphere and copy them into the vCloud Director environment.
On the surface, the eight steps of vCloud Director configuration look very simple. The truth, however, is that each of these steps has even more steps underneath. But this quick overview should help answer any questions you will be asked in the post-configuration of vCloud Director. Keep in mind that the journey to the cloud will not be taken by simply clicking "next" at every juncture and hoping for the best.
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.