Virtual desktop infrastructure (VDI) products like VMware Horizon enable IT departments to run desktop applications and virtual machines in the data center or cloud, and deliver these desktop and remote applications to employees as managed services.
For administrators, this means simplified and automated desktop and application security management. Administrators can quickly create virtual desktops based on a required location and user profile, and securely manage desktops as services from a single control plane. VMware Horizon supports local, hybrid (local but managed in the cloud) and multi-cloud deployment strategies.
End users can access custom virtual desktops or remote RDSH applications from company laptops, home PCs, Mac computers, thin clients, or mobile devices. Horizon provides a consistent user experience (UX) for virtualization services, across devices, locations and networks.
VMware Horizon stores data securely and in compliance with many regulations and industry standards, and enables migration of virtual desktop workloads to cloud platforms including Microsoft Azure, IBM Cloud, Google Cloud Platform, and VMware Cloud on AWS.
In this article, you will learn:
- Horizon Hybrid and Multi-Cloud Architecture
- Components of VMware Horizon
- Architecture Design for VMware Horizon VDI
- Memory Requirements
- CPU Req u ire m ents
- Disk Size
VMware Horizon Hybrid and Multi-Cloud Architecture
Organizations looking for a quick hybrid architecture set up can start with VMware Horizon, vSphere, Microsoft RDSH, and virtual desktop servers running on-premise, using a cloud-based control plane.
Typically, organizations leverage a VMware Horizon hybrid and multi-cloud architecture strategy for urgent matters. For example, when provisioning remote offices, maintaining business continuity, achieving disaster recovery, and ensuring high availability.
This enables enterprises to deploy and extend Horizon desktop and application pods to one or more public or private clouds, while keeping some Horizon horizon pods running locally. Therefore, the business can migrate any part of the deployment from local to cloud and back, as needed. Cloud options include any public cloud that supports VMware vSphere infrastructure, or the dedicated Horizon Cloud Service on Microsoft Azure or IBM Cloud.
The following figure shows the logical architecture of a Horizon deployment.
Components of VMware Horizon
VMware Horizon is composed of infrastructure components, VDI components, and user management components.
The central management system of VMware vSphere. vCenter can be deployed on physical or virtual machines.
You can deploy vCenter as a vCenter Server Appliance using pre-configured OVA templates. Do not use existing vCenter servers in a VMware Horizon environment-VMware recommends using new vCenter servers for licensing purposes, because you get a vCenter license included in the price of a Horizon license.
This is the server that runs the VMs for your virtualized desktop workloads. It is managed by vCenter Server.
Horizon View Connection Server
This is the central management server that accepts connections from virtualized desktop users, authenticating them via Active Directory. It stores a copy of the organization’s LDAP database.
A component that must be installed on each vCenter Server. Manages vCenter Server virtual desktop storage, improving storage efficiency through linked cloning. It creates a clone of a user’s storage from the base virtual hard disk (VMDK), comparing the user’s data to the parent disk and storing only the user’s unique data locally. This technique can save 50–90% of disk space, however it means that virtual desktops are dependent on their parent disks.
A web-based interface for managing Horizon VDI. VMware recommends using a separate Horizon Administrator instance for each Horizon Connection Server. Using this interface, administrators can add vCenter Servers and View Composers to the View configuration.
A component that must be part of all VMs the Horizon View Connection Server needs to manage. There should be an agent deployed on each machine that is served to users as a virtual desktop. It provides features important for virtualized desktops, including support for USB and peripherals, printing, and monitoring connectivity.
Allows the user’s virtualized desktop to interact with the View Connection Server, and authenticate via the Active Directory server on the Connection Server. It can be installed on Windows, MacOS or Linux.
User Management Infrastructure
Workspace ONE UEM
VMware Workspace ONE is a platform that lets you deliver applications to any device, with integrated access control, central application management and endpoint management. It is based on VMware unified endpoint management (UEM) technology, and integrates with VMware Horizon, sharing the same identity system.
There are two components VMware uses to deliver applications to users:
- App Volumes — a real-time application delivery system that dynamically delivers and manages applications to user devices.
- ThinApp — provides agentless application virtualization. Users can access remote applications without having to install software on their personal devices.
Architecture Design for VMware Horizon VDI
The design of a typical Horizon deployment is based on pods. A pod can have varying hardware configurations, and may have different versions of Horizon and vSphere.
There are several key design considerations for VMware Horizon, including whether virtual desktops should be persistent or not, and how to allocate enough memory, CPU and disk space to support virtualized workloads.
There are two primary options for virtual desktops in VMware Horizon — persistent and non-persistent.
If virtual desktops are non-persistent, after disconnecting or restarting, VMware Horizon does not keep any user data, such as user settings, application settings, or bookmarks. All desktops are identical, copied from the same master image. You can use folder redirection to maintain user-specific data — the user’s settings are stored in a central location and applied to all desktops that the user logs into.
Non-persistent desktops do not allow users to install applications and retain them in the next login. However, ThinApp can be used to provide access to applications from a virtualized desktop, without installing it locally and without requiring persistence.
Non-persistent desktops provide several benefits:
- Reduction of approx. 80% in storage requirements
- Easier maintenance of updates, because only one master image needs to be updated
- Improved security, because any desktop have a lifespan of up to one day before it is refreshed from a master image
- User settings data is also backed up centrally, further conserving storage
This option enables users to store data on their desktops, and regain access to the data each time they connect or reboot. You do not need methods like folder redirection to copy user data to another desktop. In addition, users can directly install or manage individual applications on their desktops, even if those applications do not exist for other users, and without using app virtualization.
A persistent desktop model means each user has a unique virtualized desktop. The desktop is built from the main image, but over time, becomes a unique version maintained by the user.
Persistent desktops provide an improved user experience for users, but this comes at significant expense for the VDI operator:
- Dramatically increases storage usage compared to non-persistent desktops — user-specific settings and applications may take up to 25–35 GB per desktop
- Desktop updates need to be managed, typically using a solution like Altiris or WSUS
- Security is less robust because desktops can remain persistent for months, and users may install software or make configuration changes that introduce vulnerabilities
- User settings are not backed up centrally, so may be lost in case of loss of the virtualized desktop
RAM accounts for most of the cost of server hardware, so it is important to determine the correct storage allocation when planning a virtual desktop deployment. Too little RAM increases the use of Windows paging, which hurts end user performance. Conversely, if too much RAM is allocated, the guest operating system page file, swap file and suspend files may become too large and affect storage capacity.
When calculating CPU requirements, collect information about the average CPU utilization of different types of employees in the company. During your POC, use performance monitoring like Perfmon or the ESXi utility esxtop to determine the average and maximum CPU utilization of each group.
Take into account that there can be performance spikes on a VM, for example when agents perform the same action together, such as a scheduled software update or virus scan. Identify how many agents one virtual machine can support without causing performance issues.
Ensure that each VM has just enough storage space for operations systems, user content and applications. This is typically smaller than the size of a disk included on an employee’s workstation. Make a special effort to reduce the size of the operating system, because this will result in a large storage saving across your data center.
A few considerations when estimating storage size:
- ESXi uses a suspend file with the same size as the RAM allocated to the VM
- Windows page file is, by default, 150% of RAM
- Log files require approx. 100MB per VM
Democratizing your Desktop Environment with Hysolate
Hysolate is an innovator in the isolated workspace-as-a-service space. An isolated workspace bridges the gap between enterprise endpoint security and user productivity. Hysolate is the first solution that lets organizations easily create an isolated workspace on both corporate and non-corporate devices, and manage them from the cloud.
Hysolate enables you to deploy local virtual environments on any workstation and manage them from the cloud. Isolated workspaces solve two problems:
- Protecting corporate devices by completely isolating a user desktop and the applications and files used by employees.
- Providing secure corporate access from unmanaged user-owned devices, using a strong, VM-based, isolated workspace.