Horizon and Workspace ONE Architecture for 250k Users Part 1

Disclaimer: This article is based on my own thoughts and experience and may not reflect a real-world design for a Horizon/Workspace ONE architecture of this size. The blog series focuses only on the Horizon or Workspace ONE infrastructure part and does not consider other criteria like CPU/RAM usage, IOPS, amount of applications, use cases and so on. Please contact your partner or VMware’s Professional Services Organization (PSO) for a consulting engagement.

To my knowledge there is no Horizon implementation of this size at the moment of writing. This topic, the architecture and the necessary amount of VMs in the data center, was always important to me since I moved from Citrix Consulting to a VMware pre-sales role. I always asked myself how VMware Horizon scales when there are more than only 10’000 users.

250’000 users are the current maximum for VMware Horizon 7.8 and the goal is to figure out how many Horizon infrastructure servers like Connection Servers, App Volumes Managers (AVM), vCenter servers and Unified Access Gateway (UAG) appliances are needed and how many pods should be configured and federated with the Cloud Pod Architecture (CPA) feature.

I will create my own architecture, meaning that I use the sizing and recommendation guides and design a Horizon 7 environment based on my current knowledge, experience and assumption.

After that I’ll feed the Digital Workspace Designer tool with the necessary information and let this tool create an architecture, which I then compare with my design.

Scenario

This is the scenario I defined and will use for the sizing:  

Users: 250’000
Data Centers: 1 (to keep it simple)
Internal Users: 248’000
Remote Users: 2’000
Concurrency Internal Users: 80% (198’400 users)
Concurrency Remote Users: 50% (1’000 users)

Horizon Sizing Limits & Recommendations

This article is based on the current release of VMware Horizon 7 with the following sizing limits and recommendations:

Horizon version: 7.8
Max. number of active sessions in a Cloud Pod Architecture pod federation: 250’000
Active connections per pod: 10’000 VMs max for VDI (8’000 tested for instant clones)
Max. number of Connection Servers per pod: 7
Active sessions per Connection Server: 2’000
Max. number of VMs per vCenter: 10’000
Max. connections per UAG: 2’000 

The Digital Workspace Designer lists the following Horizon Maximums:

 

Horizon Maximums Digital Workspace Designer

Please read my short article if you are not familiar with the Horizon Block and Pod Architecture.

Note: The App Volumes sizing limits and recommendations have been updated recently and don’t follow this rule of thumb anymore that an App Volumes Manager only can handle 1’000 sessions. The new recommendations are based on “concurrent logins per second” login rate:

New App Volumes Limits Recommendations

 

Architecture Comparison VDI

Please find below my decisions and the one made by the Digital Workspace Designer (DWD) tool:

Horizon ItemMy DecisionDWD ToolNotes
Number of Users (concurrent)199'400199'400
Number of Pods required2020
Number of Desktop Blocks (one per vCenter)100100
Number of Management Blocks (one per pod)2020
Connection Servers required100100
App Volumes Manager Servers802024+1 AVMs for every 2,500 users
vRealize Operations for Horizonn/a22I have no experience with vROps sizing
Unified Access Gateway required22
vCenter servers (to manage clusters)20100Since Horizon 7.7 there is support for spanning vCenters across multiple pods (bound to the limits of vCenter)

Architecture Comparison RDSH

Please find below my decisions* and the one made by the Digital Workspace Designer (DWD) tool:

Horizon ItemMy DecisionDWD ToolNotes
Number of Users (concurrent)199'400199'400
Number of Pods required2020
Number of Desktop Blocks (one per vCenter)20401 block per pod since we are limited by 10k sessions per pod, but only have 333 RDSH per pod
Number of Management Blocks (one per pod)2020
Connection Servers required100100
App Volumes Manager Servers142024+1 AVMs for every 2,500 users/logins (in this case RDSH VMs (6'647 RDSH totally))
vRealize Operations for Horizonn/a22I have no experience with vROps sizing
Unified Access Gateway required22
vCenter servers (to manage resource clusters)440Since Horizon 7.7 there is support for spanning vCenters across multiple pods (bound to the limits of vCenter)

*Max. 30 users per RDSH

Conclusion

VDI

You can see in the table for VDI that I have different numbers for “App Volumes Manager Servers” and “vCenter servers (to manage clusters)”. For the amount of AVM servers I have used the new recommendations which you already saw above. Before Horizon 7.7 the block and pod architecture consisted of one vCenter server per block:

Horizon Pod vCenter tradtitional

That’s why, I assume, the DWD recommends 100 vCenter servers for the resource cluster. In my case I would only use 20 vCenter servers (yes, it increases the failure domain), because Horizon 7.7 and above allows to span one vCenter across multiple pods while respecting the limit of 10’000 VMs per vCenter. So, my assumption is here, even the image below is not showing it, that it should be possible and supported to use one vCenter server per pod:

Horizon Pod Single vCenter

RDSH

If you consult the reference architecture and the recommendation for VMware Horizon you could think that one important information is missing:

The details for a correct sizing and the required architecture for RDSH!

We know that each Horizon pod could handle 10’000 sessions which are 10’000 VDI desktops (VMs) if you use VDI. But for RDSH we need less VMs – in this case only 6’647.

So, the number of pods is not changing because of the limitation “sessions per pod”. But there is no official limitation when it comes to resource blocks per pod and having one connection server for every 2’000 VMs or sessions for VDI, to minimize the impact of a resource block failure. This is not needed here I think. Otherwise you would bloat up the needed Horizon infrastructure servers and this increases operational and maintenance efforts, which obviously also increases the costs.

But, where are the 40 resource blocks of the DWD tool coming from? Is it because the recommendation is to have at least two blocks per pod to minimize the impact of a resource block failure? If yes, then it would make sense, because in my calculation you would have 9’971 RDSH users sessions per pod/block and with the DWD calculation only 4’986 (half) per resource block.

*Update 28/07/2019*
I have been informed by Graeme Gordon from technical marketing that the 40 resources blocks and vCenters are coming from here:

App Volumes vCenters per Pod

I didn’t see that because I expect that we can go higher if it’s a RDSH-only implementation.

App Volumes and RDSH

The biggest difference when we compare the needed architecture for VDI and RDSH is the number of recommended App Volumes Manager servers. Because “concurrent logins at a one per second login rate” for the AVM sizing was not clear to me I asked our technical marketing for clarification and received the following answer:

With RDSH we assign AppStacks to the computer objects rather than to the user. This means the AppStack attachment and filter drive virtualization process happends when the VM is booted. There is still a bit of activity when a user authenticates to the RDS host (assignment validation), but it’s considerably less than the attachment process for a typical VDI user assignment.

Because of this difference, the 1/second/AVM doesn’t really apply for RDSH only implementations.

With this background I’m doing the math with 6’647 logins and neglect the assignment validation activity and this brings me to a number of 4 AVMs only to serve the 6’647 RDS hosts.

Disclaimer

Please be reminded again that these are only calculations to get an idea how many servers/VMs of each Horizon component are needed for a 250k user (~200k CCU) installation. I didn’t consider any disaster recovery requirements and this means that the calculation I have made recommend the least amount of servers required for a VDI- or RDSH-based Horizon implementation.

Horizon on VMC on AWS Basics

VMC on AWS

In Switzerland where we have a lot of smaller to medium sized companies the demand for a  cloud solution is increasing. The customers are not yet ready to put all their servers and data into to the cloud, so they go for a hybrid cloud strategy.

And now it makes even more sense and got easier since VMware’s offering VMware Cloud on AWS (VMC on AWS) exists. This service, powered by VMware Cloud Foundation (VCF), brings VMware’s SDDC stack to the AWS cloud and runs the compute, storage and network products (vSphere, vSAN, NSX) on dedicated bare-metal AWS hardware. 

VMC on AWS

If you would like to try this offering you have the option for a Single Host SDDC which is the time-bound starter configuration and comes with the limitation of 30 days. After 30 days your Single Host SDDC will be deleted and all data will be lost as well. If you plan to scale up into a 3-host SDDC you retain all your data and you SDDC is not time bound anymore.

Availability

This pretty new service is already available in 13 global regions and already had 200+ released features since its launch. VMC on AWS is available almost everywhere – in US and Asia Pacific for example – and in Europe we find the service hosted in Frankfurt, London, Paris and Ireland. 

Use Cases

It’s not hard to guess what the use cases are for a service like this. If you are building up a new IT infrastructure, don’t want to have your own data center and purchase any server, then you might want to consider VMC on AWS. Another project could be to expand your market into a new geography and extend your footprint into the cloud based on a VMware-consistent and enterprise-grade environment in the AWS cloud.

A few customers are also finding a new way to easily deliver business continuity with VMware Site Recovery and take advantage of VMC on AWS which delivers a robust Disaster Recovery as a Service (DRaaS) possibility.

Another reason could be that your on-premises data center is in danger because of bad weather and you want to migrate all your workloads to another region.

Or you just want to quickly build a dev/test environment or do a PoC of a specific solution or application (e.g. VMware Horizon).

Elastic DRS

In my opinion EDRS is one of best reasons to go for VMC on AWS. EDRS allows you to get the capacity you need in minutes to meet temporary or unplanned demand. You have the possibility to scale-out and scale-in depending on the generated recommendation.

A scale-out recommendation is generated when any of CPU, memory, or storage utilization remains consistently above thresholds. For example, if storage utilization goes above 75% but memory and CPU utilization remain below their respective thresholds, a scale-out recommendation is generated.

 

 A scale-in recommendation is generated when CPU, memory, and storage utilization all remain consistently below thresholds.

This is interesting if your dekstop pool is creating more instant clones and the defined value of RAM for example is above the threshold. But there is also a safety check included in the algorithm, which runs every 5 minutes, to provide time to the cluster to cool off with changes. 

If you check the EDRS settings you have the option for the “Best Performance” or “Lowest Cost” policy. More information can be found here.

Horizon on VMC on AWS

For customers who are already familiar with a Horizon 7 on-premises deployment, Horizon on VMC on AWS lets you leverage the same architecture and the familiar tools. The only difference now is the vSphere outsourcing.

Use Cases

Horizon can be deployed on VMware Cloud on AWS for different scenarios. You could have the same reasons like before – data center expansion or to have a disaster recovery site in the cloud. But the most reason why a customer goes for Horizon on VMC on AWS is flexibility combined with application locality.

Horizon 7 on VMC on AWS

We have customers who were operating an on-premises infrastructure for years and suddenly they are open to a cloud infrastructure. Because the SDDC stack in the cloud is the same like in the private cloud the migration can be done very easily. You can even use the same management tools like before.

Minimum SDDC Size

The minimum number of hosts required per SDDC on VMware Cloud on AWS for production use is 3 nodes (hosts). For testing purpose, a 1-node SDDC is also available. However, since a single node does not support HA, it’s not recommended for production use.

Cloud Pod Architecture for Hybrid Cloud

If you are familiar with the pod and block architecture you can start to create your architecture design. This hasn’t changed for the offering on VMC on AWS but there is a slight difference:

  • Each pod consists of a single SDDC
  • Each SDDC only has a single vCenter server
  • A Horizon pod consists of a single block Horizon7Pod on VMC on AWS

Each SDDC only has one compute gateway which limits the connections to ~2’000 VMs or user sessions. This means that the actual limit per pod on VMC on AWS is ~2’000 sessions as well. When the number of compute gateways per SDDC can be increased, Horizon 7 on VMC on AWS will definitely have a comparable scalability with the on-premises installation.

You can deploy a hybrid cloud environment when you use the Cloud Pod Architecture to interconnect your on-premises and Horizon pods on VMC on AWS. You can also stretch CPA across pods in two or more VMware Cloud on AWS data centers with the same flexibility to entitle your users to one or multiple pods as desired.

Supported Features

The deployment of Horizon 7 on VMC on AWS started with Horizon 7.5 but there was no feature parity at this time. With the release of Horizon 7.7 and App Volumes 2.15 we finally had the requested feature parity. This means since Horizon 7.7 we can use Instant Clones, App Volumes and UEM. At the time of writing the vGPU feature is not available yet but VMware is working with Amazon on it. With the release of Horizon 7.8 a pool with VMware Cloud on AWS is now capable of using multiple network segments, allowing you to use less pools and/or smaller scopes. Please consult this KB for the currently supported features. 

Use AWS Native Services

When you set up the Horizon 7 environment in VMware Cloud on AWS you have to install and configure the following components:

  • Active Directory
  • DNS 
  • Horizon Connection Servers
  • DHCP
  • etc.

If you are deploying Horizon 7 in a hybrid cloud environment by linking the on-premises pod with the
VMC on AWS pod, you must prepare the on-premises Microsoft Active Directory (AD) to access
the AD on VMware Cloud on AWS.

My recommendation: Use the AWS native services if possible 🙂

AWS Directory Services

AWS Managed Microsoft AD is built on actual Microsoft Active Directory and does not require you to synchronize or replicate data from your existing Active Directory to the cloud. You can use standard Active Directory administration tools and take advantage of built-in Active Directory features, such as Group Policy and single sign-on (SSO).

Amazon Relational Database Service

Amazon RDS is available on several database instance types – optimized for memory, performance or I/O – and provides you with six familiar database engines to choose from, including Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database, and SQL Server. You can use the AWS Database Migration Service to easily migrate or replicate your existing databases to Amazon RDS.

This service allows you to quickly setup a SQL Express (not recommended for production) or regular SQL Server which can be used for the Horizon Event DB or App Volumes. 

Amazon FSx for Windows File Server

Amazon FSx for Windows File Server provides a fully managed native Microsoft Windows file system so you can easily move your Windows-based applications that require file storage to AWS. Built on Windows Server, Amazon FSx provides shared file storage with the compatibility and features that your Windows-based applications rely on, including full support for the SMB protocol and Windows NTFS, Active Directory (AD) integration, and Distributed File System (DFS).

At the time of writing I have to mention that the FSx service has not yet officially been tested and qualified for User Environment Manager (UEM), but that’s no problem. Technically it’s working totally fine.

Amazon Route 53

The connectivity to data centers in the cloud can be a challenge. You need to manage the external namespace to give users access to their desktop in the cloud (or on-prem). For a multi-site architecture the solution is always Global Server Load Balancing (GSLB), but how is this done when you cannot install your physical appliance anymore (in your VMC on AWS SDDC)?

The answer is easy: Leverage Amazon Route 53!

Amazon Route 53 effectively connects user requests to infrastructure running in AWS – such as Amazon EC2 instances, Elastic Load Balancing load balancers, or Amazon S3 buckets – and can also be used to route users to infrastructure outside of AWS. You can use Amazon Route 53 to configure DNS health checks to route traffic to healthy endpoints or to independently monitor the health of your application and its endpoints. 

Check Andrew Morgans blog article if you need more information about Route 53.

Horizon on VMC on AWS rocks! 🙂

 

VCAP7-DTM Design Exam, Part 11

My last article was about the Horizon reference architecture and four weeks have already passed since then. My VCAP7-DTM Design exam is scheduled for October 18 – that’s in five days!

I haven’t opened my books the last three weeks, because I think it’s important to take a break and get some distance of your books and documents, which allows you to understand things better and faster and see connections between things you haven’t seen before. And another reason was my pregnant wife who delivered our beautiful daughter on October 4! 🙂

I started from scratch and repeated reading all my training material and PDF documents.

Infrastructure Assessment

To design a Horizon 7 environment you have to follow a process to work out a VMware EUC solution that meets the customer’s requirements and follow the VMware design guidelines and use the reference architectures while considering customer constraints. It is very important that all customer business drivers and objectives are clearly defined. Then you will start to gather and analyze the business and application requirements and document the design requirements, assumptions, risks and constraints. For example, if you talk about technical requirements with your customer, the following categories should be covered:

  • Virtualization infrastructure and data center hardware
  • Storage
  • Networking
  • Security
  • Application
  • Directory services and GPOs
  • Monitoring and performance
  • Management
  • Profile management
  • Peripherals
  • Printing
  • Backup and recovery (business continuity)
  • Endpoints
  • Users/Use cases: correlation between hardware, software and user requirements)
  • High availability
  • Licensing

With the information from the assessment phase, the design work can begin and you create the conceptual design before you head over to create a logical design. Advice: Minimize risks and keep things simple!

Horizon Logical Design

The logical design (high level design) follows the conceptual design and defines how to arrange components and features. It is also useful to understand and evaluate the infrastructure design. The easiest and most common way to create a logical design is the use of architecture layers. Each layer contains one or more components and has functional and technical inter-dependencies:

  • User Layer
    • Self-Service portal
    • Authentication
  • Application Layer
    • Application deployment and type (cloud-based, locally installed, enterprise apps etc.)
  • Desktop Layer
    • Use cases and type of user
    • Scalability and multi-site
    • Desktop types and OS
  • Virtualization Layer
    • Hypervisor
    • Compute, network and storage
    • Graphics
  • Hardware Layer
    • Server
    • Network and storage
  • Management Layer
    • Patching
    • Monitoring
    • Cluster and resources
    • Capacity
    • Backup
  • Security Layer
    • Internal and external
    • Authentication and authorization
    • Policies
    • Antivirus etc.

A Horizon logical design could look like this:

Horizon Logical Architecture

If you need to write down use cases and their attributes, here an example:

AttributeDefinition
Business UnitFinance
User ClassificationTask Worker
Time of use07:00-18:00, mo-fr
User deviceThin Client
PeripheralsNone
ConnectivityLAN
PersistencyNon-persistent desktop
Data centerBasel DC1
AuthenticationWindows Login

Horizon Block and Pod Design

In part 4 I covered this topic how to use a repeatable and scalable approach to design a large scale Horizon environment.

Horizon Component Design

To have a complete design you must define the amount and the configuration of Horizon components required for your environment. You have to include certain design recommendations and design the configuration for Horizon components for your use cases. These are some required infrastructure components:

  • VMware Identity Manager
    • Load Balancing for resiliency and scale
    • Database required
    • Connection to Active Directory
    • SaaS-based implementation recommended
    • Approx. 100’000 users per virtual appliance
  • vCenter Server
    • Up to 10’000 virtual machines per vCenter
      • Recommendation: 2’000 desktops per vCenter
    • Dedicated vCenter Server instance per resource block
    • Database required
  •  Connection Server
    • Up to 2’000 sessions per Connection Server (4’000 tested limit)
    • Database required
    • Install at least one Replica Server for redundancy
    • Max. 7 Connection Servers per pod
      • Load-balanced
    • Max. 10’000 sessions per pod recommended
    • Cloud Pod Architecture
      • Max. 175 Connection Servers
      • Max. 120’000 sessions
      • Max. 5 sites
    • View Composer needed?
      • Database required
  • Security Server (not recommended anymore, use UAG)
    • Should not be member of AD domain
    • Load Balancing
    • Should be hardened Windows server (placed in DMZ)
    • 1:1 mapping with Connection Servers
  • Unified Access Gateway (UAG)
    • Virtual appliance (placed in DMZ) based on linux (Photon OS)
    • Scale-out is independent of Connection Server
    • Does not need to be paired with a single Connection Server
    • Load Balancing

Pool and Desktop Configuration

  • Desktop Configuration
    • Specification (OS, apps, RAM, disk, network)
    • Operating System Builds (master images)
      • Image Optimization (use OSOT)
    • Application Deployment
  • Pool Configuration
    • Map use cases to pools
    • Pool Design
      • Type
      • User Assignment
      • User Experience Settings
      • Pool Size
      • Performance
      • AD Groups
    • Pool Types
      • Automated Desktop Pool
      • Manual Desktop Pool
      • RDS Desktop Pool
    • Desktop Persistence
      • Dedicated
      • Floating
    • Desktop Pool Definition
      • Full Clones
      • Linked Clones (Composer)
      • Instant Clones
    • Remote Display Protocol
      • Blast (H.264 capable, TCP/UDP)
      • PCoIP (UDP)
      • RDP (TCP)
    • 3D Rendering (Horizon 7.2)
      • Nvidia GRID vCPU (shared GPU hardware acceleration)
      • Hardware
      • Virtual Shared Graphics Acceleration (vSGA)
      • Virtual Dedicated Graphics Acceleration (vDGA)
      • Soft 3D (Software-accelerated graphics)
      • AMD Multiuser GPU using vDGA
      • Pool must use PCoIP or Blast
      • (Live vMotion of vGPU VMs is supported since Horizon 7.6)

VMware Infrastructure Design

You need to map the Horizon desktop building block and the Horizon management building block to vSphere and identify factors and design decisions to figure out the sizing of the VMware infrastructure.

  • ESXi Hosts
    • ESXi Host Specifications
    • CPU requirements
    • Memory requirements
    • Storage requirements (specially if using vSAN)
    • Host density (max. VMs/desktops per ESXi host)
    • vSphere cluster requirements (HA and DRS)
  • Storage
    • Storage performance and desktop I/O requirements
      • Types of disks (SSD, SAS, SATA)
      • Dedicated array for VDI
      • FC/Network connectivity
    • Shared Storage recommended
      • vSAN recommended for Horizon desktops
      • Datastore sizing
    • Storage requirements depending on pool configuration
      • E.g. Instant Clones use significantly less storage

Network and Security Design

The network design should be simple, scalable and secure. More secure does not always mean less “user simple” (user experience), but it does less risks and does not imply more complexity.

  • Network
    • UAG appliance load-balanced in DMZ
    • Connection Servers load-balanced inside corporate firewall
      • Security Server would be placed in DMZ if no UAG
    • Know the key firewall considerations for Horizon 7
    • Bandwidth requirements for different types of users
    • LAN considerations
    • WAN considerations (e.g. latency, WAN optimization)
    • Optimization/Policies for display protocols (LAN/WAN)
    • vSphere networking requirements
      • Separate networks for management, VMs, vMotion etc.
      • Physical redundancy
      • Use vSphere Distributed Switch
  • Security
    • Secure your desktops (lockdown, GPOs, UEM)
    • Use secure client connections (secure gateways/tunnel)
    • Use Unified Access Gateway for remote access (use three NICs)
      • View Security Server (if needed)
    • User authentication method from internal and external
      • Two Factor Authentication for external connections
    • Restrict access (tags, AD groups)
    • Use NSX for micro segmentation
    • Install signed SSL certificates

Session Management

Our objective of a Horizon implementation is to provide better support to users than the physical solution. Session management is an aspect of this. Configuration and different settings on the sessions or client device are essential for a smooth user experience.

  • Personalization
    • Profile Management (mandatory profiles recommended)
      • Use folder redirection
    • User User Environment Manager (UEM) for Windows and application settings
      • Personalization
      • Application Configuration Management
      • User Environment Settings
      • Application Migration
      • Dynamic Configuration
  • Just-in-Time Management (JMP) Platform
    • App Volumes (real-time application delivery)
    • Instant Clones (rapid desktop provisioning)
    • User Environment Management (contextual policy management)
  • End-User Desktop Maintenance
    • Maintaining linked-clone desktops with Composer
      • Recompose – Patch and update desktop
      • Refresh – Revert OS disk to the base image snapshot
      • Rebalance – Management of datastore capacity
    • Manage Instant Clones by pushing an image
  • User Authentication Method
    • Smartcard
    • Two Factor Authentication (RSA, RADIUS, SAML, vIDM)
    • True SSO (short-lived certificate for Windows login process)
      • Enrollment Server required
  • ADMX template files for secure remote desktops
  • Client Devices
    • Thin clients, zero clients, fat clients, tablet and smartphones
    • Different Horizon Clients
    • Printing

Delivering Applications

The last topic I quickly repeat is about delivering and managing applications. Horizon has different methods of application delivery and the method of application delivery depends on many factors.

  • Applications in general
    • New or existing applications
    • App Lifecycle
    • Dependencies and conflicts
    • Performance and stability
  • Application delivery methods
    • RDS-hosted apps
    • ThinApp package (containerized applications, isolated from OS)
    • Natively installed Windows apps (in master image)
    • Citrix published apps
    • SaaS
    • App Volumes (real-time application delivery with LCM)
  • ThinApp
    • Isolation modes
      • Merged mode (full write access)
      • WriteCopy mode (restricted write access)
      • Full mode (no read/write access)
    • Package format
      • EXE
      • DAT (when EXE is larger than 200MB)
      • MSI

These are the topics you should cover when you prepare for the VCAP7-DTM Design exam. In addition I also read the following documents:

This is my recommendation. Within the last 8 weeks I’ve effectively studied 5 weeks for the exam. I work approx. since 4 months with Horizon products in a pre-sales role, not as a consultant. I will update you after the exam if the experience combined with learning was enough to pass! 🙂

Did I forget anything? Let me know! Jump to part 12

VCAP7-DTM Design Exam, Part 7

This is the 7th part of my VCAP7-DTM Design exam series. In part 6 I covered the creation of a physical network design for Horizon 7. This time we take a look at section 6 of the blueprint, the creation of a physical design for Horizon desktop and pools:

Section 6 – Create a Physical Design for Horizon Desktops and Pools

Objective 6.1 – Design Virtual and Physical Image Masters
Objective 6.2 – Optimize Desktop Images, OS Services and Applications for a Horizon Design
Objective 6.3 – Incorporate Desktop Pools into a Horizon Design
Objective 6.4 – Incorporate RDS Pools into a Horizon Design

The desktops your customer provides must satisfy the use case requirements to ensure a good user experience and user acceptance. To provide desktops with Horizon you have to create so called desktop pools. VMware has a few recommendations and leading practices for the configuration and optimization of a Horizon desktop. These things will help you to enhance the overall scalability and performance of a Horizon implemenation.

Desktop configuration

The desktop build process would look like this:

hroizon desktop build process

  1. You will start with the creation of the target VM
  2. Installation of guest OS
  3. Installation of VMware Tools
  4. Perform image optimization
  5. Installation of globally used applications and Horizon Agent
  6. Creation of VM template

If you understand the customer’s use cases, you will understand what kind of desktops are needed to meet the requirements. The configuration of the desktop VM varies for each pool. The differences between them are often resource allocations like disk size,  installed applications, memory or even the operating system.

For the most use cases VMware recommends only assigning two vCPUs unless it’s proven  and really a requirement to have more CPU power.

Consider RAM reservation settings and keep in mind that high memory settings require more disk space as the VM swap file and the Windows pagefile sizes are related to these settings.

Globally used applications like MS Office or Adobe Reader should be installed within the desktop image. All other applications are delivered with App Volumes, if possible.

OS Optimization

VMware recommends optimizing the guest operating system of a desktop image to positively affect the performance of a Horizon desktop.

Use VMware OS Optimization Tool (OSOT) to optimize your Windows desktops and server images. It is a great tool and will help you to disable OS components  you don’t need and could help to enhance the overall scalability and performance. Make sure you know the optimizations you apply and what settings are changed to avoid any bad user experience or unexpected behaviour of your desktops.

If you are using Windows 10 for example, also make sure that you remove all unneeded native apps.

More details on creation of an optimized Windows image for a Horizon virtual desktop can be found on Tech Zone.

See also the blog article from Login VSI.

Pool Configuration

You can create desktop pools to give users remote access to virtual machine-based desktops. You can also choose VMware PC-over-IP (PCoIP), or VMware Blast to provide remote access to users.

There are two main types of virtual desktop pools.
Automated desktop pools use a vCenter Server virtual machine template or snapshot to create a pool of identical virtual machines.
Manual desktop pools are a collection of existing vCenter Server virtual machines, physical computers, or third-party virtual machines. In automated or manual pools, each machine is available for one user to access remotely at a time.

With Horizon 7.5 a instance is limited to 10’000 desktops and if the planned deployment exceeds this limit, then you must use the Cloud Pod Architecture (CPA) feature. With CPA you can link together 25 pods to provide one big desktop environment for ten geographically distant sites and provide apps and desktops for up to 200’000 sessions. See VMware Horizon 7 sizing limits and recommendations.

In a Horizon design you must state the use cases and use desktop pools which are the logical containers that represent each use case (desktop type, application set, access mode etc.).

With VMware Horizon it is also possible to provide hosted applications with the integration or Remote Desktop Services Hosts (RDSH) based on Microsoft Remote Desktop Services (RDS).
A RDS desktop pool is associated with a farm, which is nothing more than group of RDS hosts. Each RDS host is a Windows Server that can host multiple RDS desktop sessions.

Desktop Persistence

The Horizon 7.5 handbook is a really great source for this part and I will allow myself to copy and past some part of it. 🙂

There are two options for a desktop assignment:

Dedicated-assignment pools
Each user is assigned a particular remote desktop and returns to the same desktop at each login. Dedicated assignment pools require a one-to-one desktop-to-user relationship. For example, a pool of 100 desktops are needed for a group of 100 users.

Floating-assignment pools
Using floating-assignment pools also allows you to create a pool of
desktops that can be used by shifts of users. For example, a pool of 100 desktops could be used by 300 users if they worked in shifts of 100 users at a time. The remote desktop is optionally deleted and re-created after each use, offering a highly controlled environment.

This means that a floating assignment is recommended because it decouples the user from a specific desktop and provides management and resource efficiency. This obviously could also reduce the licensing costs.

Dedicated desktop assignments are useful or required where users have applications or data that they install and keep on a specific desktop. A dedicated desktop can be assigned (fixed) to a specific user or also during the first logon where the next unused desktop will be assigned automatically.

Full Clones, Linked Clones or Instant Clones?

One of the most important questions for your design is whether users need a stateful or stateless desktop to work with. If the user has a stateful desktop, you have to think about the data which needs to be included in a backup (e.g. user profile or application data).

If you provide stateless desktop images you face other challenges. What happens to a user’s profile or data? Should it be saved and be available in the next session?

Stateless desktop images
Also known as nonpersistent desktops, stateless architectures have many advantages, such as being easier to support and having lower storage costs. Other benefits include a limited need to back up the virtual machines and easier, less expensive disaster recovery and business continuity options.

Stateful desktop images
Also known as persistent desktops, these images might require traditional image management techniques. Stateful images can have low storage costs in conjunction with certain storage system technologies. Backup and recovery technologies such as VMware Site Recovery Manager are important when considering strategies for backup, disaster recovery, and business continuity.

There are two ways to create stateless (non-persistent) desktop images in Horizon 7:

  1. You can create floating assignment pools or dedicated assignment pools of instant clone virtual machines. Folder redirection and roaming profiles can optionally be used to store user data.
  2. You can use View Composer to create floating or dedicated assignment pools of linked clone virtual machines. Folder redirection and roaming profiles can optionally be used to store user data or configure persistent disks to persist user data.

There are several ways to create stateful (persistent) desktop images in Horizon 7:

  1. You can create full clones or full virtual machines. Some storage vendors have cost-effective storage solutions for full clones. These vendors often have their own best practices and provisioning utilities. Using one of these vendors might require that you create a manual dedicated-assignment pool.
  2. You can create pools of instant-clone or linked-clone virtual machines and use App Volumes user writable volumes to attach user data and user-installed apps.

Whether you use stateless or stateful desktops depends on the specific type of worker.

There could be a lot more to tell you about when creating desktop pools, but those details can be found on Tech Zone and the available PDFs and Youtube videos.

The next time we take a look at “Section 7 – Incorporate Application Services into a Horizon Physical Design”.