Getty Images
Learn vSphere vApps creation, deployment and configuration
VApps in vSphere can combine VMs into a single location for resource management and have configurations for start and stop processes that improve application performance.
A vApp isn't a commonly known feature in vSphere. VSphere vApps are implicit resource pools that let you set limits, reservations and shares for resources as well as start and stop VMs within a vApp.
VMware vApps combine VMs to create tiered applications, which you can then manage through vSphere. You can create, deploy and configure vSphere vApps directly through your host or cluster, which improves resource management initiatives. You can also manage start and stop processes for VMs within vApps; this ensures VMs execute their operations in an orderly manner and use resources sufficiently.
To better manage your vApps and their resources, you must understand how vApps differ from resource pools, the challenges that come with vApps, and how to properly create and configure vApps in vSphere.
An introduction to VMware vApps in vSphere
Before you evaluate vSphere vApps, first understand that there's no relationship between vApps in vSphere and vApps in VMware Cloud Director. Both types of vApps combine VMs that belong together, but that's where the similarities end. VMware developed vApps for vSphere and Cloud Director approximately at the same time, but they have different implementation strategies.
At first sight in the vSphere Client, a vApp looks similar to a VM storage folder; you might also see this setup with resource pools. Resource pools look like a folder, but they serve a completely different purpose -- just as vApps do. Though unlike resource pools, vApps are tiered applications that contain several different VMs, including database servers, application servers and web servers.
Figure 1 shows a vApp named CMS-App-01, which contains four VMs: a database server, an application server and two web servers. Together, these four VMs form a tiered application. Figure 1 also displays the resource allocations for each VM, such as the memory resource details.
These resource allocations act as resource pools for each VM; a vApp is an implicit resource pool. All features available to manage resources with limits, reservations and shares are also available for a vApp to use -- the process works in the same way for both resource pools and vApps.
One feature that sets vApps apart from regular resource pools is you can start and stop VMs within a vApp.
The drawbacks of vSphere vApps
VSphere vApps are implicit resource pools, which means you can face similar challenges that affect resource pools. For example, if the balance of shares or the configuration of reservations and limits isn't properly designed, resource contention and performance issues can occur.
VSphere 7 introduced a scalable shares feature to mitigate these issues, which are available for resource pools and vApps. Scalable shares prevent a single resource pool from having more VMs than other resource pools. The larger the imbalance, the more likely a resource pool has less shares per VM.
A resource pool with fewer VMs than other resource pools can also become unbalanced. The resource pool with a lower number of VMs has more shares per VM. So be sure to enable scalable shares when you create vApps in vSphere.
Create and clone vApps in vSphere
To create vApps, select the New vApp option found in the context menu of a host or cluster. In Figure 2, when you select the New vApp option, a dialog box opens that enables you to create a new vApp or clone an existing one.
The New vApp option also sets a vApp aside from regular resource pools because you can now clone an entire stack of VMs with a single action. Traditionally you would have to clone VMs in a resource pool one by one.
Once you create a vApp, you can drag and drop additional VMs into the vApp or create new VMs from scratch. Another possibility vApps offer is you can export an entire set of VMs within a vApp in OVF format. With one click, you can export multiple VMs.
How to configure vSphere vApps
Because resource management for a vApp is similar to a resource pool, you might wonder why you don't place a VM within a resource pool.
One feature that sets vApps apart from regular resource pools is you can start and stop VMs within a vApp with a single power on or power off action. Figure 3 shows a vApp with the options to power on, power off, suspend and shut down in the menu.
If the VMs are in a power off state, the power on option enables you to start all VMs within the vApp with a single click. It's possible to stop and start VMs individually, but for a tiered application it's more practical to start and stop the entire stack.
When you start or stop VMs within a vApp you should do so in a specific order. For a tiered application, first start with the database server, then the application server and lastly the web servers. If you initiate a shutdown, repeat those steps but in the reverse order.
You can configure start and stop processes in the settings of the vApp under the Start Order option. In Figure 4, you can see that the database server is in Group 1, the application server in Group 2 and the two web servers in Group 3. Each VM starts in the numerical order of these groups and shut down in the reverse order.
You can change the amount of time it takes before vSphere begins to start or stop the next VM group or keep the default of 120 seconds. Another option is to continue the start and stop processes when the VMware Tools are available. This means the next group starts once vSphere completely powers on the OSes in the first group -- otherwise the VMware Tools aren't fully loaded.
This method doesn't guarantee that vSphere fully initializes the necessary services. For example, if the application server depends on the database server, but the database server isn't fully functional, then vSphere might require additional time before it can start the next group.
The best approach is to handle start and stop processes in the application stack itself. An application server should try to access the database server and if the database server isn't available, application server should try again. When the full stack is fully initialized, it's then available for client connections.
