The App Volumes architecture

Now that you understand what each of the inpidual 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 three 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 closely at the supporting and underlying infrastructure, that is, 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 will 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 running Windows as the starting point of our solution. Onto that virtual desktop machine, we have installed an App Volumes Agent.

We also have some core applications already installed onto this virtual desktop machine that part of the core/parent image. These will be applications that are delivered to every user, such as Adobe Reader. This is exactly the same best-practice method as we would normally follow in any other VDI. 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 assigning AppStacks to our Active Directory users and groups.

When a user who has been assigned an AppStack or Writable Volume logs in to a virtual desktop machine, the 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.

They will also have access to their Writable Volume, should one be assigned to them.

The following diagram illustrates an example deployment from the virtual desktop machine's perspective, as we have just described:

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 and 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:

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

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

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.

We will discuss integration with Horizon View and the associated architecture in Chapter 9, Horizon View Integration.

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

Following on from the architecture and the way the different components fit together and communicate, in the next section we will cover which ports need to be open to allow communication between the various services and components.