Phase III - Design and Deploy

Now that you have proved that the solution works within your environment, you can take all the findings from both the assessment and the pilot phases, and start to build out a design for production.

In this section, we are going to cover the main considerations for a successful design, and discuss the general rules of thumb and best practices and then move on to the specifics of sizing the storage requirement, scalability, availability, and also how to architect the solution when deployed as part of a VMware Horizon View virtual desktop solution.

Before we get into the specific areas we are going to touch on, let's look at a couple of best practices when it comes to the App Volumes server and the AppStacks themselves.

App Volumes Manager deployment best practice

In this book, we are using a single App Volumes Manager that is ideal for a test environment during the proof of concept and pilot stages of a project. However, when it comes to a production deployment then you should deploy a minimum of two App Volumes Managers. The minimum number of two servers allows you to effectively remove having a single point of failure in the event that one of the servers fails.

When deploying more than one App Volumes Manager, as you would in production, then it is best practice to deploy a load balancer, as shown in the following diagram:

When using a load balancer, App Volumes will work with any load balancer that supports resolving to a single namespace. Configure your load balancer to use virtual IP addresses.

Configure each of the App Volumes Agents installed on your virtual desktop machines, RDSH servers, and physical desktops, and so on, to point at that virtual IP address of the load balancer.

You could also use a Domain Name System (DNS) server configured as round-robin that resolves to each of your App Volumes Managers in turn. It is also recommended to use DNS aliases when using Windows.

The actual number of servers you deploy is largely dependent on the size of your environment, although a minimum of two is the recommendation for any production environment. A single App Volumes Manager can support up to 10,000 users.

AppStack design considerations

In this next section, we are going to discuss how to design your AppStacks within your environment.

AppStack logical grouping

The first thing we are going to look at in more detail is how to group your AppStacks. This is going to determine who gets which applications, based on Active Directory (AD) membership, and where applications should ideally be grouped, based on AD groups.

Based on your assessment information, you should have built up a picture of your AD groups, your users, and the applications that they use. This should give you an understanding of which end users run which applications, and you can draw up an overview of how your AppStacks will be built and delivered. It may well mean that you need to perform some housekeeping when it comes to your users and their group membership.

If we look at your active directory then the highest level to which we can assign AppStacks is at the Domain Users level. This will basically assign AppStacks to everybody in your environment. As an example, this may be useful if you want to assign particular applications to all users, such as Adobe Reader. This will allow you to perform updates at the AppStack level and not per user.

The next level down might be to have groups at a departmental level; for example, sales, finance, marketing, and so on. This would allow AppStacks to be assigned to users who were just members of that particular active directory group. An example of this is where you have an application that is specific to a particular department. For example, the finance team may use a particular accounting package that is not relevant for other users, or indeed you don't want them to have access to it. This approach also helps with keeping tabs on the licensing of those particular applications, as only those who are members of that AD group will be able to run the application.

A final level may be a group within that group. If we use our previous example of the finance team, within that finance team there may be an application that only finance management can have access to. In this example, there will be another active directory group specifically for finance management to which these users can be assigned the AppStack containing that application.

The following diagram illustrates the scenario we have just described:

As you can see, the Domain Users group covers all users and in the example they all get assigned the PDF Reader AppStack.

The Finance Group has been assigned an AppStack that contains Microsoft Excel, but also, as that group falls under the Domain Users group, they also have access to the PDF Reader.

Finally, the Finance Manager Group, being a subgroup of the Finance Group, and part of Domain Users, will have all three AppStacks assigned to them: PDF Reader, MS Excel, and Sage.

Note

One thing to be aware of when designing AppStack assignments in this way is to ensure that users are not assigned to more than three to five AppStacks. Having a large number of AppStacks could impact the performance for the users.

There are also some other important considerations when creating AppStacks for users with Microsoft Office applications. We will cover this in more detail in Chapter 6, Working with AppStacks, using our Example Lab, where we have created a number of Active Directory groups to represent various different departments, along with some example users.

AppStack deployment best practice

In this section, we are going to cover some of the best practices when it comes to deploying AppStacks in your environment.

How many AppStacks per VM can I have?

The current best practice is to limit each virtual desktop machine to having no more than 12 to 15 AppStacks attached at any one time. In theory, you could have up to 60 AppStacks attached at any one time, based on a virtual desktop machine being able to be configured with 4 virtual SCSI adapters, and each one being able to support 15 virtual SCSI disks; the rules of SCSI. After all, an AppStack is basically an attached disk or VMDK file. In reality, doing this will severely impact performance.

To limit the number of AppStacks in a production environment, it is a good practice to try to combine as many applications as possible into a single AppStack, and then use storage groups for AppStacks that are assigned to a large number of end users or desktops. This will help to distribute the aggregated Input/Output Operations Per Second (IOPS) across multiple datastores, while at the same time keep the assignments consistent and simpler to manage.

If you turn that around and now look at the number of connections to an AppStack, it is best practice to connect an AppStack to no more than 2,000 virtual desktop machines at any one time.

Application provisioning best practice

When it comes to the actual applications in an AppStack, there are a couple of points to note before we get to some of the best practices.

Firstly, any kernel mode drivers should be installed in the base image of the virtual desktop machine. You cannot have kernel mode drivers in an AppStack, as the applications in an AppStack run in user mode.

The second point to note is that any applications that need to run when an end user is logged out of their virtual desktop machine should also be installed in the base image.

When it comes to building your AppStacks on the provisioning virtual machine, then any AppStacks you create should be built on a clean and up-to-date base image that closely matches or is identical to the virtual desktop machines in your production environment.

By this, we mean that the provisioning virtual desktop machine and the virtual desktop machine in your production environment should all be running the same patches and service packs. This also applies to any applications. If you have any applications that are part of the base image, then they also need to be installed on the provisioning virtual desktop machine before creating any AppStacks.

The easiest way to manage the provisioning process is to create your provisioning virtual desktop machine as a dedicated VM using one of your production virtual desktop machines as the source. Once built exactly how you want it, including updates and applications, then take a snapshot to use as a reference point. It's now ready for you to create your AppStacks.

Note

Don't forget you will need to include the App Volumes Agent as part of the build of the virtual desktop machines used for provisioning AppStacks.

Once the provisioning process has been completed, the virtual desktop machine can then be rolled back to the initial snapshot ready to create the next AppStack. Before you start the "revert to previous snapshot" process, ensure that the virtual desktop machine has been powered off.

On the subject of the provisioning process itself, there are a few things to highlight as listed in the following:

• Do not use special characters when naming AppStacks and writable volumes. The following characters cannot be used:

  ~ ! @ $ ^ % ( ) { } [ ] | , ` ; # \ / : * ? < > ' " &

• Perform provisioning on a virtual desktop machine that has not had any AppStacks attached to it before; that is, always start from a clean machine.
• Ensure the provisioning virtual desktop machine is joined to the same domain as your production virtual desktop machines.

  Note

  Some applications and licensing models require that the virtual desktop machine should share a common SID with the production virtual machines.

• Ensure you install applications for all users so that applications install in program files and not in a user's profile.
• The provisioning system should not have the following installed or enabled:
  • Anti-virus agents
  • VMware Horizon View Agent
  • Any other filter driver applications, such as VMware Mirage

VMware Horizon View integration with pod and block design

A feature of App Volumes is the ability to integrate with VMware Horizon View by installing the Broker Integration Service onto your Horizon View Connection Servers. We will cover the Broker Integration Service in Chapter 9, Horizon View Integration.

As well as installing the App Volumes Broker Integration Service onto the Horizon View Connection Servers, the App Volumes Managers can be included in the Horizon View pod and block reference architecture. To find out more about the VMware Horizon View specifics and the pod and block architecture, refer to, Mastering VMware Horizon 6, Packt Publishing.

The following diagram illustrates the reference architecture for a Horizon View block to support 2,000 users. It comprises a block containing the infrastructure to support the virtual desktop machines, and a separate block to support the management components:

The App Volumes Managers would be part of the management block and therefore hosted on that part of the infrastructure.

However, the App Volumes Managers will be configured to point at the vCenter Servers in the desktop block, as these are managing the virtual desktop machines. AppStacks would be stored on the storage within the same block and mounted on the ESXi host servers in that block too.

In the previous example, we discussed an inpidual Horizon View desktop block. If we now scale this to a full pod configuration, consisting of 5 blocks of 2,000 users each to support 10,000 virtual desktop users, the architecture would look something like the following diagram:

In this example, we have deployed 5 App Volumes Managers just for illustrative purposes, but you could deploy a single App Volumes Manager: given that each instance can support up to 10,000 users. However, as we discussed previously, best practice states that a minimum of two App Volumes Managers should be deployed in a production environment.

Each App Volumes Manager will be configured with the details of each of the vCenter Servers in the desktop blocks, a feature of App Volumes that allows support for multi-vCenter Servers. In App Volumes terms, the vCenter Servers are referred to as Machine Managers.

When configuring App Volumes with the multi-vCenter Server feature, the following list details a few points to be aware of:

• vCenter Servers must use the same credentials
• The hostnames must be unique
• Datastore names must be unique
• Once deployed, it's not recommended to revert back to a single vCenter Server

In the next section, we are going to look at some of the considerations when planning your storage for an App Volumes deployment

Storage considerations

The most important element when it comes to sizing is about the storage components. As AppStacks are essentially VMDK files containing the applications, you need to ensure your storage platform has both the capacity and performance to deliver these applications to the end users.

When you create and deploy new AppStacks or Writable Volumes, templates are used as the copy source, and by default are created as 20 GB in size. These templates, which get created as part of the installation process, should be hosted on a centralized, shared storage platform that is highly available, backed up, and even more importantly, has the ability to recover the data in the event of a failure.

Note

Best practice would be to use a third-party data replication solution to ensure that App Volumes folders containing AppStacks and Writable Volumes are replicated across various locations.

The other key consideration is ensuring you have enough free storage space.

AppStack storage capacity considerations

It goes without saying that correctly sizing AppStacks and Writable Volumes is critical for a successful production deployment.

AppStacks should be configured so that they are of a big enough size to allow all the applications you want in that particular AppStack to be installed. You should also bear in mind that if the application is going to need to be updated during its lifecycle, you allow enough free space to accommodate these updates. Rule of thumb would say to leave about 20 percent of free space for future upgrades and updates.

Although AppStacks are created using standard templates, these templates can be resized if required.

Note

The default size of an AppStack template is 20 GB.

We will cover this in Chapter 14, Advanced Configuration and Other Options, and the Customizing AppStack templates section in that chapter.

Writable Volumes storage capacity considerations

In the same way as we discussed with AppStacks, Writable Volumes should also be sized correctly to ensure they can accommodate all the applications that a user could install into it. This should be a key piece of information you need to find from the assessment phase of any project that involves working with applications.

At first, this may seem like you require a large amount of storage capacity; however, all AppStacks and Writable Volumes use vSphere VMFS thin provisioning so that not all the storage space is utilized from day one, it's just allocated. This is where you will need to consider deploying tools that can monitor the free space in your environment.

When it comes to managing the free space for Writable Volumes, there are a couple of policy options to make you aware of that could complicate the management of that free space. These are about the Writable Volumes Delay Creation Option.

With this policy, you have the option to:

• Create Writable Volumes on next login: This means that any storage processes and capacity impacts occur based on user login behavior.
• Restrict Writable Volume Access: this allows you to restrict access to a certain virtual desktop machine or group of virtual desktop machines. This again means that login behavior dictates when a Writable Volume template is copied or initially created.

In a large-scale App Volumes deployment, it is not good practice to allow user behavior to dictate storage operations and capacity allocation. Writable Volumes should therefore be assigned to the end users at the same time as they are created, rather than waiting for the user to log in first and then create the Writable Volume. This allows you to manage and control the storage more effectively.

Scalability

An inpidual instance of an App Volumes Manager server has been tested with up to 10,000 active users connected to AppStacks. We have already talked about best practices where we limit each virtual desktop machine to having no more than 12 to 15 AppStacks attached to an inpidual virtual desktop machine and also to connect no more than 2,000 virtual desktop machines to an AppStack at any one time.

When it comes to scaling your deployment, in theory there isn't an upper limit to the number of App Volumes Managers you can deploy, or at least not one that has been tested today. In reality, even a deployment of 100,000 users would need only 10 App Volumes Managers.

Scaling your deployment is very straightforward. It's just a case of installing the App Volumes Manager software component onto a Windows server, and then connecting it to your existing App Volumes SQL database. When deploying additional App Volumes Manager servers, it is important not to overwrite the existing database.

Don't forget that when deploying multiple App Volumes Manager servers, that you will need to deploy a load balancer in front of the App Volumes Manager servers.

Availability

When it comes to making your App Volumes deployment highly available, it's more about the infrastructure that supports App Volumes that needs to be configured to be highly available.

The first and most obvious one is to configure some of the vSphere components to ensure that the App Volumes Manager servers are available. For example, you could enable VMware vSphere HA (short for High Availability) or even VMware FT (short for Fault Tolerance), although FT is probably a little overkill for App Volumes. As we have discussed previously, in a production environment you would have deployed multiple App Volumes Manager servers.

As part of the supporting infrastructure, you will have also deployed a SQL database or be using an existing SQL database. SQL is a critical component of App Volumes, as it keeps track of user assignments of AppStacks and Writable Volumes. If you lose the database, you will lose all of this information and effectively have to recreate all the assignments from scratch. With this in mind, and for production environments, you should deploy an enterprise-class level of SQL, using SQL clustering, for example.

You can of course use SQL Server Express as we are for the Example Lab in this book, and which is included with the App Volumes installation software; however, that should not be used in a production environment. When looking at your SQL deployment for App Volumes, ensure that the SQL Server is running on its own dedicated virtual machine, and that you place the datastore on storage that can satisfy the read/write IOPS that will be required.

Performance

There are a couple of components within App Volumes that you can configure to enhance the performance. The first of these is to enable the mounting of AppStacks and Writable Volumes to the vSphere host servers.

By enabling this feature, the App Volumes Manager will connect directly to the ESXi host server to issue a volume mount command. This could help increase the performance of mounting the AppStacks and Writable Volumes, as commands are not queued in the vCenter Server. It also provides a level of resiliency should the vCenter Server be down.

By default, if you do not enable this feature then the volume mount command will be issued indirectly to the vCenter Server via the vCenter SDK.

We have also talked previously about the number of App Volumes Manager servers that you should deploy based on 10,000 users per server, with a minimum of 2 servers for a production environment.

As a guideline for sizing your environment and to give you an idea of how many additional App Volumes Manager servers you may need in your environment, the rule of thumb is that each App Volumes Manager server supports a user login every second. So having 10 App Volume Manager servers would support 10 users every second.

When it comes to storage performance for your AppStacks, there are a couple of points to note. Firstly, you should ensure that your AppStacks, Writable Volumes, and virtual desktop machines are not stored on the same datastore. Keep them separate unless you are hosting your datastores on VMware Virtual SAN storage nodes.

You can find a reference architecture for Virtual SAN, Horizon View, and App Volumes by following this link: http://tinyurl.com/qa4vnsf.

The second point is more about the performance of the applications in the AppStack. It's best practice to install any application dependencies, such as Java or .NET, into the same AppStack in which the application is located.