Horizon 8.0 Part 3: Design Considerations

Whether it is Horizon, XenDesktop, or a cloud-based Desktop-as-a-Service provider, the implementation of a virtual desktop and/or published applications environment requires a significant time investment during the design phase.  If care isn’t taken, the wrong design could be put into production, and the costs of fixing it could easily outweigh the benefits of implementing the solution.

So before we move into installing the actual components for a Horizon environment, we’ll spend the next two posts on design considerations.  This post, Part 3, will discuss design considerations for the Horizon virtual desktops, and Part 4 will discuss design considerations for Active Directory.

Before I begin, designing an infrastructure to support a virtual desktop environment is a complex process. I couldn’t do it justice in one blog post. This post will provide an overview of the topic and help you understand all of the considerations that go into designing an environment. If you want to learn more about the art and science of designing VDI environments, I highly recommend The VDI Design Guide by Johan van Amersfoort.

Virtual Desktop Design

Virtual desktop environments are all about the end user and what they need.  So before you go shopping for storage arrays and servers, you need to start looking at your desktops.

Typically, when people think about desktop design, the first thing they think about is what provisioning engine they want to use. This is not the place to start. However, since this is one of the things that people want to know more about, I’ll start by discussing the provisioning methods in Horizon.

There are four methods for provisioning desktops in Horizon 2006:

  • Full Clone Desktops – Each desktop is a full virtual machine deployed from a template and managed as an independent virtual machine.
  • Instant Clone Desktops – Instant Clone desktops are new to Horizon 7, and they are built off of the VMfork technology introduced with vSphere 6.0.  Instant Clones are essentially a rapid clone of a running virtual machine with extremely fast customization.
  • Remote Desktop Session Host Pools – Horizon 6 expanded RDSH support to include PCoIP support and application remoting.  When RDSH desktops and/or application remoting are used, multiple users are logged into servers that host user sessions.  This feature requires Windows Server 2008 R2 or Server 2012 R2 with the RDSH features enabled.
  • Manually Provisioned Desktops – Manually provisioned desktops are desktop or published app resources that are provisioned outside of Horizon. These can be virtual machines that are managed by vCenter, or unmanaged physical or virtual machines.

I didn’t mention Linked Clones here. While Linked Clones are still available in Horizon 8, they have been officially deprecated, and Composer is slated to be removed in a future release. Instant Clones are the replacement for Linked Clones, and they are available in all Horizon 8 SKUs. If you currently use Linked Clones, you will want to transition to Instant Clones, and if you are starting a new project, you should not consider Linked Clones if you are using Horizon 8.

Desktops are more than just how they are provisioned. There are also options for how the desktops get assigned to users.

There are two desktop assignment types for desktop pools:

  • Dedicated Assignment – users are assigned to a particular desktop during their first login, and they will be logged into this desktop on all subsequent logins.
  • Floating Assignment – users are temporarily assigned to a desktop on each login.  On logout, the desktop will be available for other users to log into.  A user may not get the same desktop on each login.

As I mentioned above, there is a lot more to desktop design than the provisioning and assignment method. It also involves the VM specifications, applications, peripherals, and other attributes of the desktop environment. In fact, these attributes may determine what provisioning methods are available to you.

Understanding Use Cases

When you design a virtual desktop environment, you have to design around the use cases.  Use cases are the users, applications, peripherals, and how they are used to complete a task, and they are used to define many of the requirements in the environment.  The requirements of the applications in the type of desktops that are used and how they are assigned to users.

Unless you have some overriding constraints or requirements imposed upon your virtual desktop project, the desktop design choices that you make will influence and/or drive your subsequent purchases.   For instance, if you’re building virtual desktops to support CAD users, blade servers aren’t an option because high-end graphics cards will be needed, and if you want/need full clone desktops, you won’t invest in a storage array that doesn’t offer deduplication.

Other factors that may impact the use cases or the desktop design decisions include existing management tools, security policies, and other policies.

The Importance of Desktop Assessments

So how do you define your use cases? What information do you need, and how do you collect it?

The knowledge of who the users are collectively, the applications and peripherals they use, and how often they use them may exist in the organization, but there is a good chance that this information is tribal knowledge, outdated, and may be missing key details.

This is where desktop assessments come in. A desktop assessment is a process that gathers information about the environment to assist in defining use cases and sizing requirements for an environment.

The assessment starts by deploying an application in the environment. This typically consists of a server or virtual appliance that processes data and an agent that is deployed on endpoints. The tool runs for at least 30 days to gather information from a full business cycle.

When the assessment is complete, you will have detailed information about the application and resource usage, which will help determine the virtual desktop sizing and, later in the project, the physical infrastructure requirements.

Putting Together a High Level Design

Once you have determined your use cases, completed a desktop assessment and understand the impacts that these have on the desktop design, you’ll be able to put together a design document with the following items:

  • Use Case definition, which includes the applications, peripherals, and other aspects of the user environment.

The use case definitions will then determine other aspects of the environment, including:

  • Desktop definition based on the assessment data
  • Number of parent images that need to be managed
  • Number and type of desktop pools
  • Number of desktops per pool
  • Number of Connection Servers and Unified Access Gateways that are required

If you’re following the methodology that VMware uses in their design exams, your desktop design document should provide you with your conceptual and logical designs.

The conceptual and logical designs, built on details from the use cases, will influence the infrastructure design.  This phase would cover the physical hardware to run the virtual desktop environment, the network layer, storage fabric, and other infrastructure services such as antivirus.

The desktop design document will have a heavy influence on the decisions that are made when selecting components to implement Horizon 7.  The components that are selected need to support and enable the type of desktop environment that you want to run.

Before moving onto the next section, I want to reiterate the importance of doing a desktop assessment. The assessment will provide you with the information you need to properly design the environment, and it will avoid costly mistakes.

In part four, we will cover Active Directory design for Horizon environments.