Horizon Apps Performance Reference Architecture

Executive Summary

VMware Horizon® Apps provides a single platform for delivering virtualized Windows applications and shared desktop sessions from Windows Server instances using Microsoft Remote Desktop Services (RDS). With Horizon Apps, you can publish business-critical Windows apps alongside SaaS and mobile apps in a single digital workspace, easily accessed with single sign-on from any authenticated device or OS.

This white paper provides a reference architecture for Horizon Apps Advanced Edition, which includes the RDSH features of VMware Horizon 7 Enterprise Edition. This reference architecture is based on addressing key business requirements such as making standard Windows applications available to employees, and targeting use cases such as task workers and knowledge workers.

We carried out extensive testing to evaluate the performance and capacity characteristics of VMware Horizon Apps in a JMP (Just-in-Time Management Platform) environment. This paper describes a simple, validated architecture and details of the test results, which are summarized in Figure 1.

Reference Architecture Highlights

Figure 1: Reference Architecture Highlights

This architecture uses key features of Horizon 7 Enterprise Edition and Horizon Apps Advanced Edition, such as Just-in-Time Delivery, which combines Instant Clone Technology, VMware App Volumes™, and VMware User Environment Manager™ to provide the accelerated delivery of OS, applications, and user configuration.

VMware vSphere® is the foundation platform for any Horizon 7 or Horizon Apps environment. This paper designs and builds out the requirements and best practices using VMware vSAN™ as a storage platform for RDSH servers. VMware vSAN comes with Horizon Apps Advanced Edition and provides an excellent scalable storage layer; however, other storage types can be used instead.

The testing results focused on the entire RDSH-provided virtual desktop lifecycle by capturing metrics during the boot-up, user login, and RDSH session acquisition (also called ramp-up), user workload execution (also referred to as steady state), and user logout for the RDSH sessions under test. Test metrics were gathered from the VMware ESXi™ host servers, RDSH and infrastructure VMs, and storage.

We used VMware vRealize® Operations for Horizon, VMware ESXTOP, and Windows Performance Monitor to record detailed performance statistics. We also used Login Virtual Session Indexer (Login VSI), the industry-standard benchmarking tool, to generate a reproducible, real-world test case that simulates the execution of various applications, including Microsoft Internet Explorer, Adobe Flash video, and Microsoft Office. Login VSI also recorded an impressive number of user-experience metrics that we used to determine the largest number of user sessions you can run in a particular environment with good user experience.

• User experience results from Login VSI tests:

– VSI baseline response time: 730 ms – Considered an excellent VSI index result, this baseline score reflects the response time of specific operations performed in the desktop workload when there is little or no stress on the system. A low baseline score indicates a better user experience, resulting from applications responding quickly in the environment.

VSIBASE SCORE PERFORMANCE RATING
0–799 ms Excellent
800–1399 ms Very Good
1400–1999 ms Good
2000–9999 ms Reasonable/Poor

VSI average index response time: 1015 ms – Considered an excellent VSI index result, this number represents the application-consistent response times that measured the user experience. The lower the numbers, the more responsive the apps and user experience remained throughout workload testing.

• vSphere host performance:

– Average CPU utilization at steady state: 65 percent – 65 percent CPU utilization at peak load means the servers can maintain the overall user load in the event that one of the four RDSH vSphere hosts becomes inoperable.

Average RAM used at steady state: 150 GB out of 384 GB available – Although each host server was configured with 384 GB of RAM, only 150 GB was needed to drive the load.

Peak network utilization per host server per adapter: 574 Mbps – With dual 10G NICs available on each host, less than 1 G per adapter was used during peak load with 700 active sessions running the Login VSI workload.

• vSAN datastore performance:

– Average read latency: 0.69 ms; maximum read latency: 3.14 ms – Sustained read/write latency reported under 5 ms is a good result for hyper-converged infrastructure (including vSAN) running end-user-computing (EUC) workloads.

– Average write latency: 2.6 ms; maximum write latency: 4.68 ms – Sustained read/write latency reported under 5 ms is a good result for hyper-converged infrastructure (including vSAN) running EUC workloads.

– Peak I/O operations per second (IOPS) at steady state: 1525 – This is a moderate level of IOPS given the 700 sessions we tested with.

– Peak throughput at steady state: 115 MBps – This is a reasonable level of storage throughput given the 700 sessions we tested with.

This reference architecture underwent validation of design and build, user workflow, and testing to ensure that all the objectives were met, the use case was delivered properly, and that real-world application is achievable.

Audience

This document is intended for IT architects and administrators who want to understand the performance and scale attributes of VMware Horizon Apps and the Just-in-Time Management Platform products in a virtualized RDSH environment. The reader should have a solid understanding of desktop and application virtualization, familiarity with VMware Horizon 7 and VMware vSphere products, in addition to an understanding of sizing and performance concepts.

Scope

For this guide, we created a Horizon Apps deployment according to VMware best practices, and we validated performance. The scope of this design is limited to the Business Process Application service, as described in the VMware Horizon 7 Enterprise Edition Reference Architecture. A service defines unique business requirements, combines them with a use case, and identifies the technology or feature combinations that best satisfy those unique requirements.

For the Business Process Application service:

• The unique requirements often include fast provisioning and simplified management of a small number of Windows applications, as well as the ability to use location-aware printing.

• The use case is normally that of a static task worker, but to amply prove the performance capabilities of Horizon RDSH, we decided to test the workload for a medium-level knowledge worker, who might have 5–9 Windows apps open at any given time.

• The technology includes the RDSH features of Horizon Apps Advanced Edition or Horizon 7 Enterprise Edition. These include Instant Clone Technology, App Volumes, and User Environment Manager.

Windows applications are delivered as RDSH-based remoted apps. The RDS hosts are instant clones to provide space and operational efficiency. Applications are delivered through App Volumes. User Environment Manager applies profile settings and folder redirection. Location-aware printing is delivered through the virtual printing (ThinPrint) feature and User Environment Manager settings.

VMware Reference Architectures

VMware reference architectures are built and validated by VMware and supporting partners. They are designed to address common use cases for end-user computing. A reference architecture describes the environment and workload used to simulate realistic usage, and draws conclusions based on that particular deployment.

This guide is intended to help customers—IT architects, consultants, and administrators—involved in the early phases of planning, design, and deployment of VMware Horizon Apps-based solutions. The purpose is to provide a standard, repeatable, and highly scalable design that can be easily adapted to specific environments and customer requirements.

The reference architecture “building block” approach uses common components to minimize support costs and deployment risks during the planning of large-scale Horizon Apps deployments. The building block approach is based on information and experiences from some of the largest VMware deployments in production today. While drawing on existing best practices and deployment guides pertinent to many of the individual specific components, the reference architectures are tested and validated in the field and described in detail.

Some key features that can help an organization get started quickly with a solution that integrates easily into existing IT processes and procedures include:

  • Standardized, validated, readily available components
  • Scalable designs that allow room for future growth
  • Validated and tested designs that reduce implementation and operational risks
  • Quick implementation and reduced costs

VMware Horizon Apps Overview

VMware Horizon desktop and application virtualization solutions are built on a unified architecture, making them simple to manage and flexible enough to meet the needs of all your organization’s users. You use the same architecture and management tools to manage public, private, and hybrid cloud deployments as you do for on-premises deployments.

VMware Horizon Apps published applications – These are applications provided by Microsoft Windows Remote Desktop Session Host (RDSH) VMs to any type of device, including Windows PCs, Macs, smartphones, and tablets. Some VMware editions include technologies that further optimize the experience of using Windows applications on a mobile device by automatically translating native mobile-device display, navigation, and controls to Windows applications; enhancing performance over mobile networks; and enabling developers to optimize any custom Windows application for any mobile environment.

VMware Horizon Apps shared session-based desktops – These are inexpensive, locked-down Windows virtual desktops provided by RDSH VMs. They are well suited for users such as call center employees, who perform a standard set of tasks.

VMware Horizon Apps Benefits

VMware Horizon 7, which includes the same RDSH features as Horizon Apps, is the leading platform for virtual desktops and applications.

A single digital workspace – Provide end users with easy access to virtual desktops and published applications—including RDS-hosted applications and Citrix XenApp virtualized applications—through a single digital workspace.

Just-in-time delivery of applications and desktops – Rapidly deploy full-featured, personalized digital workspaces leveraging JMP technologies, which include Instant Clone Technology, App Volumes, and User Environment Manager. Easily monitor performance, set up alerts, and remediate issues to improve the user experience.

Blast Extreme display protocol – Deliver an immersive, feature-rich user experience for end users, across devices, locations, media, and network connections. Blast Extreme, our newest user-interface remoting technology, brings secure, workstation-class performance from the cloud to remote and mobile workers.

Smart Policies with streamlined access – Simplify authentication across all desktop and app services with True SSO and contextual, granular, role-based policies that connect user, device, and location information. Deliver multilayered protection of the virtual infrastructure with simplified networking, automated intelligence, and threat protection that goes from data center to device.

Built for the Software-Defined Data Center – Horizon 7 and Horizon Apps are tightly integrated with the VMware Software-Defined Data Center, which includes vSphere, vSAN, and VMware NSX®. This integration provides a seamless turnkey solution, eliminating the need to build, test, and support disparate virtualization, storage, and networking products.

RDSH Features

The published applications feature supports a wealth of remote-experience features. These include everything from the HTML Access web client to client-drive redirection, access to locally connected USB devices, file-type association, Windows media redirection, content redirection, printer redirection, location-based printing, 3D rendering, smart card authentication, and more. The published applications feature can leverage the PCoIP and Blast Extreme display protocols from VMware, providing a rich user experience using zero, thin, laptop, PC, or mobile clients over LAN, WAN, or bandwidth-limited connections.

Remote-Experience Features Available with Published Applications

Figure 2: Remote-Experience Features Available with Published Applications

With published applications, you install applications on servers with the Microsoft Remote Desktop Session Host (RDSH) role, and entitle applications to corporate users through the Horizon Administrator console. Once authenticated, users can launch an application, save files, and use network resources from a remote RDSH server—just as if the users had the application installed on their local computer, tablet, or phone.

Publishing applications using the published applications feature simplifies management of line-of business applications, allows the delivery of Windows applications to non-Windows devices, and can potentially provide licensing advantages. This strategy can reduce CapEx and OpEx costs, simplifying installation, upgrades, and troubleshooting.

With a VMware implementation, end users launch VMware Horizon Client™, or the HTML Access web client, and log in to the server that brokers connections to published apps. Users then see a catalog of published apps, as well as session-based or single-user virtual desktops, if desktops have been configured.

VMware Just-in-Time Management Platform

Horizon 7 introduced a new concept in managing virtual desktops and published applications and desktops—the Just-in-Time Management Platform.

VMware Horizon 7 with VMware JMP technologies provides IT with a new streamlined approach to deliver, protect, and manage Windows, Linux, SaaS, web, and mobile desktops and applications while ensuring that end users can work anytime, anywhere, on any device.

JMP (pronounced jump), which stands for Just-in-Time Management Platform, represents capabilities in VMware Horizon 7 Enterprise Edition (and Horizon Apps Advanced Edition) that deliver Just-in-Time Desktops and Apps in a flexible, fast, and personalized manner. JMP is composed of the following VMware technologies:

VMware Instant Clone Technology for fast desktop and Remote Desktop Session Host RDSH provisioning

VMware App Volumes for real-time application delivery

VMware User Environment Manager for contextual real-time policy and user profile management

JMP allows components of a desktop or RDSH server to be decoupled and managed independently in a centralized manner, yet reconstituted on demand to deliver a personalized user workspace when needed. JMP is supported with both on-premises and cloud-based Horizon 7 deployments, providing a unified and consistent management platform regardless of your deployment topology. The JMP approach provides several key benefits, including simplified desktop and RDSH image management, faster delivery and maintenance of applications, and elimination of the need to manage “full persistent” desktops

Components of Horizon 7 and Horizon Apps

Figure 3 and corresponding descriptions show the relationships between the major components of a Horizon Apps Advanced Edition or Horizon 7 Enterprise Edition deployment.

Components of a JMP Deployment Using Horizon 7.1 Enterprise Edition

Figure 3: Components of a JMP Deployment Using Horizon 7.1 Enterprise Edition

Note: Horizon Apps Advanced Edition includes these same components except for single-user virtual desktops. Horizon Apps includes RDSH-based published applications and shared session-based virtual desktops.

1. Horizon Client – Client software is available from app stores or from VMware for iOS, Android, Chrome, Windows, Linux, and macOS so that users can access published applications and VDI desktops from any device. An HTML Access web client is also available, and it does not require installing any software on client devices.

2. Connection Server – Horizon Client is configured to access the Connection Server. This server, which integrates with Windows Active Directory, provides access to virtual desktops and published applications. This server also includes the instant-clone engine, which provides single-image management with automation capabilities.

3. VMware Instant Clone Technology – Use this key Horizon 7.1 feature to create instant-clone desktop pools and automated farms of instant-clone Microsoft RDSH servers.

4. RDSH VMs and Desktop VMs – To provide published applications, you attach App Volumes AppStacks to one or more Microsoft RDSH servers. You can also use RDSH servers to provide shared session-based virtual desktops. In contrast, with single-user virtual desktops, each user gets an individual desktop VM.

5. Agents – You install the Horizon Agent, the App Volumes Agent, and the User Environment Manager FlexEngine service on the master images for Microsoft RDSH servers and single-user virtual desktops.

  • Horizon Agent communicates with Horizon Client to provide features such as connection monitoring, virtual printing, folder sharing (client-drive redirection), and access to locally connected USB devices.
  • App Volumes Agent runs as a service and uses a filter driver to handle application calls and filesystem redirects to AppStack disks (VMDKs).
  • FlexEngine, the User Environment Manager agent, starts at login and imports policy settings, including application and user environment settings, from a configuration share.

This agent also loads personalization settings from a user profile archives share. You use the provided Group Policy Object (GPO) administrative templates (.admx files) to enable and configure FlexEngine.

6. RDSH farms – One or more RDSH servers make up a farm, and from that farm you create application and shared session-based desktop pools. Each individual farm can contain up to 200 RDSH servers.

7. Application pools – Each application that you select to publish becomes an application pool. For example, using the Add Application Pool wizard, if you select the Paint and Calculator apps to publish, when you complete the wizard, you will have a Paint application pool and a Calculator application pool.

8. Desktop pools – You can create an instant-clone pool from a Windows 7 or Windows 10 master image, or you can create a desktop pool based on an automated instant-clone farm of RDSH servers.

9. App Volumes Manager – You use this administrative console for configuring VMware App Volumes to attach applications (AppStacks) to virtual desktops and to RDSH servers, simplifying application distribution and update.

10. User Environment Manager – Use the VMware User Environment Manager Management Console to configure user-specific Windows desktop and application settings that are applied in the context of client device, location, or other conditions. Policies are enforced when users log in, launch an app, reconnect, or when some other triggering event occurs. You can also configure folder redirection for storing personal user data, including documents, pictures, and so on.

11. Unified Access Gateway – A VMware Unified Access Gateway™ virtual appliance (formerly known as Access Point) functions as a secure gateway for users to access resources such as remote desktops and applications from outside the corporate firewall. Unified Access Gateway appliances typically reside within a network demilitarized zone (DMZ).

12. Workspace ONE – VMware Workspace™ ONE™ leverages VMware Identity Manager™, which provides application provisioning, a self-service catalog, conditional access controls, and single sign-on for SaaS, web, cloud, and native mobile applications. When Workspace ONE is integrated with Horizon 7, users access the app catalog through either the Workspace ONE app or the Workspace ONE browser-based catalog. With one click in the Workspace ONE catalog, the selected published app or virtual desktop is launched in Horizon Client.

13. Display Protocol – Blast Extreme is the newest VMware user-interface remoting technology, which can use natively supported encoding formats H.264 (for longer device battery life) or JPG/PNG, and can use either UDP or TCP transport. Blast Extreme is supported on all Horizon Client OS types and on more than 70 thin and zero clients. Alternatively, the PCoIP and RDP display protocols are also supported.

VMware vSphere

The two core components of VMware vSphere are ESXi and VMware vCenter Server®.

• ESXi is a bare-metal hypervisor that installs directly on top of a physical server. ESXi is the virtualization platform on which you can create and run virtual machines (VMs) and virtual appliances.

• VMware vCenter Server is a service that acts as a central administrator for ESXi hosts connected in a network. (ESXi hosts are often called vSphere hosts in this paper.) VMware vCenter Server lets you pool and manage the resources of multiple hosts. VMware vCenter Server also provides the central point for configuring, provisioning, and managing VMs in the data center.

VMware vSphere can use an external storage system, such as a Fibre Channel or iSCSI SAN (storage area network) or an NFS (Network File System) NAS (network-attached storage). With the VMware vSAN feature available with vSphere, the storage system can alternatively be aggregated local server-attached storage.

VMware vSAN Storage

VMware vSAN (formerly VMware Virtual SAN), is a core building block for the Software-Defined Data Center. Embedded in the VMware vSphere hypervisor, VMware vSAN delivers flash-optimized, highperformance storage for hyper-converged infrastructure (HCI).

VMware vSAN is a software-defined storage tier that virtualizes the local physical solid-state drive (SSD) disks and hard disk drives (HDDs) available on ESXi hosts into a single datastore shared by all hosts in a cluster. You specify only one datastore when creating an automated desktop pool or server farm, and the various components, such as VM files, replicas, user data, and operating system files, are placed on the appropriate SSD disks or direct-attached HDDs.

VMware vSAN supports a number of configuration options, from two-node clusters for small implementations at remote offices to clusters as large as 64 nodes, delivering over 6 million IOPS. Stretched clusters can also be configured to provide resiliency against site failure and workload migration with no downtime for disaster avoidance.

VMware vSAN implements a policy-based approach to storage management. Horizon 7-specific vSAN policy profiles define VM storage requirements, such as capacity, performance, and availability. Each VM maintains its policy regardless of its physical location in the cluster. If the policy becomes noncompliant because of a host, disk, or network failure, or workload changes, vSAN reconfigures the data of the affected VMs and load-balances to meet the policies of each VM.

Horizon Apps Component Design

Extensive planning went into every element of the design of the vSphere, Horizon 7, vSAN, and JMP environment that was used during this project. VMware best practices were referenced and followed at all times. Wherever possible, the configuration used for performance tests conformed to recommendations for production environments, as described in the VMware Horizon 7 Enterprise Edition Reference Architecture.

One key concept in a Horizon 7 or Horizon Apps environment design is the use of pods and blocks, which gives us a repeatable and scalable approach.

• A pod is made up of a group of interconnected Connection Servers that broker published apps. Multiple pods can be interconnected using Cloud Pod Architecture (CPA).

• A pod is divided into multiple blocks to provide scalability. Each block has its own VMware vCenter Server and one or more resource vSphere clusters. To add more capacity, we simply add more resource blocks. We also add an additional Connection Server for each additional block.

VMware vSphere Design

VMware vSphere was deployed in a standard configuration. Two virtual data centers were deployed, one for infrastructure and management systems, and one dedicated to desktops and applications. A total of six physical hosts were deployed—two hosts for infrastructure and management systems and four hosts for RDSH servers. Hardware configurations are detailed in Appendix C: Bill of Materials. Shared storage was connected using iSCSI attached volumes, and vSAN was used for the RDSH VMs. Each vSphere host was configured with two 10 GbE network adapters.

Host and Datastore Layout

Figure 4: Host and Datastore Layout

Three vSphere clusters were deployed, each sized and configured to house VMs based on their role:

• Infrastructure and management cluster

• RDSH cluster

• Login VSI (Virtual Session Indexer) Launcher Client cluster

vCenter and Cluster Layout

Figure 5: vCenter and Cluster Layout

The vSphere environment was segregated, with VMs being deployed in the appropriate virtual data center, vSphere host, and datastore according to their role.

VMware vSphere hosts and vCenter Servers were deployed in a best-practice configuration. VMware vCenter Servers were deployed using the Linux-based appliance and were sized according to vSphere 6.5 sizing best practices, as described in the VMware vSphere Installation and Setup Guide.

VMware vSphere clusters were configured with VMware vSphere High Availability (HA) and VMware vSphere Distributed Resource Scheduler™ (DRS) enabled. DRS policy was set to the default, moderate configuration. VMware vSphere clusters were set to place the VM swap file on a datastore that was deployed specifically to house vSwap files. At the time of testing, vSphere hosts were patched with all available VMware updates.

The basic vSphere configuration, including version and build information, is listed in Appendix C: Bill of Materials.

Horizon Apps Design

The test case consisted of Horizon 7 RDSH provisioned by Instant Clone Technology, User Environment Manager with mandatory profiles, and App Volumes with two AppStacks.

RDSH Server Farm

Two dedicated vCenter Servers supported an infrastructure cluster and RDSH cluster. High availability was incorporated into the environment across all host servers and software components with N + 1 server fault tolerance.

• Infrastructure cluster

• RDSH workload cluster to support 700 concurrent sessions

• N + 1 server HA per cluster

Environment Layout

Figure 6: Environment Layout

Note: In this diagram vCenter PSC means vCenter Platform Services Controller, a functional component introduced in vSphere 6.0 that includes services such as licensing, SSO, certificate services, and component registrations.

The following illustration outlines the VM distribution across the RDSH and infrastructure hosts. In this diagram, VCSA means vCenter Server appliance, and VROPS V4H means vRealize Operations for Horizon.

VM and Workload Distribution

Figure 7: VM and Workload Distribution

The architecture is composed of 32 RDSH VMs with four workload vSphere hosts and two infrastructure vSphere hosts. Note that the design can sustain the 700-session load and user experience with only 24 RDSH VMs, three workload vSphere hosts, and one vSphere infrastructure host. Two Connection Servers were implemented for this architecture for high-availability purposes.

Our test scenarios were all run with a 32-RDSH-VM automated instant-clone farm. Using the Login VSI knowledge worker workload with a Windows 2012 R2 image, 8 vCPU, and 32 GB of RAM, we loaded as many active user sessions as we could on a host until the host CPUs reached an average of 65 percent usage on the RDSH servers. Some 700 simulated users logged in and performed simulated work with Login VSI.

For details about the VM specifications and configuration settings, see Appendix A: Configuration and Settings and Appendix B: Virtual Machine Specifications.

App Volumes

The VMware App Volumes just-in-time application model provides a simple solution to managing and deploying applications. App Volumes separates IT-managed applications and application suites into administrator-defined application containers. These shared read-only virtual disks (VMDK files) are called AppStacks. As part of an AppStack, applications can be deployed “once” to a single central file and accessed by hundreds of RDSH VMs. This simplifies application maintenance, deployment, and upgrades.

App Volumes Manager orchestrates application delivery by managing assignments of application volumes (AppStacks) to target RDSH servers. Two App Volumes Managers were used, which is the recommended minimum for high availability in a production environment. The App Volumes Manager servers were sized according to published best practices and in accordance with all requirements and prerequisites.

App Volumes Deployment Configuration

Figure 8: App Volumes Deployment Configuration

A Microsoft SQL database was housed on a Windows Server 2012 R2 VM with SQL 2014 Server. Standard Active Directory integration was configured, with only domain administrators granted permission to log into the App Volumes Manager server.

For details about the App Volumes settings used, see Appendix A: Configuration and Settings.

A total of two AppStacks were built and maintained during this project:

• An AppStack for Microsoft Office apps, including Microsoft Word, PowerPoint, Excel, and Outlook

• An AppStack for other common apps, including Adobe Reader, Java, Flash, and Doro PDF Print

All of the (Login VSI) applications that were part of the App Volumes tests were delivered by AppStack, with the exception of Internet Explorer, which was installed natively.

AppStacks Used for Testing

Figure 9: AppStacks Used for Testing

The following screenshot taken from App Volumes Manager shows the two AppStacks that were tested as part of the architecture.

App Volumes Manager Screenshot of the Tested AppStacks

Figure 10: App Volumes Manager Screenshot of the Tested AppStacks

User Environment Manager

VMware User Environment Manager provides profile management by capturing user settings for the operating system and applications. Unlike traditional application profile management solutions, User Environment Manager does not manage the entire profile. Instead it captures settings that the administrator has specified. This reduces login and logout time, because less data needs to be loaded.

When a user logs in to a virtual desktop or published app, user environment and personalization settings are imported based on conditions such as the user’s location, type of device, and user group. Network and printer mappings, application blocking rules, shortcuts, and many more settings are configured according to the current policy.

You can also use User Environment Manager to configure folder redirection so that personal user data, documents, pictures, and so on are redirected from specific folders inside the VM. This combination of folder redirection and fine-grained policy control enhances the ability to manage user profiles and minimizes the number of files that must be copied to the VM when the user logs in.

In this test environment, User Environment Manager was used to create and enforce user profiles. Components of User Environment Manager were installed as follows:

• GPO templates were installed in Active Directory, so that settings could be configured by using the User Environment Manager Management Console.

• The User Environment Manager Management Console was installed on the file server VM.

• Also on the file server VM, a file share was created for user data, and a file share was created to store environment and application configuration settings.

• A mandatory profile was locally placed in the RDSH image before cloning the RDSH VMs.

• The User Environment Manager agent (called FlexEngine) was installed in the RDSH image before cloning the RDSH VMs.

Testing Details

We took a methodical approach to all test operations. Tests were performed in an environment with a dedicated workload. No core infrastructure server (Active Directory or SQL, for example) was being used by any other applications.

After deploying all components in a best-practice configuration and then conducting functional validation testing, we followed a simple test methodology. All testing was conducted onsite within VMware labs.

Methodology

The testing results focused on the entire process of the virtual desktop lifecycle by capturing metrics during the boot-up, user login and RDSH session acquisition (also called ramp-up), user workload execution (also referred to as steady-state), and user logout for the RDSH sessions under test.

Test metrics were gathered from the ESXi host servers, RDSH and infrastructure VMs, storage, and load generation software to assess the overall success of an individual test cycle. No test cycle was considered passing unless all of the planned test user accounts completed the ramp-up and steady-state phases and unless all metrics were within the permissible thresholds as noted in Success Criteria

During a test run, we logged in a new user every ~4 seconds until we reached 100 percent concurrent session load, and then we let the workload run for 15 minutes to measure steady-state operations. During the test run, we used VMware vRealize Operations for Horizon, VMware ESXTOP, and Windows Performance Monitor to record detailed performance statistics. Login VSI also recorded an impressive number of user-experience metrics that are used to produce a score called VSImax. This score represents the largest number of user sessions you can run in a particular environment with good user experience.

Two successfully completed test cycles were conducted for each configuration scenario and results were found to be relatively consistent from one test to the next. The RDSH virtual servers were refreshed after each test run.

The following protocol was used for each test cycle in this study to ensure consistent results.

Pre-Test Process

Before the test run is started, the following conditions are verified:

1. All RDSH machines are shut down using the Horizon Administrator console.

2. All Login VSI Launcher VMs are available for testing.

3. Login VSI Launcher VMs are restarted in groups until the required number of launchers is running with the Login VSI Agent at a “waiting for test to start” state.

Test Run Protocol

To ensure consistency between performance lead studies, VMware requires the login duration, known as ramp-up, to complete within 48 minutes using Login VSI in benchmark mode. All RDSH machines are to be started and available within two minutes after the last VM has been started by vCenter Server.

In addition, Login VSI benchmark mode was used for all published test results. This ensures that the tests represent a fixed set of parameters for interpreting the results. The following steps outline the testing process:

  1. Timecode 0:00: Start performance logging on the following systems:
  • Infrastructure and RDSH host blades
  • A single RDSH VM and all infrastructure VMs used in the test run (AD Servers, Connection Servers, App Volumes Managers, and so on) In addition, the starting time for monitoring vRealize Operations Manager is logged.
  1. Timecode 0:03: Boot RDSH machines using the Horizon Administrator console.
  2. Timecode 0:04: First set of machines boot.
  3. Timecode 0:05: All RDSH machines report as available in the Horizon Administrator console.

Note: A rest time of 15 minutes is required after the last RDSH machine reports as available in the Horizon Administrator console and before the next step commences.

  1. Timecode 0:20: Start the Login VSI 4.1.25.6 test using the knowledge worker workload in benchmark mode, with the auto-logout time set to 900 seconds, with RDSH VMs using a sufficient number of launchers (at 20 sessions per launcher).

Note: The knowledge worker workload includes using the following applications: Microsoft Word, Microsoft Outlook, Internet Explorer, Adobe Reader, Microsoft PowerPoint, Microsoft Excel, FreeMind / Java, and Photo Viewer.

  1. Timecode 1:08: All RDSH sessions report as launched (48-minute benchmark launch rate) in the Login VSI Management Console.
  2. Timecode 1:10: All launched sessions must report as active within the Login VSI Management Console.

Note: All sessions launched must become active for a valid test run within this window of time.

  1. Timecode 1:20: The Login VSI test ends (based on an auto-logout with a 900-second period designation).
  2. Timecode 1:35: All active sessions are logged out.

Note: All sessions launched and active must be logged out for a valid test run. The Horizon Administrator console must show that all RDSH VMs have maintained an available state as evidence of this condition being met.

  1. Timecode 1:38: All performance logging is terminated; the test is complete.

Post-Test Process

After testing,

  1. All performance logs are copied to a storage repository.
  2. The RDSH farm is disabled in the Horizon Administrator console and the RDSH VMs are shut down.
  3. All RDSH ESXi hosts are rebooted. The environment is now ready for the next test sequence.

Success Criteria

The purpose of this testing was to provide data metrics that validate the performance of Horizon 7 RDSH machines in their specific design implementations. These validation results are an example of what is possible under the specific environment conditions outlined here, and do not represent the full characterization of VMware products.

To determine the upper limits of this reference architecture for best performance, the following procedures were used:

  • Tests were run at a session count level that effectively utilized the cluster and host capacity as measured by CPU utilization, memory utilization, storage utilization, and network utilization.
  • Login VSI version 4.1.25.6 was used to launch the knowledge worker workload in benchmark mode.
  • The number of launched sessions was required to equal the number of active sessions within 2 minutes of the last session launched in a test as observed on the Login VSI Management Console.

The Horizon Administrator console was monitored throughout testing to verify that all RDSH machines remained in the Available state during testing, and all running sessions reported a status of In Use and were load balanced evenly during the steady-state test phase.

Within 20 minutes of the end of each test, all sessions on all launchers had to log out automatically, and the Login VSI workload had to be complete.

Problematic workload sessions reported by Login VSI as Stuck that were greater than 1 percent of the total number of sessions tested constituted a failure condition.

Two consecutive test runs had to return results within plus-or-minus 1 percent variability to pass the success criteria.

Key Metrics

Hundreds of performance and capacity metrics were collected during testing. Some metrics are of key importance in evaluating performance, capacity, and scalability.

METRIC TYPE SOURCE METRIC LISTING
User-experience metrics • Login VSI • Login times
• Application launch times
• VSImax scores
Host performance and capacity metrics • vRealize Operations Manager
• ESXTOP
• CPU consumed
• vRAM consumed
• Storage usage (reads/writes)
• Network transmit/receive
RDSH VM performance and capacity metrics • vRealize Operations Manager • Windows PerfMon • CPU consumed
• vRAM consumed
• Storage usage (reads/writes)
• Network transmit/receive
Infrastructure VM performance and capacity metrics (domain controllers, Connection Servers, App Volumes Manager, SQL Server, file server) • vRealize Operations Manager
• Windows PerfMon
• CPU consumed
• vRAM consumed
• Storage usage (reads/writes)
• Network transmit/receive
vCenter performance and capacity metrics (infrastructure and RDSH instances) • vRealize Operations Manager • CPU consumed
• vRAM consumed
• Storage usage (reads/writes)
• Network transmit/receive
RDSH storage performance and capacity metrics (vSAN datastore) • vRealize Operations Manager • Read latency
• Write latency
• Read throughput
• Write throughput
• Read I/O per second
• Write I/O per second
• Capacity consumed
App Volumes storage performance and capacity metrics (AppStacks datastore) • vRealize Operations Manager • Read latency
• Write latency
• Read throughput
• Write throughput
• Read I/O per second
• Write I/O per second

Table 1: Test Metric Types and Listings

Test Tools

We used a standard set of tools to orchestrate the workload, monitor the environment, and collect performance metrics.

ESXTOP

The VMware esxtop tool provides a real-time view of ESXi hosts sorted by CPU usage. The esxtop utility displays information about the state of the physical server running an ESXi. It lists statistics for CPU utilization for each physical processor, memory utilization, and disk and network bandwidth for each network and disk device available to the ESXi host.

We used esxtop to collect and analyze performance data of the ESXi hosts and storage datastores during testing. Here is an example of the command-line syntax used for this study:

esxtop -a -b -d 10 -n 1000 > /vmfs/volumes/VSI-Logs/Test123.csv

Windows Logman

Windows Logman manages and schedules performance counter and event trace log collections on local and remote systems. This tool is used to analyze how applications are affecting computer performance.

We used Logman to collect and analyze performance data of the Windows VMs, including the infrastructure and RDSH systems.

Login VSI

Login Virtual Session Indexer (Login VSI) is the industry-standard benchmarking tool for measuring the performance and scalability of centralized desktop environments such as VDI and RDSH.

Active Directory users are systematically logged in to client endpoints, called launchers, which are standard PCs running the latest Horizon Client. During a test, domain users launch virtual desktop sessions from launchers to the target desktop or application pool that is under test. In this project, we used the Blast Extreme display protocol for the desktop sessions.

Login VSI Logical Diagram

Figure 11: Login VSI Logical Diagram

We used Login VSI to generate a reproducible, real-world test case that simulated the execution of various applications, including Microsoft Word, Microsoft Outlook, Internet Explorer, Adobe Reader, Microsoft PowerPoint, Microsoft Excel, FreeMind / Java, and Photo Viewer. This benchmark workload was then run against various configurations of the test environment. Hardware and software remained the same, but we ran different user, desktop, and application configurations.

Various workload profiles can be run during a Login VSI test. The medium-level knowledge worker workload was selected for this test because it is the closest analog to the average desktop user that we see in our customer deployments. For more information on Login VSI workloads, refer to Introduction to Login VSI Workloads and Login VSI Workload Breakdown.

Login VSI was configured to run a knowledge worker workload against a Horizon 7 farm of 32 RDSH machines, with the tests set up to log users in to shared, session-based RDSH virtual desktops incrementally every ~4 seconds.

Once logged in, each session remained active for the duration of the test, and for at least 15 minutes after the final user logged in, thereby ensuring full concurrency for the desired number of sessions. Not reaching VSImax was an indication of satisfactory user response at the predetermined user count. (VSImax represents the largest number of user sessions you can run in a particular environment with good user experience.)

Login VSI recorded and measured the total response time of all the applications from each session and calculated the VSI average index by taking the average response times and dropping the highest and lowest 2 percent. Increased latencies in response times indicated when the system configuration was saturated and had reached maximum user capacity. Refer to VSImax Overview for details on how Login VSI is measured and calculated.

Login VSI Workloads

Figure 12: Login VSI Workloads

VSIbase is a baseline score that reflects the response time of specific operations performed in the desktop workload when there is little or no stress on the system. A low baseline indicates a better user experience, resulting from applications responding quickly in the environment.

VSIBASE SCORE (MS) PERFORMANCE RATING
0–799 ms Excellent
800–1399 ms Very Good
1400–1999 ms Good
2000–9999 ms Reasonable/Poor

During testing, Login VSI sessions were initiated by launchers (simulated user operations) that ran on a separate compute and storage infrastructure using the knowledge worker workload in benchmark mode. A total of 40 launchers were used, each running a maximum of 18 sessions. Each launcher (client endpoint) was configured with 4 vCPUs and 4 GB of vRAM, following Login VSI sizing guidelines. VMware Blast Extreme (JPG/PNG) was used as the display protocol during all tests.

Test Results

We exercised every test configuration with full-session concurrency, to ensure that all elements of the environment could handle the simultaneous user load of 700 active users with two Horizon Connection Servers, two App Volumes Manager servers, and a dedicated vCenter server for the RDSH block. Throughout testing, we had no problem sustaining the 700-session load, each with two AppStacks attached, and with the user profiles managed by User Environment Manager along with a mandatory profile locally placed in the RDSH image.

The following summary outlines the key data points for the testing.

  • User experience results from Login VSI tests:
    • VSI baseline response time: 730 ms – Considered an excellent VSI index result, this baseline score reflects the response time of specific operations performed in the desktop workload when there is little or no stress on the system. A low baseline score indicates a better user experience, resulting from applications responding quickly in the environment.
      VSIBASE SCORE PERFORMANCE RATING
      0–799 ms Excellent
      800–1399 ms Very Good
      1400–1999 ms Good
      2000–9999 ms Reasonable/Poor
    • VSI average index response time: 1015 ms – Considered an excellent VSI index result, this number represents the application-consistent response times that measured the user experience. The lower the numbers, the more responsive the apps and user experience remained throughout workload testing.
  • vSphere host performance:
    • Average CPU utilization at steady state: 65 percent – 65 percent CPU utilization at peak load means the servers can maintain the overall user load in the event that one of the four RDSH vSphere hosts becomes inoperable.
    • Average RAM used at steady state: 150 GB out of 384 GB available – Although each host server was configured with 384 GB of RAM, only 150 GB was needed to drive the load.
    • Peak network utilization per host server per adapter: 574 Mbps – With dual 10G NICs available on each host, less than 1G per adapter was used during peak load with 700 active sessions running the Login VSI workload.
  • vSAN datastore performance:
    • Average read latency: 0.69 ms; maximum read latency: 3.14 ms – Sustained read/write latency reported under 5 ms is a good result for hyper-converged infrastructure (including vSAN) running end-user-computing (EUC) workloads.
    • Average write latency: 2.6 ms; maximum write latency: 4.68 ms – Sustained read/write latency reported under 5 ms is a good result for hyper-converged infrastructure (including vSAN) running EUC workloads.
    • Peak I/O operations per second (IOPS) at steady state: 1525 – This is a moderate level of IOPS given the 700 sessions we tested with.
    • Peak throughput at steady state: 115 MBps – This is a reasonable level of storage throughput given the 700 sessions we tested with.

User-Experience Performance Results

User login times are a key measure of desktop performance. Users who have to wait for long periods of time for their desktops and apps to be ready are generally not satisfied with the user experience. During each test scenario, we measured the time for each of the 700 simulated users to log in to their RDSH desktop session.

During testing we observed only a slight increase in login time with App Volumes. As a general rule for VDI with App Volumes, the additional time it takes to mount AppStacks volumes on the back end means longer login times for users on the front end, and the more AppStacks assigned to users, the longer the login times. This is a key consideration for making decisions about the number of applications in a single AppStack, or AppStack density.

With RDSH however, the paradigm is changed. With RDSH, AppStacks are mounted at the machine level rather than to user accounts. AppStacks are attached at boot time as opposed to login, which helps to minimize the impact on user experience during login.

Note: Login VSI reports the login time from the point at which the session is established until the VSI workload has started the test, which adds additional time to the reported statistic (LogonTimer) once the desktop has been presented.

Average User Login Times as Reported by Login VSI

Figure 13: Average User Login Times as Reported by Login VSI

The following bar chart compares the login times, as reported by Login VSI, for various Horizon 7 product configurations including:

• Baseline test with a manual farm using roaming profiles

• Test with a manual farm along with User Environment Manager and mandatory profiles

• Test with automated farm using Instant Clone Technology and User Environment Manager (UEM)

• Full JPM test with App Volumes, Instant Clone Technology, and User Environment Manager (This is the setup recommended by this guide.)

Only marginal differences were observed across the test scenarios, with a less than two-second increase in login time with two App Volumes AppStacks in place. The variance in login times for the three test scenarios that do not include App Volumes should be considered as similar results within a margin of error of each other.

Average User Login Times Comparison Chart

Figure 14: Average User Login Times Comparison Chart

Login VSI is a valuable user experience benchmark tool for end-user-computing (EUC) workloads. It allowed us to adjust the active user session count and measure the corresponding impact on user experience and application responsiveness. During our testing, we increased the session count until we reached the point where user experience degraded below acceptable levels, and then we adjusted for high availability.

Figure 15 shows the VSImax scores that represent the impact that increasing the number of active sessions has on application response times and, thus, user experience. The VSI baseline score of 730 ms places the results in an excellent performance rating category. Once we reached 700 sessions, if we ran additional sessions in this environment, with this synthetic workload, and simulated the loss of a single host server, the user experience degraded. For more information on the definition of VSImax, see VSImax Overview.

 Testing was performed with synthetic user workloads

Note: Testing was performed with synthetic user workloads. Real-world users exercise applications and access data in a more intermittent, random manner. Also, most organizations deploy more than a single use case in a Horizon 7 or Horizon Apps environment. Real-world consumption patterns vary from organization to organization. Before deploying any EUC technology, it is important to understand the use-case resource requirements. Reference architecture workloads based on lab testing might not precisely match real-world user workloads.

The following VSImax chart illustrates the results of the primary test run documented in this reference architecture. All data points provided here indicate a passing score with excellent VSI response times validated.

VSImax Results Based on Active Session Count for the Primary Test Run

Figure 16: VSImax Results Based on Active Session Count for the Primary Test Run

Figure 17 shows the VSI Comparison bar chart for two consecutive test runs, and displays the following metrics:

Active Session – Total number of sessions reported as active

Launched Sessions – Total number of sessions reported as launched by the VSI launcher systems

Stuck Sessions – Total number of reported stuck sessions, where the VSI workload prematurely terminated

Baseline – The calculated VSI baseline score (response time, in ms)

Threshold –The point where a VSImax is reached (baseline + 1000 ms)

The results across both tests are well within the success criteria’s level of variability.

Login VSI Comparison Chart for Two (Primary and Secondary) Test Runs

Figure 17: Login VSI Comparison Chart for Two (Primary and Secondary) Test Runs

Figure 18 shows the VSI Index Comparison chart for the two test runs. This chart compares the two tests during the ramp-up phase.

VSImax Index Chart Comparison for Two Test Runs

Figure 18: VSImax Index Chart Comparison for Two Test Runs

Boot Storms

A key performance metric for end-user computing-environments is the ability to boot VMs quickly and efficiently to minimize user wait time for their desktop and application resources.

As part of our test protocol, we always shut down every RDSH VM at the conclusion of a test. When we run a new test, we cold-boot all RDSH machines and measure the time it takes for all of them to report as available in the Horizon Administrator console. We also collect statistics to determine server and storage performance impact during the boot phase.

As figure 19 shows, the VMware reference architecture can accomplish this boot-up task in less than 1 minute with 32 RDSH instant-clone VMs with minimum impact to the host servers—only slightly higher than 30 percent processor utilization at peak on the host servers.

RDSH Hosts CPU Usage Highlighting Boot Phase

Figure 19: RDSH Hosts CPU Usage Highlighting Boot Phase

Host Performance Results

It is of vital importance for organizations to monitor vSphere host resource utilization to ensure that hosts are not loaded to the point where resource contention develops. Host resource contention can sometimes be tolerated in some server environments, but in EUC environments, resource contention can result in poor user experience and in most cases is the gating factor for those environments.

Throughout testing, hosts were carefully monitored, and resource consumption metrics are presented in the following graphs. All results are considered to be well within the success criteria for the solution that accounts for server high availability (N + 1).

Note: Callouts have been added throughout the data charts to indicate each phase of testing.

TEST PHASE DESCRIPTION
Boot Start all RDSH or VDI VMs at the same time
Login The Login VSI phase of testing is where sessions are launched and start executing the workload over a 48-minute duration.
Steady state The steady-state phase is where all user sessions are logged in and are performing various workload tasks such as using Microsoft Office, web browsing, PDF printing, playing videos, and compressing files.
Logout Sessions finish executing the Login VSI workload and log out.

Table 2: Test Phase Callouts and Descriptions

RDSH vSphere Hosts

Highlights of the captured metrics are provided in Figure 20.

RDSH vSphere Host Metrics

Figure 20: RDSH vSphere Host Metrics

Figure 21 shows that the CPU consumption of each host server was around 65 percent during peak load, as intended. The primary gating factor for determining workload scalability is based on CPU usage at the host and workload VM level. Server fault tolerance has been incorporated into the design where the 700-session load can be maintained with one of the four host servers out of service.

shows that the host memory usage was the same for all four servers

Figure 22 shows that the host memory usage was the same for all four servers, with a relative maximum usage of 150 GB (NonKernel memory) during peak load out of an available 384 GB per host server. Each RDSH VM was configured with 32 GB of vRAM, with all guest memory reserved.

RDSH vSphere Host Memory Usage

Figure 22: RDSH vSphere Host Memory Usage

Figure 23 shows that network bandwidth consumption briefly spiked to 2 Gbps per network adapter, per host when booting the RDSH machines, with the sustained network load reaching 600 Mbps RX/TX during steady-state operations. Each host server was configured with two 10G network adapters, so the reported results should not be considered statistically significant.

RDSH vSphere Host Network Usage

Figure 23: RDSH vSphere Host Network Usage

See Horizon Apps Design for details on the VM and session distribution configured across the host servers.

Infrastructure vSphere Hosts

Highlights of the captured metrics are provided in Figure 24.

Infrastructure vSphere Host Metrics

Figure 24: Infrastructure vSphere Host Metrics

Figure 25 shows that the CPU consumption of each infrastructure vSphere host was less than 15 percent throughout testing. The primary gating factor for determining workload scalability is based on CPU usage at the host and workload VM level. Server fault tolerance has been incorporated into the design, where the management operations and 700-session load can be maintained with one of the two hosts out of service.

Infrastructure vSphere Host CPU Usage

Figure 25: Infrastructure vSphere Host CPU Usage

Figure 26 shows that the host memory usage was ~90 GB (NonKernel memory) on the first host and ~60 GB on the second, throughout testing, out of an available 256 GB per host server.

Infrastructure vSphere Host Memory Usage

Figure 26: Infrastructure vSphere Host Memory Usage

Figure 27 shows that the network bandwidth consumption was under 500 Mbps per network adapter, per host throughout testing operations. Each host was configured with two 10G network adapters, so the reported results should not be considered statistically significant.

Infrastructure vSphere Host Network Usage

Figure 27: Infrastructure vSphere Host Network Usage

See Horizon Apps Design for details on the VM distribution configured across the host servers.

Virtual Machine Performance Results

In addition to monitoring host performance, it is very important for organizations to monitor VM resource utilization to ensure that VMs are not loaded to the point where resource contention develops. Host resource contention can sometimes be tolerated in server environments, but in hosted desktop environments, resource contention can result in poor user experience or result in the loss of operational services needed to sustain a Horizon 7 or Horizon Apps environment.

Throughout testing, the RDSH and infrastructure VMs were carefully monitored, and resource consumption metrics are presented in the following graphs. All results are considered to be well within the success criteria for the solution that accounts for high availability for each product component.

RDSH Virtual Machines

Highlights of the captured metrics are provided in Figure 28.

RDSH VM Metrics

Figure 28: RDSH VM Metrics

The performance statistics for a single RDSH VM are provided as a representation of the 32 total RDSH machines provisioned for this solution. Each RDSH machine supported a load of up to 22 sessions.

Figure 29 shows that the guest OS CPU consumption of the VM was less than 50 percent, with a few brief spikes exceeding 60 percent, toward the end of the login phase and throughout steady-state operations. High availability has been accounted for at the VM level, given that the RDSH machines in this solution have the capacity to support an increased session load in the event that one of the vSphere hosts goes out of service.

RDSH VM CPU Usage

Figure 29: RDSH VM CPU Usage

Figure 30 shows that guest OS memory usage was ~12 GB consumed out of an available 32 GB. The peak usage was observed toward the end of login and throughout steady-state operations.

RDSH VM Memory Usage

Figure 30: RDSH VM Memory Usage

Figure 31 shows that the network bandwidth consumption peaked to around 10 MBps during testing operations, which should not be considered as statistically significant. The network traffic traveling through this VM resulted from communications with the infrastructure software (such as the Connection Servers and domain controllers), user data (such as User Environment Manager data, profiles, and data repositories), and the Blast Extreme display protocol.

RDSH VM Network Usage

Figure 31: RDSH VM Network Usage

Figures 32 and 33 show that disk usage peaked at approximately 420 disk IOPS, with less than 0.6 disk queue lengths observed, which should not be considered as statistically significant.

RDSH VM Disk Usage

Figure 32: RDSH VM Disk Usage

RDSH VM Disk Queuing

Figure 33: RDSH VM Disk Queuing

Infrastructure Virtual Machines

Throughout testing, the infrastructure VMs were carefully monitored. Resource consumption metrics are presented in the following graphs. All results are considered to be well within the success thresholds, even taking high-availability requirements into account.

Highlights of the captured metrics are provided in Figure 34.

Infrastructure VM Metrics

Figure 34: Infrastructure VM Metrics

Appendix D includes charts that detail the metrics for each type of infrastructure VM: Active Directory domain controllers, file servers, SQL Servers, Connection Servers, App Volumes Managers, vCenter Server for the infrastructure VMs, and vCenter Server for the RDSH VMs.

Storage Performance Results

Because vSAN and App Volumes are storage-focused technologies, we collected storage-related metrics during all phases of testing. Shared storage performance and capacity metrics are highlighted in the following figures.

RDSH vSAN Datastore

Highlights of the captured metrics are provided in Figure 35.

RDSH vSAN Datastore Metrics

Figure 35: RDSH vSAN Datastore Metrics

Figures 36 through 38 show the vSAN datastore performance captured during the primary test run using vRealize Operations Manager and the vSAN Pack. The less than 5 milliseconds of write latency was observed at peak load.

Storage Performance Chart vSAN Datastore Latency (ms)

Figure 36: Storage Performance Chart vSAN Datastore Latency (ms)

The write throughput was greater than 110 MBps, with the read throughput highest at boot to approximately 70 MBps, and less than 30 MBps at steady state.

Storage Performance Chart for vSAN Datastore Throughput (MBps)

Figure 37: Storage Performance Chart for vSAN Datastore Throughput (MBps)

Similar to the data throughput statistics, the read IOPS was highest during boot, captured at slightly above 4,000 and averaging around 500 IOPS throughput for most of the test. Write IOPS peaked at around 1,500 toward the end of steady state.

Storage Performance Chart for vSAN Datastore IOPS

Figure 38: Storage Performance Chart for vSAN Datastore IOPS

AppStacks Datastore

Highlights of the captured metrics are provided in Figure 39.

AppStacks Datastore Metrics

Figure 39: AppStacks Datastore Metrics

Figures 40 through 42 show the AppStacks datastore performance captured during the primary test run using vRealize Operations Manager. Less than 1.2 milliseconds of read latency was observed at peak load.

Storage Performance Chart for AppStacks Datastore Latency (ms)

Figure 40: Storage Performance Chart for AppStacks Datastore Latency (ms)

The read throughput was slightly greater than 7 MBps at boot, when 32 RDSH machines attached two AppStacks per VM.

Storage Performance Chart for AppStacks Datastore Throughput (KBps)

Figure 41: Storage Performance Chart for AppStacks Datastore Throughput (KBps)

Similar to the data throughput statistics, the read IOPS was highest during boot, captured at slightly above 350. Because AppStacks are read-only when used in production, all write activity recorded was negligible.

Storage Performance Chart AppStacks Datastore IOPS

Figure 42: Storage Performance Chart AppStacks Datastore IOPS

Figure 43 shows the storage capacity for the vSAN datastore that housed the 32 RDSH VMs and Instant Clone Technology (that is, parent, replica, and template VMs, and provisioned clones). The total available capacity for the datastore was 11.53 TB, of which, 540.48 GB was used by the RDSH machines, and 558.25 GB was consumed for vSAN overhead operations (replicas, witnesses, RAID components, and so on).

vSAN RDSH Datastore Storage Capacity Reported by vCenter

Figure 43: vSAN RDSH Datastore Storage Capacity Reported by vCenter

Figure 44 shows the amount of the storage space used by each RDSH machine.

vSAN RDSH Datastore Storage Capacity for RDSH VMs

Figure 44: vSAN RDSH Datastore Storage Capacity for RDSH VMs

Conclusion

This Horizon Apps RDSH solution addresses IT needs by delivering a platform that is cost effective and simple to deploy and manage. The design and approach used in this reference architecture provide for a flexible and high-performance solution, incorporating a familiar and consistent management model from VMware. In addition, the solution offers numerous enterprise-class data management features to deliver a scalable end-user-computing solution.

This Horizon Apps architecture provisioned Windows Server RDSH virtual machines for delivering responsive, resilient, high-performance hosted apps and shared desktops while demonstrating many advantages for enterprise administrators. Instant Clone Technology, User Environment Manager, App Volumes, and vSAN were combined together and performance-tested as the core focus with excellent results.

The testing for this solution validates functional support, interoperability, and scalability performance across the VMware Horizon suite of products and features related to RDSH delivery.

Virtual desktop end-user experience, as measured by the Login VSI tool in benchmark mode, offers outstanding results using Intel Broadwell E5-2698 v4 processors as the gating factor for the RDSH vSphere host cluster. VMware vSAN provided acceptable results for the RDSH Instant Clone Technology–based machines.

Appendix A: Configuration and Settings

This appendix lists the configuration and settings used for the various components of the Horizon 7 RDSH or Horizon Apps solution.

Horizon Connection Server Settings

Table 3 lists the settings for Connection Server testing.

CONFIGURATION PARAMETER SETTING
General settings The following fields were left unselected: HTTPS Secure Tunnel, PCoIP Secure Gateway, Blast Secure Gateway.
Authentication Active Directory user credentials

Table 3: Connection Server Settings

Desktop Pool and Farm Settings

Table 4 lists the settings for desktop-pool and farm testing.

POOL PARAMETER SETTING
Pool Type RDS Desktop Pool
User Assignment Floating
Adobe Flash Quality Do Not Control
Adobe Flash Throttling Disabled
Connection Server restrictions None
Farm Type Automated Farm (Instant Clones)
Display Protocol VMware Blast
Allow users to choose protocol Yes
Log off disconnected sessions Never
Max sessions per RDS Host 30
Max number of machines 32
Minimum number of ready (provisioned) machines 0
Storage Optimization Use VMware Virtual SAN

Table 4: Desktop-Pool Test Settings

App Volumes Manager Settings

The following key configurations were used for this project.

APP VOLUMES SETTING VALUE USED FOR APPSTACKS ONLY
Individual datastore size 1 TB (dedicated for AppStacks)
Storage Group None
Template Template.vmdk (20GB)
Mount Local Not Enabled (default)
Mount on Host Not Enabled (default)
AppStack Attachments Active Directory Machine OUs

An AppStack storage group can be configured to replicate AppStacks between multiple datastores, and this type of spread distribution policy can ensure that users are connected to AppStacks in a roundrobin fashion. For the purposes of this study, a single datastore was used, so a storage group was not configured.

App Volumes can be configured to use the Mount on Host option for all volume mount operations as a best practice. This option was not configured as part of this study so that the AppStacks’ storage performance could be observed at the datastore level.

Note: Writeable volumes are not supported with RDSH and as such, were excluded from the design.

Storage Configuration

Three datastores were provisioned on the shared Tegile T3600 storage system for the infrastructure cluster and AppStacks. VMware vSAN was used for the RDSH cluster.

DATASTORE PROVIDER SIZE PURPOSE
vsanDatastore-VDI VMware vSAN 11.53 TB 11.53 TB
T3600-02-RA-AppStacks-1 Shared Tegile T3600 Array 1 TB Dedicated AppStacks volume
T3600-02-RA-Apps-1 Shared Tegile T3600 Array 1 TB Infrastructure cluster and VMs
T3600-02-RA-Apps-2 Shared Tegile T3600 Array 1 TB Infrastructure cluster and VMs
Local storage Compact Flash 2x 16 GB Boot storage for hosts

Table 6: Storage Layout

The following diagram shows the vSAN configuration used for the architecture and testing, which consisted of four vSphere hosts equipped with five SSDs per server. The vSAN datastore was used to store the RDSH VMs.

vSAN High-Level Architecture

Figure 45: vSAN High-Level Architecture

Network Configuration

The vSphere hosts were configured to allow each server blade to have access to two 10-GbE adapters. VMware vSphere Distributed Switch™ was used on all hosts.

Host Network Configuration

Figure 46: Host Network Configuration

Two adapters were used as uplinks for a vSphere Distributed Switch that was used for the host management network, iSCSI access, vSphere vMotion®, and RDSH VM traffic.

Configuration of RDSH Server Master Images

We built target RDSH images according to VMware best practices. A master Windows 2012 R2 image with 8 vCPUs and 32 GB of vRAM was built. The VMware Tools™ version and virtual hardware version matched the vSphere operating environment. We then optimized the image for RDSH with the OS Optimization Tool and made all recommended RDSH-specific configuration changes.

For the App Volumes provisioning VM, we did not install the Horizon Agent. For target images, the Horizon Agent, User Environment agent (FlexEngine), and App Volumes Agent were installed.

Because the vSphere hosts were equipped with an adequate amount of physical RAM (384 GB), and because we did not want to use shared storage for VM swap files, each RDSH VM had a 100 percent memory reservation set.

We used the Active Directory Group Policy Object (GPO) settings shown in the following tables.

CONFIGURATION OPTION SETTING
Disable Automatic Updates Disabled
Don’t show messages while viewing a document Disabled
Show messages while I launch Reader Disabled
Turn off user participation in the feedback program Disabled
Enable protected Mode at Startup Disabled

Table 7: Adobe Reader GPO Settings

CONFIGURATION OPTION SETTING
Disable First Run Movie Enabled
Disable Office First Run on application boot Enabled
Disable Opt-in Wizard on first run Enabled
Do not use hardware graphics acceleration Enabled

Table 8: Key Microsoft Windows GPO Settings

CONFIGURATION OPTION SETTING
Central location of Flex config files \\file1.vmweuc.com\uemconfig\General
Process folder recursively Enabled
Path and of log files \\file1.vmweuc.com\uemusers\%username%\Logs\FlexEngine.log
Log level Warn
Maximum log file size in kB 512
Log total size of profile archive and profile archive backups folder Disabled
Location of storing user profile archives backups \\file1.vmweuc.com\uemusers\%username%\Backups
Number of backups profile archive 1
Create single backup per day Disabled
Location of storing user profile archives \\file1.vmweuc.com\uemusers\%username%\Archives
Compress profile archives Enabled
Retain file medication dates Disabled
Use mandatory profiles on the RD Session Host server Enabled
Set roaming profile path for all users logging onto this computer C:\Users\MandatoryProfile

Table 9: User Environment Manager GPO Settings

Login VSI Test Parameters

Table 10 lists the Login VSI parameters used for testing.

CONFIGURATION ITEM SETTING
Enable Session Monitor Yes
Workload Knowledge Worker
Benchmark Mode Yes
Steady State Duration 15 Minutes
Dedicated Dataserver Yes
Dedicated Webserver Yes
VSImax reached No
(Used for workload and response time measure)
Office Version 2016
Home Directories Yes
Overall logon rate Session count x 4 seconds
(one session every four seconds over 48 min.)
Sessions per launcher ~17
Launcher VMs 40
Launcher Hosts 8
Overall logon rate Session count x ~4.1 seconds
(one session every four seconds over 48 min.)

Table 10: Login VSI Test Parameters

Appendix B: Virtual Machine Specifications

The settings for key components are contained in the tables that follow.

Infrastructure Server VMs

Tables 11 through 16 list the specifications used when creating the various types of server VMs used in testing.

ATTRIBUTE DETAILS
OS Appliance, SUSE Linux 11
vCPU 4
vRAM 16 GB
Storage 320 GB

Table 11: vCenter VM Details

ATTRIBUTE DETAILS
OS Microsoft Windows Server 2012 R2
vCPU 4
vRAM 12 GB
Storage 50 GB

Table 12: Connection Server VM Details

ATTRIBUTE DETAILS
OS Microsoft Windows Server 2012 R2
vCPU 4
vRAM 12 GB
Storage 50 GB

Table 13: App Volumes Manager VM Details

ATTRIBUTE DETAILS
OS Microsoft Windows Server 2012 R2
vCPU 2
vRAM 8 GB
Storage 50 GB

Table 14: Active Directory Domain Controller VM Details

ATTRIBUTE DETAILS
OS Microsoft Windows Server 2012 R2
vCPU 2
vRAM 12 GB
Storage 150 GB

Table 15: SQL Server VM Details

ATTRIBUTE DETAILS
OS Microsoft Windows Server 2012 R2
vCPU 2
vRAM 12 GB
Storage 350 GB

Table 16: File Server VM Details

RDSH Server Image Configuration

Table 17 details the virtual hardware settings and the software versions used for image configuration.

ATTRIBUTE SPECIFICATION
Operating system Microsoft Server 2012 R2 Standard
Hardware VMware Virtual Hardware Version 13
vCPU 8
Memory 32 GB (Reserved all guest memory)
Video RAM Default
3D graphics Off
NIC E1000E was used (VMXNET3 is preferred)
Virtual SCSI controller Paravirtual
Virtual Disk: VMDK 1 - OS 50 GB
Virtual Disk: VMDK 2 – AppStack 1 20 GB – Office 2016
Virtual Disk: VMDK 3 – AppStack 2 20 GB – Login VSI Apps
Virtual floppy drive Removed
Virtual CD/DVD drive Removed
VMware Tools release 10.1.0.4449150
VMware Horizon Agent release 7.1.0.5170901
VMware User Environment Manager release 9.1.0.175
VMware App Volumes release 2.12.1.103
VMware vRealize Horizon release 6.4.0.4661670
Applications Microsoft Office 2016 Pro Plus 32-bit
Microsoft Internet Explorer 11
Login VSI 4.1.25.6 Target Installation
The following apps were delivered as
AppStacks:
• Adobe Reader 11
• Adobe Flash 11.5
• Java 7.13
• Doro PDF 1.82
• FreeMind

Table 17: Desktop Image Configuration Settings

Appendix C: Bill of Materials

This appendix details the major hardware and software components that were used during this project.

Hardware BOM

The test configuration bill of materials is summarized in the following table.

AREA COMPONENT QUANTITY
Host hardware Infrastructure • Dell R730 Servers (2x Intel Xeon processorE5-2695 v3 CPUs 2.3 GHz)
• 256 GB of RAM
• NICs 2x 10GbE, 2x 1 GB
2
Host hardware RDSH • Dell R730 Servers (2x Intel Xeon processor E5-2698 v4 CPUs 2.2 GHz) • 384 GB of RAM • NICs 2x 10GbE, 2x 1 GB • Dell PERC H730P Mini RAID Controller, 5x 800 GB SSDs per server 4
Storage hardware • Tegile T3600 Storage Array – For App Volumes and Infrastructure datastores
• Firmware version 3.5
1
Network hardware • Cisco Nexus 9372 Switches
• Cisco 2248 Fabric Extenders
2
2
Login VSI Launchers • Host servers
• Storage array
4
1

Table 18: Hardware Test Configuration

Software BOM

The test configuration bill of materials is summarized in the following table.

COMPONENT VERSION
VMware vSphere (ESXi, vCenter Server Applicance, vSAN) 6.5
VMware Horizon 7 Enterprise Edition 7.1
Connection Server 7.1
VMware App Volumes 2.12.1
VMware User Environment Manager 9.1
VMware vRealize Operations 6.4
VMware Horizon Client 4.4
Microsoft SQL Server 2014
Microsoft Windows Server 2012 R2 Standard
Microsoft Office 2016 ProPlus 32-bit
Login VSI 4.1.25.6 (Pro License)

Table 19: Software Test Configuration

Appendix D: Details of Infrastructure VM Metrics

Throughout testing, the infrastructure VMs were carefully monitored, and resource consumption metrics are presented in the following graphs. All results are considered to be well within the success criteria for the solution that accounts for high availability for each product component.

Note: Callouts have been added throughout the data charts to indicate each phase of testing

TEST PHASE DESCRIPTION
Boot Start all RDSH or VDI VMs at the same time
Login The Login VSI phase of testing is where sessions are launched and start executing the workload over a 48-minute duration.
Steady state The steady-state phase is where all user sessions are logged in and are performing various workload tasks such as using Microsoft Office, web browsing, PDF printing, playing videos, and compressing files.
Logout Sessions finish executing the Login VSI workload and log out.

Table 20: Test Phase Callouts and Descriptions

Active Directory Domain Controllers

Figures 47 through 51 detail the CPU, memory, network, and disk usage and queuing of the Active Directory domain controller VM.

AD VM CPU Usage

Figure 47: AD VM CPU Usage

AD VM Memory Usage

Figure 48: AD VM Memory Usage

AD VM Network Usage

Figure 49: AD VM Network Usage

AD VM Disk Usage

Figure 50: AD VM Disk Usage

AD VM Disk Queuing

Figure 51: AD VM Disk Queuing

Windows File Server

Figures 52 through 56 detail the CPU, memory, network, and disk usage and queuing of the Windows file server VM.

File Server VM CPU Usage

Figure 52: File Server VM CPU Usage

File Server VM Memory Usage

Figure 53: File Server VM Memory Usage

File Server VM Network Usage

Figure 54: File Server VM Network Usage

File Server VM Disk Usage

Figure 55: File Server VM Disk Usage

File Server VM Disk Queuing

Figure 56: File Server VM Disk Queuing

SQL Server

Figures 57 through 61 detail the CPU, memory, network, and disk usage and queuing of the SQL Server VM.

SQL Server VM CPU Usage

Figure 57: SQL Server VM CPU Usage

SQL Server VM Memory Usage

Figure 58: SQL Server VM Memory Usage

SQL Server VM Network Usage

Figure 59: SQL Server VM Network Usage

SQL Server VM Disk Usage

Figure 60: SQL Server VM Disk Usage

SQL Server VM Disk Queuing

Figure 61: SQL Server VM Disk Queuing

Horizon Connection Servers

Figures 62 through 66 detail the CPU, memory, network, and disk usage and queuing of the Connection Server VMs.

Connection Server VM CPU Usage

Figure 62: Connection Server VM CPU Usage

Connection Server VM Memory Usage

Figure 63: Connection Server VM Memory Usage

Connection Server VM Network Usage

Figure 64: Connection Server VM Network Usage

Connection Server VM Disk Usage

Figure 65: Connection Server VM Disk Usage

Connection Server VM Disk Queuing

Figure 66: Connection Server VM Disk Queuing

App Volumes Managers

Figures 67 through 71 detail the CPU, memory, network, and disk usage and queuing of the App Volumes Manager VMs.

App Volumes Manager VM CPU Usage

Figure 67: App Volumes Manager VM CPU Usage

App Volumes Manager VM Memory Usage

Figure 68: App Volumes Manager VM Memory Usage

App Volumes Manager VM Network Usage

Figure 69: App Volumes Manager VM Network Usage

App Volumes Manager VM Disk Usage

Figure 70: App Volumes Manager VM Disk Usage

App Volumes Manager VM Disk Queuing

Figure 71: App Volumes Manager VM Disk Queuing

Management vCenter Server Appliance

Figures 72 through 76 detail the CPU, memory, network, and disk usage and latency of the vCenter Server VM used for managing the infrastructure hosts and VMs.

Management vCenter Server VM CPU Usage

Figure 72: Management vCenter Server VM CPU Usage

Management vCenter Server VM Memory Usage

Figure 73: Management vCenter Server VM Memory Usage

Management vCenter Server VM Network Usage

Figure 74: Management vCenter Server VM Network Usage

Management vCenter Server VM Disk Usage

Figure 75: Management vCenter Server VM Disk Usage

Management vCenter Server VM Disk Latency

Figure 76: Management vCenter Server VM Disk Latency

RDSH vCenter Server Appliance

Figures 77 through 81 detail the CPU, memory, network, and disk usage and latency of the vCenter Server VM used for managing the RDSH vSphere hosts and VMs.

RDSH vCenter Server VM CPU Usage

Figure 77: RDSH vCenter Server VM CPU Usage

RDSH vCenter Server VM Memory Usage

Figure 78: RDSH vCenter Server VM Memory Usage

RDSH vCenter Server VM Network Usage

Figure 79: RDSH vCenter Server VM Network Usage

RDSH vCenter Server VM Disk Usage

Figure 80: RDSH vCenter Server VM Disk Usage

RDSH vCenter Server VM Disk Latency

Figure 81: RDSH vCenter Server VM Disk Latency

About the Authors

Lead Author

Frank Anderson is a Solutions Architect in VMware End-User-Computing Technical Marketing. He is currently focusing on the creation of best-practice technical collateral throughout the Horizon portfolio, including performance studies, white papers, enablement of technical communities, and tool development. He has over 20 years of industry experience in end-user computing in the design, implementation, testing, and support of complex computing environments of many varieties.

Contributing Author

Donal Geary is a Reference Architect Engineer in VMware End-User-Computing Technical Marketing. Previously he worked as Lead System Administrator for VMware Internal IT and as Senior Technical Support Engineer for the VMware Global Support Services Organization. To comment on this paper, contact VMware End-User-Computing Technical Marketing at euc_tech_content_feedback@vmware.com.