- "Do I Know This Already?" Quiz
- Foundation Topics
- Exam Preparation Tasks
This chapter is from the book
This chapter is from the book
This chapter is from the book
Foundation Topics
What Is a vCloud Resource?
VMware defines cloud resources in two sections, compute and network resources. vCenter Server clusters and vSphere hosts provide compute resources, while vCloud Networking and Security (in conjunction with vCenter Server) provides the network resources. We covered network resource configuration and allocation in Chapter 6, “Configure and Administer vCloud Networking.”
vCloud Director enables compute resources to be provisioned using a provider virtual datacenter (vDC), assigned to organizations through organization vDCs, and finally consumed by users through containers called vApps.
In this chapter, we discuss compute resources and how vCloud Director presents those resources to you, the cloud administrator. Then, we explain how to define the consumption model for those resources, and ultimately how the end user consumes the resources provided.
Create and Administer Provider vDCs
vCloud Director’s first abstraction of resources is the provider virtual datacenter, commonly referred to as a provider vDC. A provider vDC takes the compute and memory resources from a vCenter Server resource pool and combines them with one or more available datastores to create a group of resources available within the cloud. These resources are then provisioned to one or more organization virtual datacenters (org vDCs). We cover org vDCs in the next section.
A provider vDC is a combination of one or more resource pools or clusters defined by vCenter Server. If multiple resource pools are provisioned to a single provider vDC, that provider vDC is considered an elastic provider vDC.
What Is an Elastic Provider vDC?
When VMware released vCloud Director 1.5, it incorporated the capability to include more than one resource pool per provider vDC for a Pay-as-You-Go allocation model. With the release of 5.1, VMware expanded this capability to include the Allocation Pool allocation model. When configured with multiple resource pools, these elastic provider vDCs provide the flexibility for cloud resources to be scaled as needed.
Several things must be in place and working for an elastic provider vDC to function properly. First, the resource pools must exist in the same vCenter Server and the same vCenter Server Datacenter. Second, the network pool that is backing the workloads must be capable of being extended to all resource pools used by the provider vDC. This extension is necessary to avoid issues with network communication between virtual machines (VMs). Finally, the storage between the resource pools should be shared. If the storage is not shared, deployment times are greatly extended. This is due to the fact that vCloud Director must export the VM using the Export Open Virtualization Format (OVF) process and then reimport the VM to the other resource pool’s storage.
Activity 8-1: Creating a Provider vDC
- Log in to vCloud Director, and click the Manage & Monitor tab.
Click the Provider VDCs option in the left pane, as shown in Figure 8-1.
Figure 8-1 Provider vDC Selection
Click the green + or the blue gear symbol, and select New Provider VDC, shown in Figure 8-2.
Figure 8-2 Add New Provider vDC
Type in a name and description.
Figure 8-3 Provider vDC Naming
Select the highest VM Hardware version that your vSphere installation supports, as shown in Figure 8-4.
Figure 8-4 VM Hardware Selection
Next, as shown in Figure 8-5, select the vCenter Server and the resource pool that this provider vDC will consume.
Figure 8-5 vCenter and Resource Pool Selection
Select the appropriate storage profile for this provider vDC. Figure 8-6 shows the Any profile selected.
Figure 8-6 Storage Profile Selection
- Click Finish.
)
)
)
)
)
)
Prepare a Provider vDC
After you have created your first provider vDC, you must prepare the hosts that will provide the physical resources to that provider vDC. Until the hosts are prepared by vCloud Director, they cannot be used to host a vCloud workload.
Activity 8-2: Preparing a Host
- Click the Manage & Monitor tab, and then select the Provider VDCs option in the left pane.
Find the provider vDC with hosts that need prepared; then right-click it and select Open, as shown in Figure 8-7.
Figure 8-7 Provider vDC Selection
As shown in Figure 8-8, select the Hosts tab.
Figure 8-8 Host Selection
Select the hosts to prepare; then right-click and select Prepare Host, as shown in Figure 8-9.
Figure 8-9 Prepare Host Selection
Enter a username and password of a user who has administrator privileges on the vSphere host. Figure 8-10 shows an example using root, which is the most common user used.
Figure 8-10 Username Input
Verify that the hosts have been prepared properly. The host in Figure 8-11 has been successfully provisioned.
Figure 8-11 Host Successfully Provisioned
)
)
)
)
)
Enable Provider Storage
After the hosts have been enabled for the cloud, you must verify that the storage presented to those hosts is available for usage. This requires a storage profile to be created in vCenter Server and attached to the datastores on the hosts. After the storage profile is created and presented, you can enable it in the provider vDC inside of vCloud Director.
vCloud Director 5.1 uses the vCenter Server Storage Profile service for combining and utilizing datastores. A storage profile must be created and defined by a vCenter Server administrator. If the administrator neglects this step, the *(Any) storage profile is used, which includes any datastore that is not assigned to a storage profile. A storage profile consists of storage capabilities that can be user defined or vendor defined. If you have a large infrastructure and require the ability to segment your storage, you might need to create user-defined storage capabilities and selectively assign them to storage profiles.
We cover how to check the storage profile and how to attach it to a provider vDC in Activity 8-3.
Activity 8-3: Assigning a Storage Profile to a Datastore
- Log in to the vCenter Server to which vCloud Director is attached.
- Select Management > VM Storage Profiles > [Datacenter Name].
- Click Create New VM Storage Profile.
Select a name that is unique to this vCenter Server or Cluster to reduce confusion later, similar to the profile being created in Figure 8-12.
Figure 8-12 Storage Profile Creation in vCenter
Select the vendor- or user-defined storage capabilities for this profile. Figure 8-13 shows an NFS profile being selected.
Figure 8-13 Storage Capabilities in vCenter
Select the Inventory > Datastores and Datastore Cluster View. Now select each datastore and verify that the proper user-defined storage capability has been assigned to the datastores, as shown in Figure 8-14.
Figure 8-14 Storage Profile Assignment
)
)
vCloud Director should now display the available storage profiles in the system administrator view. If the profiles are not visible, a problem has occurred. Troubleshooting storage profiles is covered in the next section.
Decommission a Provider vDC
In the lifecycle of a vCloud deployment, there might come a time when you need to decommission a provider vDC, or possibly a storage profile. This task is not as simple as just powering on the new provider vDC and powering down the old infrastructure. The process can vary based on the hardware and the use of the hardware that is being replaced. For the purpose of the VCP-Cloud and VCP-IaaS exams, we cover only the disabling and deleting of a provider vDC and the addition of a storage profile to a provider vDC.
Disabling a provider vDC does not power off the existing vApps, stop access to the associated network, or delete files from the storage profile. Disabling the provider vDC stops vCloud Director from adding new workloads to the provider vDC and prevents the powering on of any vApp that might be powered down. You can still migrate vApps or workloads off of the provider vDC.
Activity 8-4: Disabling a Provider vDC
Open the vCloud Director user interface (UI), as shown in Figure 8-15.
Figure 8-15 vCloud Director UI
Select the Manage & Monitor tab, and then select the Provider vDCs option in the left pane, as shown in Figure 8-16.
Figure 8-16 Manage & Monitor Tab
Right-click the provider vDC that is to be disabled, such as the one shown in Figure 8-17, and then select Disable.
Figure 8-17 Disabling a Provider vDC
)
)
)
After the provider vDC is disabled, you must remove the resources allocated to the provider vDC before it can be removed from vCloud Director. These resources can include networks, vShield Edge devices, storage profiles, org vDCs, catalogs, vApps, and media. We cover the removal of these items in their respective chapters and sections.
Activity 8-5: Deleting a Provider vDC
Open the vCloud Director UI, as shown in Figure 8-18.
Figure 8-18 vCloud Director Main Page
Select the Manage & Monitor tab, and then select the provider vDCs option in the left pane, as shown in Figure 8-19.
Figure 8-19 Manage & Monitor Tab
Right-click the provider vDC that is to be deleted, as shown in Figure 8-20.
Figure 8-20 Deleting a Provider vDC
Select Delete.
If the provider vDC still has a resource assigned to it, you will receive an error similar to that shown in Figure 8-21.
Figure 8-21 Resource Deletion Error
)
)
)
If this happens, find the resource that the error mentions, remove it from the provider vDC, and then attempt the delete operation again. For example, Figure 8-21 shows an error that is a leftover org vDC that must be removed before the provider vDC can be deleted.
After all items are removed, the delete process removes the binding of vCloud Director to the resource pool in vCenter Server. The operation does not remove the vCloud Agents from the hosts—this must be done separately. To do so, navigate to the host tab and select Disable Host and Unprepare Host, as shown in Figure 8-22.
)
Figure 8-22 Disable and Unprepare a Host
Storage Profile in vCenter
It is common for vCenter Server to take a few minutes to sync newly created and defined storage profiles. To speed up this process, you can force a re-sync operation, which is performed from the system administrator view.
Activity 8-6: Syncing vCenter Storage Profiles
Open the vCenter Servers view from the left pane of the Manage & Monitor tab, as shown in Figure 8-23.
Figure 8-23 Manage & Monitor Tab
Right-click the vCenter Server where the storage profile exists, and select Refresh Storage Profiles, as shown in Figure 8-24.
Figure 8-24 Refresh Storage Profiles
Verify that the task completed without error by clicking the Logs menu option on the left pane. View the log status to ensure that the Refresh Storage Profile operation completed without error. The log should look similar to the one shown in Figure 8-25.
Figure 8-25 vCloud Director Event Log
)
)
)
){kind=link}
){kind=link}
Create and Administer Organization vDCs
Creating a provider vDC provides resources that can be provisioned to the organizations in the cloud. This is accomplished through the creation of organization virtual datacenters (org vDCs). An org vDC is how vCloud Director defines a space for vApps to be stored and run, as well as a space for CD-ROM (.iso) and floppy image (.flp) files to be stored. The org vDC provisions resources to an organization (or group within an organization) by defining the CPU, RAM, storage, and network resources that will be available to vApps within the org vDC.
When creating an org vDC, an important step is choosing the appropriate allocation model. The allocation model determines how resources are allocated by the org vDC. The three allocation models are Pay-as-You-Go, Allocation Pool, and Reservation Pool. An organization’s service-level agreement (SLA), operational level agreement (OLA), and other agreements typically determine the allocation model that will be used by the org vDC. The three allocation models provision resources as follows:
Pay-as-You-Go
- Resources are not allocated in advance.
- Resources are reserved as vApps are powered on.
- A percentage of resources can be reserved.
- vCPU speed rating is adjustable.
Allocation Pool
- A percentage of resources is allocated in advance.
- This percentage of resources is reserved.
- Cloud administrators control the amount of over commit.
- Resources are sharable between org vDCs.
Reservation Pool
- All resources are allocated and reserved in advance.
- Users are able to adjust individual VM priorities and resources.
- No sharing of resources with other org vDCs.
Pay-As-You-Go
The Pay-As-You-Go (PAYG) allocation model most closely resembles the Amazon EC2 model, in which the compute resources are defined on a per-VM basis. PAYG allows for performance guarantees on each VM as well as limits for each VM. The benefit of PAYG is that the provider vDC’s resources are consumed only when a VM or vApp is powered on.
When a VM or a vApp is powered on, vCloud Director places the vApp into the provider vDC that is assigned to the org vDC. After the VM is placed into a resource pool, it is configured with the limits and guarantees that are defined by the org vDC.
PAYG allocation models are unique in that they allow you to place limits on a single VM and not the entire resource pool, while still allowing for a % reservation. A PAYG model is ideal for use cases where noisy neighbors are a concern. PAYG enables you, the cloud administrator, to limit the amount of resources a single VM can consume.
It should be noted that there is some risk with using a PAYG allocation model. Because there are no pre-reserved or committed resources, a VM might be unable to power on if the provider vDC is out of resources.
At some point an org vDC configured with the PAYG allocation model might need to be resized. This can be done, but it does require all vApps to be powered down and backed up before the adjustment can be made. Figure 8-26 shows the PAYG org vDC properties.
)
Figure 8-26 Pay-as-You-Go Org vDC Properties
During the creation of a PAYG allocation model, you will define the following:
- CPU Quota—This quota is the limit of CPU resources that an organization can consume at any time. This limit can be higher than the actual resources presented, which gives a cloud administrator the ability to overcommit CPU resources provided by the org vDC.
- CPU Resources Guaranteed—vCenter Server defines this as the reservation on the VM.
- vCPU Speed—In vCenter Server, this is defined as the limit of a VM’s CPU resource. This is a per-CPU value, so the number placed in this field becomes the limit on the CPU of the VM multiplied by the number of vCPUs assigned.
- Memory Quota—Much like the CPU quota, this is the limit of memory for an org vDC. This limit will most likely be higher than the physical memory in the backing provider vDCs. Features built in to vSphere such as transparent page sharing, compression, swapping, and ballooning make overallocating memory not only possible but also highly efficient.
- Memory Resources Guaranteed—The guarantee here is placed on the VM itself, meaning that a VM will always have X amount of RAM available.
- Maximum Number of VMs—It might seem that this field would apply only to powered on VMs or deployed VMs, but this is not the case. For the purpose of this value, a VM is counted as ANY VM in the org vDC. This includes catalog items and powered-off and powered-on VMs.
To bring all these concepts together, consider the following example. An org vDC with a CPU reservation of 20% and a vCPU speed of 2.5GHz will produce a limit of 5GHz with 1GHz being reserved on a 2 vCPU VM. That same VM with 12GB of assigned RAM and a 10% guarantee will have a 1.2GB reservation for RAM (plus the virtualization overhead).
The PAYG allocation method can also present a billing problem to end users in a service provider model. The billing process for PAYG varies and can be unpredictable from month to month. That being said, PAYG does provide the best method of accounting for the actual resources used by an organization because both of the other allocation models require a pre-purchased amount of resources.
Allocation Pool Model
An Allocation Pool is the second most commonly used allocation model in vCloud Director deployments. An Allocation Pool model gives you the ability to overcommit resources while still limiting the amount of resources an organization consumes.
Much like PAYG, an Allocation Pool model can be elastic. This means it can span multiple resource pools inside a single provider vDC. While providing a great deal of flexibility, this can complicate the troubleshooting of resources should a resource-related problem arise.
For example, assume you have a provider vDC with multiple resource pools, with multiple organization vDCs provisioned. A vApp could span resource pools, which could result in decent performance for VMs in one resource pool but heavily overcommitted VMs in another resource pool. Because DRS does not balance VMs between resource pools, and vCloud Director’s placement engine runs only on power-on, this is a very real concern and possibility.
Unlike a PAYG model, the Allocation Pool model enables you to adjust resources and their commitments without causing a need to redeploy VMs. Figure 8-27 shows the Allocation Org vDC properties page.
)
Figure 8-27 Allocation Model Org vDC Properties
During the creation of an org vDC with the Allocation Pool model, you define the following:
- CPU Allocation—Like the PAYG allocation model, this is the limit of resources for the entire org vDC. This limit is placed on the resource pool that was created by vCloud Director in vCenter Server. By placing a number higher than the physical resources, you are able to overcommit the CPU resources in the org vDC.
CPU Resources Guaranteed—Unlike the PAYG model, the CPU resource guarantee is not defined on the individual VM. This reservation is placed on the org vDC’s resource pool in vCenter Server. What an Allocation Pool model does not protect against is the possibility of a single VM compromising the rest of the machines in the org vDC. That said, this model will always guarantee resources to the org vDC even if other tenants or org vDCs in the provider vDC are consuming all their resources.
This guarantee is calculated using the vCPU speed defined by the CPU allocation. For example, a vCPU speed of .5GHZ and a 10% reservation results in a 50MHz reservation on the org vDC resource pool.
- vCPU Speed—Also unlike the vCPU speed in the PAYG model, the vCPU speed for an Allocation Pool org vDC defines a value used to calculate the amount of resources to reserve. This does not place a limit on the VM or the resource pool. The vCPU speed is used only to calculate the reservation that should be placed on the org vDC resource pool.
- Memory Allocation—Much like the PAYG model, this defines the maximum amount of RAM that can be allocated to VMs. Even if a VM is using only 1GB of RAM, if it is configured with 100GB of RAM, the VM will consume 100GB of RAM out of the Allocation Pool.
- Memory Resources Guaranteed—Like the CPU resources guaranteed, this value is used to calculate how much RAM is reserved for the VM. Unlike the PAYG model, this reservation is not placed on the VM itself, but on the org vDC’s resource pool in vCenter Server.
- Maximum Number of VMs—This field is the same as PAYG. Any VM that is defined, including catalog items, powered-off VMs, and powered-on VMs, are included in this value.
To bring all the concepts together for an Allocation Pool model org vDC, consider the following example. Assume you have an Allocation Pool org vDC defined with an allocation of 100GHz, vCPU speed of 2GHz, and a CPU guarantee of 50%. For each 2vCPU VM that is powered on in the org vDC, vCloud Director will reserve 2GHz of compute power for that VM.
The same applies to the memory allocation. Let’s say the Allocation Pool org vDC is configured with 200GB of memory allocation and 50% guaranteed. A VM with a memory allocation of 50GB will receive an allocation from vCloud Director of 50GB from the 200GB available to the org vDC and set a reservation on the vCenter Server resource pool of 25GB.
The Allocation Pool model allows for more predictable billing for customers of service providers. It also enables a service provider’s charge in an overage billing model, much like a 95th percentile-billing model.
A benefit of the Allocation Pool and PAYG allocation models is that they are dynamic. For each VM that is powered on, vCloud Director calculates the settings for the resource pool and reapplies the proper settings. This is different from the process used by the final