11 min read

 In this article by Giordano Scalzo, the author of Learning VMware App Volumes, we are going to look a little deeper into the different component parts that make up an App Volumes solution. Then, once you are familiar with these different components, we will discuss how they fit and work together.

(For more resources related to this topic, see here.)

App Volumes Components

We are going to start by covering an overview of the different core components that make up the complete App Volumes solution, a glossary if you like. These are either the component parts of the actual App Volumes solution or additional components that are required to build your complete environment.

App Volumes Manager

The App Volumes Manager is the heart of the solution. Installed on a Windows Server operating system, the App Volumes Manager controls the application delivery engine and also provides you the access to a web-based dashboard and console from where you can manage your entire App Volumes environment.

You will get your first glimpse of the App Volumes Manager when you complete the installation process and start the post-installation tasks, where you will configure details about your virtual host servers, storage, Active Directory, and other environment variables.

Once you have completed the installation tasks, you will use the App Volumes Manager to perform tasks, such as creating new and updating existing AppStacks, creating Writable Volumes as well as then assigning both AppStacks and Writable Volumes to end users or virtual desktop machines.

The App Volumes Manager also manages the virtual desktop machine that has the App Volumes Agent installed. Once virtual desktop machine has the agent installed, then it will then appear within the App Volumes Manager inventory so that you are able to configure assignments.

In summary the App Volumes Manager performs the following functions:

It provides the following functionality:

  • Orchestrates the key infrastructure components such as, Active Directory, AppStack or Writable Volumes attachments, virtual hosting infrastructure (ESXi hosts and vCenter Servers)
  • Manages assignments of AppStack or Writable Volumes to users, groups, and virtual desktop machines
  • Collates AppStacks and Writable Volumes usage
  • Provides a history of administrative actions
  • Acts as a broker for the App Volumes agents for automated assignment of AppStacks and Writable Volumes as virtual desktop machines boot up and the end user logs in
  • Provides a web-based graphical interface from which to manage the entire environment

Throughout this article you will see the following icon used in any drawings or schematics to denote the App Volumes Manager.

Learning VMware App Volumes

App Volumes Agent

The App Volumes Agent is installed onto a virtual desktop machine on which you want to be able to attach AppStacks or Writable Volumes, and runs as a service on that machine. As such it is invisible to the end user.

When you attach AppStack or Writable Volume to a virtual machine, then the agent acts as a filter driver and takes care of any application calls and file system redirects between the operating system and the App Stack or Writable Volume.

Rather than seeing your AppStack, which appears as an additional hard drive within the operating system, the agent makes the applications appear as if they were natively installed. So, for example, the icons for your applications will automatically appear on your desktop/taskbar.

The App Volumes Agent is also responsible for registering the virtual machine with the App Volumes Manager.

Throughout this article, you will see the following icon used in any drawings or schematics to denote the App Volumes Agent.

Learning VMware App Volumes

The App Volumes Agent can also be installed onto an RDSH host server to allow the attaching of AppStacks within a hosted applications environment.

AppStacks

An AppStack is a read-only volume that contains your applications, which is mounted as a Virtual Machine Disk file (VMDK) for VMware environments, or as a Virtual Hard Disk file (VHD) for Citrix and Microsoft environments on your virtual desktop machine, or RDSH host server.

An AppStack is created using a provisioning machine, which has the App Volumes Agent installed on it. Then, as a part of the provisioning process, you mount an empty container (VMDK or VHD file) and then install the application(s) as you would do normally. The App Volumes Agent redirects the installation files, file system, and registry settings to the AppStack. Once completed, AppStack is set to read-only, which then allows one AppStack to be used for multiple users. This not only helps you reduce the storage requirements (an App Stack is also thin provisioned) but also allows any application that is delivered via AppStack to be centrally managed and updated.

AppStacks are then delivered to the end users either as individual user assignments or via group membership using Active Directory.

Throughout this article, you will see the following icon used in any drawings or schematics to denote AppStack.

Learning VMware App Volumes

Writable Volumes

One of the many use cases that was not best suited to a virtual desktop environment was that of developers, where they would need to install various different applications and other software. To cater for this use case, you would need to deploy a dedicated, persistent desktop to meet their requirements. This method of deployment is not necessarily the most cost-effective method, which potentially requires additional infrastructure resources, and management.

With App Volumes, this all changes with the Writable Volumes feature. In the same way as you assign AppStack containing preinstalled and configured applications to an end user, with Writable Volumes, you attach an empty container as a VMDK file to their virtual desktop machine into which they can install their own applications.

This virtual desktop machine will be running the App Volumes Agent, which provides the filter between any applications that the end user installs into the Writable Volume and the native operating system of the virtual desktop machine. The user then has their own drive onto which they can install applications.

Now you can deploy nonpersistent, floating desktops for these users and attach not only their corporate applications via AppStacks, but also their own user-installed applications via a Writable Volume.

Throughout this article, you will see the following icon used in any drawings or schematics to denote a Writable Volume.

Learning VMware App Volumes

Provisioning virtual machine

Although not an actual part of the App Volumes software, a key component is to have a clean virtual desktop machine to use as reference point from which to create your AppStacks from. This is known as the provisioning machine.

Once you have your provisioning virtual desktop machine, you first install the App Volumes Agent onto it. Then, from the App Volumes Manager, you initiate the provisioning process, which attaches an empty VMDK file to the provisioning virtual desktop machine, and then prompts you, as the IT admin, to install the application.

Before you start the installation of the application(s) that you are going to create as AppStack, it’s a good practice to take a snapshot before you start. in this way, you can roll back to your clean virtual desktop machine state before installation, ready to create the next AppStack.

Throughout this article, you will see the following icon used in any drawings or schematics to denote a provisioning machine.

Learning VMware App Volumes

A Broker Integration service

The Broker Integration service is installed on a VMware Horizon View Connection Server, and it provides faster log on times for the end users who have access to a Horizon View virtual desktop machine.

Throughout this article, you will see the following icon used in any drawings or schematics to denote the Broker Integration Service.

Learning VMware App Volumes

Storage Groups

Again, although not a specific component of App Volumes, you have the ability to define Storage Groups to store your AppStacks and Writable Volumes.

Storage Groups are primarily used to provide replication of AppStacks and distribute Writable Volumes across multiple data stores. With AppStack storage groups, you can define a group of data stores that will be used to store the same AppStacks, enabling replication to be automatically deployed on those data stores.

With Writable Volumes, only some of the storage group settings will apply attributes for the storage group, for example, the template location and distribution strategy.

The distribution strategy allows you to define how writable volumes are distributed across the storage group. There are two settings for this as described:

  • Spread: This will distribute files evenly across all the storage locations. When a file is created, the storage with the most available space is used.
  • Round-Robin: This works by distributing the Writable Volume files sequentially, using the storage location that was used the longest amount of time ago.

In this article, you will see the following icon used in any drawings or schematics to denote storage groups.

Learning VMware App Volumes

We have introduced you to the core components that make up the App Volumes deployment.

App Volumes Architecture

Now that you understand what each of the individual components is used for, the next step is to look at how they all fit together to form the complete solution.

We are going to break the architecture down into two parts. The first part will be focused on the application delivery and virtual desktop machines from an end user’s perspective.

In the second part, we will look more at the supporting and underlying infrastructure, so the view from an IT administrator’s point of view.

Finally, in the infrastructure section, we will look at the infrastructure with a networking hat on and illustrate the various network ports we are going to require to be available to us.

So let’s go back and look at our first part, what the end user will see.

In this example, we have a virtual desktop machine to run a Windows operating system as the starting point of our solution. Onto that virtual desktop machine, we have installed the App Volumes Agent.

We also have some core applications already installed onto this virtual desktop machine as a part of the core/parent image. These would be applications that are delivered to every user, such as Adobe Reader for example. This is exactly the same best practice as we would normally follow in any other virtual desktop environment. The updates here would be taken care of by updating the parent image and then using the recompose feature of linked clones in Horizon View.

With the agent installed, the virtual desktop machine will appear in the App Volumes Manager console from where we can start to assign AppStacks to our Active Directory users and groups.

When a user who has been assigned AppStack or Writable Volume logs in to a virtual desktop machine, AppStack that has been assigned to them will be attached to that virtual desktop machine, and the applications within that AppStack will seamlessly appear on the desktop.

Users will also have access to their Writable Volume. The following diagram illustrates an example deployment from the virtual desktop machines perspective, as we have just described.

Learning VMware App Volumes

Moving on to the second part of our focus on the architecture, we are now going to look at the underlying/supporting infrastructure.

As a starting point, all of our infrastructure components have been deployed as virtual machines. They are hosted on the VMware vSphere platform.

The following diagram illustrates the infrastructure components and how they fit together to deliver the applications to the virtual desktop machines.

Learning VMware App Volumes

In the top section of the diagram, we have the virtual desktop machine running our Windows operating system with the App Volumes Agent installed. Along with acting as the filter driver, the agent talks to the App Volumes Manager (1) to read user assignment information for who can access which AppStacks and Writable Volumes.

The App Volumes Manager also communicates with Active Directory (2) to read user, group, and machine information to assign AppStacks and Writable Volumes. The virtual desktop machine also talks to Active Directory to authenticate user logins (3).

The App Volumes Manager also needs access to a SQL database (4), which stores the information about the assignments, AppStacks, Writable Volumes, and so on. A SQL database is also a requirement for vCenter Server (5), and if you are using the linked clone function of Horizon View, then a database is required for the View Composer.

The final part of this diagram shows the App Volumes storage groups that are used to store the AppStacks and the Writable Volumes. These get mounted to the virtual desktop machines as virtual disks or VMDK files (6).

Following on from the architecture and the how the different components fit together and communicate, later we are going to cover which ports need to be open to allow the communication between the various services and components.

Network ports

Now, we are going to cover the firewall ports that are required to be open in order for the App Volumes components to communicate with the other infrastructure components.

The diagram here shows the port numbers (highlighted in the boxes) that are required to be open for each component to communicate.

Learning VMware App Volumes

It’s worth ensuring that these ports are configured before you start the deployment of App Volumes.

Summary

In this article, we introduced you to the individual components that make up the App Volumes solution and what task each of them performs. We then went on to look at how those components fit into the overall solution architecture, as well as how the architecture works.

Resources for Article:

 


Further resources on this subject:


LEAVE A REPLY

Please enter your comment!
Please enter your name here