Dell EMC Ready Architectures for VDI Designs for VMware ... · negative impact on your total cost...

Dell EMC Ready Architectures for VDIDesigns for VMware Horizon on Dell EMC XC FamilyAugust 2019

H17386.3

Validation Guide

Abstract

This validation guide describes the architecture and performance of the integration ofVMware Horizon components for virtual desktop infrastructure (VDI) on Dell EMC XCFamily devices.

Dell EMC Solutions

Copyright © 2018-2019 Dell Inc. or its subsidiaries. All rights reserved.

Dell believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS-IS.” DELL MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH

RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS

FOR A PARTICULAR PURPOSE. USE, COPYING, AND DISTRIBUTION OF ANY DELL SOFTWARE DESCRIBED IN THIS PUBLICATION REQUIRES AN

APPLICABLE SOFTWARE LICENSE.

Dell Technologies, Dell, EMC, Dell EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be the property of their

respective owners. Published in the USA.

Dell EMCHopkinton, Massachusetts 01748-91031-508-435-1000 In North America 1-866-464-7381www.DellEMC.com

2 Dell EMC Ready Architectures for VDI

Introduction 5Executive summary.............................................................................................6Document purpose..............................................................................................7Audience............................................................................................................. 7We value your feedback...................................................................................... 7

Test Environment Configuration and Best Practices 9Validated hardware resources........................................................................... 10

Enterprise hardware............................................................................. 10Storage hardware................................................................................. 10Graphics hardware................................................................................10Network hardware.................................................................................11

Validated software resources............................................................................ 12Validated system versions................................................................................. 12Virtual networking configuration........................................................................13Management server infrastructure.................................................................... 13

NVIDIA GRID License Server................................................................ 14SQL Server databases.......................................................................... 14DNS...................................................................................................... 14

High availability..................................................................................................14VMware Horizon 7 architecture.........................................................................15

Solution Performance and Testing 17Testing process................................................................................................. 18

Resource monitoring.............................................................................18Load generation....................................................................................18Profiles and workloads..........................................................................19A comparison of linked clones and instant clones.................................22Virtual Desktop Profile......................................................................... 23

Login VSI test analysis and results.................................................................... 23Login VSI test results summary............................................................24Knowledge Worker, 135 users per host, ESXi 6.7, Horizon 7.7 ............ 25Power Worker, 106 users per host, ESXi 6.7, Horizon 7.7 .................... 31Graphics Multimedia worker, 48 vGPU users per host, ESXi 6.7, Horizon7.7........................................................................................................36Graphics Power Worker, 96 vGPU users per host, ESXi 6.7, Horizon 7.7.............................................................................................................44RDSH Task Worker, 233 users per host, ESXi 6.7, Horizon 7.7 ........... 53

Conclusion 59Test results and density recommendations....................................................... 60Summary.......................................................................................................... 60

References 63Dell EMC documentation.................................................................................. 64VMware documentation....................................................................................64NVIDIA documentation......................................................................................64

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

CONTENTS

Dell EMC Ready Architectures for VDI 3

Contents


CHAPTER 1

Introduction

This chapter presents the following topics:

l Executive summary................................................................................................................. 6l Document purpose.................................................................................................................. 7l Audience..................................................................................................................................7l We value your feedback.......................................................................................................... 7


Executive summary

Virtual desktop infrastructure (VDI) plays a crucial role in today's business transformationinitiatives. VDI is the most efficient way to present Microsoft Windows applications to users intheir digital workspaces and provides a consistent user experience across devices for the modern-day mobile workforce. Organizations increasingly rely on VDI to provide the agility, security, andcentralized management that is so important for their workforce.

It is often challenging for organizations to set up a VDI infrastructure. This challenge is mainlybecause a typical VDI infrastructure involves the integration of multiple data center componentssuch as storage, network, and compute. The multivendor profile of these components oftencreates challenges during deployment and can also affect the system's performance if it is notoptimized for VDI.

To consistently maintain a multicomponent and multivendor environment with a specialized skill setis challenging for most organizations. The effort to maintain a stable VDI infrastructure can have anegative impact on your total cost of ownership (TCO).

Dell EMC Ready Architectures for VDI based on Dell EMC XC series appliances is a perfectsolution for your VDI workloads. These hyperconverged appliances integrate Dell EMC PowerEdgeservers, Nutanix software, and a choice of hypervisors to run any virtualized workload you choose.You can deploy an XC cluster in 30 minutes and manage it without specialized IT resources. XCSeries solutions eliminate the need for over-provisioning and capital expenditures that are basedon anticipated capacity and performance requirements.

System performance and capacity can be easily expanded one node at a time with zero downtime,offering customers linear and predictable scale-out expansion and pay-as-you-grow flexibility. Afault-tolerant architecture and self-healing capabilities provide system reliability and help ensuredata integrity. You will have an enterprise-level infrastructure with rapid deployment, less timeneeded for routine management tasks, faster system restoration, and integrated enterprise classdata protection. Moreover, Dell EMC's Global Service and Support organization fully supports allXC Series hardware, software, and deployments.

For customers who have chosen a Nutanix-based environment, Dell EMC recommends XC Familydevices that are optimized for VDI workloads to run VMware Horizon 7 VDI infrastructure. VMwareHorizon 7 has a streamlined approach to delivering and managing virtual desktops and applications,providing a consistent user experience across devices and locations while keeping corporate datasecure and compliant. XC series appliances—the XC740xd-24 (2U) and the XC640-10 (1U)—aredesigned for compute- and performance-intensive workloads in VDI. XC740xd-24 devices alsosupport GPU hardware for graphics-intensive desktop deployments.

The Dell EMC Ready Architectures for VDI team tests VDI solutions to ensure their validity. As partof the testing process, engineers tune the system to maximize performance and efficiency, anddocument best practices. Finally, a separate team of experts evaluates the test results to ensurethat the systems are properly configured and sized for customers. In the validation effortdescribed in this guide, we have used the Login VSI tool, which is an industry standard tool forbenchmarking VDI workloads. We tested typical Login VSI workloads such as Task worker,Knowledge worker, Power worker, and Multimedia worker with each workload being accompaniedby an appropriate desktop virtual machine (VM) profile (that is, vCPU count, memory configuredon the VM and so on.). This document provides a detailed analysis that is based on those testresults. We recommend user density figures for these workloads while giving the utmostimportance to the user experience.

Introduction


Document purpose

This validation guide details the architecture, components, testing methods, and test results forDell EMC XC Family devices with VMware Horizon 7. It includes the test environmentconfiguration and best practices for systems that have undergone testing.

Audience

This guide is intended for architects, developers, and technical administrators of IT environments.It provides an in-depth explanation of the testing methodology and basis for VDI densities. It alsovalidates the value of the Dell EMC Ready Architectures for VDI that deliver Microsoft Windowsvirtual desktops to users of VMware Horizon 7 VDI components on XC Family devices.

We value your feedback

Dell EMC and the authors of this document welcome your feedback on the solution and thesolution documentation. Contact the Dell EMC Solutions team by email or provide your commentsby completing our documentation survey.

Authors: Dell EMC Ready Architectures for VDI Team.

Introduction


mailto:[email protected]?subject=Feedback:%20Dell%20EMC%20Ready%20Architectures%20for%20VDI:%20Designs%20for%20VMware%20Horizon%20for%20Dell%20EMC%20XC%20Family%20VG%20(H17386.3)

https://www.surveymonkey.com/r/SolutionsSurveyExt

Introduction


CHAPTER 2

Test Environment Configuration and BestPractices


l Validated hardware resources................................................................................................ 10l Validated software resources.................................................................................................12l Validated system versions...................................................................................................... 12l Virtual networking configuration............................................................................................ 13l Management server infrastructure.........................................................................................13l High availability...................................................................................................................... 14l VMware Horizon 7 architecture............................................................................................. 15


Validated hardware resourcesDell EMC validated the solution with the specific hardware resources listed in this section.

Enterprise hardware

We used a 3-node cluster of Dell EMC XC Family XC740xd-24 devices with the componentconfiguration that is listed in the following table. We called this configuration "Density Optimized."It comes with 2nd Generation Intel Xeon Scalable processors, code named Cascade Lake.

We used Dell EMC XC740xd-24 appliances to deliver performance while driving savings on power,cooling, and data center space. These XC devices are designed to handle VDI workloads andreduce Operational Expenditure (OPEX).

Table 1 Validated Density Optimized hardware configuration

Enterpriseplatform

CPU Memory RAIDcontroller

HD configuration Network

XC740xd-24 2 x 6248 IntelXeon Gold (20-core, 2.6 GHz)

768 GB @2933 MT/s

HBA 330 ADP l 2 x 240 GB M.2

l 2 x 960 GB SSD

l 6 x 1.2 TB HDD

2 x MellanoxConnect X-4 LX 25GbE SFP RackNDC

Dell EMC XC740xd-24 devices are one of the most versatile and scalable hyperconvergedinfrastructure platforms. They are purpose-built for performance-intensive VDI workloads and youcan use them to scale incrementally to match VDI requirements in a pay-as-you-grow model.

The Dell EMC XC740xd-24 device is a 2U platform that can be configured with 24 x 2.5-inch disksto serve a broad range of capacity requirements. Each one comes equipped with dual CPUs, 10 to28 cores, and up to 1.5 TB of high performance RAM. They are VDI optimized and support GPUhardware for graphics-intensive desktop deployments. The XC740xd-24 can be configured with orwithout GPUs.

Storage hardwareWe used the following storage configuration for different storage tiers.

Storage hardware used per cluster node:

l 2 x Boot Optimized Storage Solution (BOSS) M.2 SATA Device for the host OS

l 2 x 960 GB SATA SSD for the Performance tier

l 6 x 1.2 TB NL SAS for the Capacity tier

The M.2-based BOSS module boots the hypervisor and the Nutanix Controller VM (CVM). PERCHBA330 connects the CVM to the SSDs and HDDs. All HDD and SSD disks are presented to theNutanix CVM running locally on each host, which contributes to the clustered DSF storage pool.Two SSDs were used for the Performance tier (Tier1) and six HDDs were used for the Capacitytier (Tier2), per node.

Graphics hardware

We used NVIDIA Tesla T4 GPU hardware in our tests for graphics-intensive workloads. The T4 is asingle-slot 6-inch PCI Express Gen3 graphics card featuring a single high-end NVIDIA T4 GPU.NVIDIA's newest architecture is available in the T4 GPU, which is considered the universal GPU for

Test Environment Configuration and Best Practices


data center workflows. The GPU architecture supports GDDR6 memory, which provides improvedperformance and power efficiency when compared to the previous generation, GDDR5.

The T4 provides power savings by requiring lower power (70 watts) and it does not require anysupplemental power connector. It also uses the NVIDIA Turing architecture, which includes TensorCores for accelerating deep learning inference workflows and provides up to 40X higherperformance compared to CPUs, with 60 percent of the power consumption. Add up to six GPUcards to your Dell EMC XC740xd-24 device to enable up 96 GB of video buffer. In modernized datacenters, use this card during off-peak hours to perform your inferencing workloads.

Network hardware

We used the following network hardware in our test environment:

l Dell Networking S4048 (10 GbE ToR switch)—A high-density, ultralow-latency ToR switchthat features 48 x 10 GbE SFP+, 6 x 40 GbE ports and up to 720 Gbps switch fabric capacity.

l Dell Networking S5248 (25 GbE ToR switch)—A high-density, high performance, opennetworking ToR switch that features 48 x 25 GbE SFP28, 4 x 100 GbE QFSP28 ports, 2 x 100GbE QFSP28-DD ports and up to 2.0 TB/s switch fabric capacity.



Validated software resources

Dell EMC validated this solution with the software components listed in the following table.

Table 2 Validated software component versions

Component Description/Version

Hypervisor ESXi 6.7

Broker technology VMware Horizon 7 version 7.7

Broker database Microsoft SQL Server 2016

Management VM operatingsystem

Microsoft Windows Server 2016 (Connection Server and DB)

Virtual desktop operatingsystem

Microsoft Windows 10 Enterprise

Office application suite Microsoft Office Professional 2016

Login VSI test suite Version 4.1.32.1

Platform Nutanix AOS version 5.10.3.1

NVIDIA GRID software (forgraphics testing)

7.1

Validated system versions

Dell EMC validated this solution using the system versions listed in the following table.

Table 3 Version matrix for tested system

Serverconfiguration

NvidiavGPUversion

Hypervisor Hypervisorversion

Hypervisorbuild

Bios AOSversion

Windows10 version

Windows 10patches

Density-Optimized

N/A ESXi 6.7 10302608 1.6.11 5.10.3.1 1803 l KB4100347

l KB4477137

l KB4480979

l KB4480966

Density-Optimized + 6 xT4

7.1



Virtual networking configurationThe network configuration for the Dell EMC XC Family devices uses a 25 Gb convergedinfrastructure model.

All required VLANs traverse two 25 GB network interface controllers (NICs) configured in anactive/active team. For larger scaling, we recommend that you separate the infrastructuremanagement VMs from the compute VMs to aid in predictable compute host scaling.

We used the following VLAN configurations for the compute hosts, management hosts, and iDRACin this solution model:

l Compute hosts

n Management VLAN: Configured for hypervisor infrastructure traffic—L3 routed by usingthe spine layer

n Live Migration VLAN: Configured for Live Migration traffic—L2 switched by using the leaflayer

n VDI VLAN: Configured for VDI session traffic—L3 routed by using the spine layer

l Management hosts

n Management VLAN: Configured for hypervisor management traffic—L3 routed by using thespine layer

n Live Migration VLAN: Configured for Live Migration traffic—L2 switched by using the leaflayer

n VDI Management VLAN: Configured for VDI infrastructure traffic—L3 routed by using thespine layer

l VLAN iDRAC: Configured for all hardware management traffic—L3 routed by using the spinelayer

Management server infrastructure

The following table lists the sizing requirements for the management server components.

Table 4 Sizing for XC Family devices, Remote Desktop Session Host (RDSH), and NVIDIA GRIDlicense server (optional)

Component vCPU RAM (GB) NIC OS + data vDisk(GB)

Tier 2 volume(GB)

VMware vCenter Appliance 2 16 1 290

Platform Services Controller 2 2 1 30

Horizon Connection Server 8 16 1 40

SQL Server 4 8 1 40 210 (VMDK)

File server 1 4 1 40 2,048 (VMDK)

Nutanix CVM 12 32 2 0

RDSH VM 8 32 1 80

NVIDIA GRID License Server 2 4 1 40 + 5



NVIDIA GRID License ServerWhen using NVIDIA vGPU cards, graphics-enabled VMs must obtain a license from a GRID LicenseServer on your network to be entitled for vGPU.

We installed the GRID License Server software on a system running a Windows 2016 operatingsystem to test vGPU configurations.

We made the following changes to the GRID License Server to address licensing requirements:

l Used a reserved fixed IP address

l Configured a single MAC address

l Applied time synchronization to all hosts on the same network

SQL Server databases

During validation, a single dedicated SQL Server 2016 VM hosted the VMware databases in themanagement layer. We separated SQL data, logs, and tempdb into their respective volumes, andcreated a single database for Horizon Connection Server.

We adhered to VMware best practices for this testing, including alignment of disks to be used bySQL Server with a 1,024 KB offset and formatted with a 64 KB file allocation unit size (data, logs,and tempdb).

DNSDNS is the basis for Microsoft Active Directory and also controls access to various softwarecomponents for VMware services. All hosts, VMs, and consumable software components musthave a presence in DNS. We used a dynamic namespace integrated with Active Directory andadhered to Microsoft best practices.

High availability

Although we did not enable high availability (HA) during the validation that is documented in thisguide, we strongly recommend that HA be factored into any VDI design and deployment. Thisprocess follows the N+1 model with redundancy at both the hardware and software layers. Thedesign guide for this architecture provides additional recommendations for HA and is available atthe VDI Info Hub for Ready Solutions.



https://community.emc.com/docs/DOC-69231

VMware Horizon 7 architecture

When designing and determining the architecture for a successful VDI deployment, it is importantto understand the underlying network traffic flows, ports, and components. Use Figure 1 as astarting reference for understanding the interdependencies of the different components within aVMware Horizon 7 architecture. The number of ports and protocols that are required will varydepending on the size of the deployment, the external connectivity requirements, and the displayprotocols in use (RDP, Blast, or PCoIP). You should undertake careful planning and design to allowthese ports and protocols in the corporate network firewall policies.

For more information about required ports and protocols, see VMware View ports and networkconnectivity requirements (1027217) and the VMware Horizon Reference Architecture guide.



https://kb.vmware.com/s/article/1027217

https://kb.vmware.com/s/article/1027217

https://techzone.vmware.com/resource/workspace-one-and-horizon-reference-architecture#sec9-sub2

Figure 1 VMware Horizon architecture



CHAPTER 3

Solution Performance and Testing


l Testing process......................................................................................................................18l Login VSI test analysis and results.........................................................................................23


Testing processTo ensure good EUE and cost-per-user, we conducted PAAC testing on this solution using LoginVSI, a load-generation tool that monitors both hardware resource utilization parameters and EUEduring load-testing.

For each user scenario, we ran the tests four times, once to validate data capture and three timesto collect metrics and analyze variance.

Our EUE validation consisted of logging into a session while the system was under a load createdby the VSI Login tool and completing tasks from the workload definition. While this test issubjective, it helps to provide a better understanding of the EUE in the desktop sessions,particularly under high load. It also helps to ensure reliable data gathering.

Resource monitoring

To ensure that the user experience was not compromised, we monitored the following importantresources:

l Compute host server resources—VMware vCenter (for solutions based on VMwarevSphere) or Microsoft Performance Monitor (for solutions based on Hyper-V) gather key data(CPU, memory, disk, and network usage) from each of the compute hosts during each testrun. This data was collected for each host and consolidated for reporting. We do not report anymetrics for the management host servers. However, they were monitored manually duringtesting to ensure that no bottlenecks impacted the test.

l Utilization thresholds—Resource overutilization can cause poor EUE. We monitored therelevant resource utilization parameters and compared them to relatively conservativethresholds. The thresholds were selected based on industry best practices and our experienceto provide an optimal trade-off between good EUE and cost-per-user while also allowingsufficient burst capacity for seasonal or intermittent spikes in demand.

Table 5 Parameter pass/fail thresholds

Parameter Pass/fail threshold

Physical host CPU utilization 85% a

Physical host memory utilization 85%

Network throughput 85%

Storage I/O latency 20 ms

Login VSI Failed Session 2%

a. The Ready Solutions for VDI team recommends that steady-state average CPU utilizationacross the three hosts in a cluster not exceed 85 percent in a production environment.Average CPU utilization sometimes exceeds our recommended percentage. Because of thenature of automated testing tools like Login VSI, a 5 percent margin of error was acceptedand it does not impact our sizing guidance.

l GPU resources—We collected GPU utilization metrics from VMware vCenter.

Load generationLogin VSI from Login VSI, Inc. is the industry-standard tool for testing VDI environments andRDSH environments.

Login VSI installs a standard collection of desktop application software (including Microsoft Officeand Adobe Acrobat Reader) on each VDI desktop testing instance. It then uses a configurable



launcher system to connect a specified number of simulated users to available desktops within theenvironment. When the simulated user is connected, a logon script configures the userenvironment and starts a defined workload. Each launcher system can launch connections toseveral VDI desktops (target machines). A centralized management console configures andmanages the launchers and the Login VSI environment.

We used the following login and boot conditions:

l For most of our tests, new user sessions were logged in at a steady rate over a 1-hour period.During tests of low-density solutions such as GPU and graphic-based configurations, userswere logged in every 10 seconds.

l All desktops were started before users logged in.

l All desktops ran an industry-standard anti-virus solution. Windows 10 machines used WindowsDefender.

Profiles and workloadsThe combination of virtual desktop profiles and simulated user workloads determines the totalnumber of users (density) that the VDI solution can support. Specific metrics and capabilitiesdefine each virtual desktop profile and user workload. It is important to understand these terms inthe context of this document.

Profiles and workloads are defined as follows:

l Profile—The configuration of the virtual desktop: the number of vCPUs and the amount ofRAM that is configured on the desktop and available to the user.

l Workload—The set of applications and tasks that are defined to be used by a simulated user inthe PAAC test.

Load-testing on each machine profile uses an appropriate user workload that is representative ofthe relevant use case. It is summarized in the following table:

Table 6 Virtual desktop profile to workload mapping

Profile name Workload name

Knowledge worker Login VSI Knowledge worker

Power worker Login VSI Power worker

Graphics power worker Login VSI Power worker

Graphics multimedia worker Login VSI Multimedia

RDSH task worker Login VSI Task worker

The following table summarizes the Login VSI workloads that were tested in this validation effort.For more information, see Login VSI.

Table 7 Login VSI tested workloads

Workload name Workload description

Login VSIKnowledge worker

Designed for virtual machines with 2 vCPUs. This workload includes the following activities:

l Outlook—Browse messages.

l Internet Explorer—Browse websites and open a YouTube style video (480p movie trailer)three times in every loop.



https://www.loginvsi.com/documentation/index.php?title=Login_VSI_Workloads

Table 7 Login VSI tested workloads (continued)


l Word—Start one instance to measure response time and another to review and edit adocument.

l Doro PDF Printer and Acrobat Reader—Print a Word document and export it to PDF.

l Excel—Open a large randomized sheet.

l PowerPoint—Review and edit a presentation.

l FreeMind—Run a Java-based Mind Mapping application.

l Other—Perform various copy and zip actions.

Login VSI Powerworker

The most intensive of the standard Login VSI workloads. The following activities areperformed with this workload:

l Begin by opening four instances of Internet Explorer and two instances of Adobe Readerthat remain open throughout the workload.

l Perform more PDF printer actions than in the other workloads.

l Watch a 720p and a 1080p video.

l Reduce the idle time to two minutes.

l Perform various copy and zip actions.

Login VSIMultimedia worker(Graphicsperformanceconfiguration)

A workload that is designed to heavily stress the CPU when using software graphicsacceleration. GPU-accelerated computing offloads the most compute-intensive sections ofan application to the GPU while the CPU processes the remaining code. This modifiedworkload uses the following applications for its GPU/CPU-intensive operations:

l Adobe Acrobat

l Google Chrome

l Google Earth

l Microsoft Excel

l HTML5 3D spinning balls

l Internet Explorer

l MP3

l Microsoft Outlook

l Microsoft PowerPoint

l Microsoft Word

l Streaming video

Login VSI TaskWorker

The least intensive of the standard workloads. It runs fewer applications and starts and stopsthem less frequently than the other workloads, resulting in lower CPU, RAM and I/O usage.The Task Worker workload uses the following applications:

l Adobe Reader

l Microsoft Excel

l Internet Explorer

l Microsoft Outlook



Table 7 Login VSI tested workloads (continued)


l Microsoft Word

l Print and zip actions using Notepad and 7-zip



A comparison of linked clones and instant clones

Horizon supports two provisioning methods that deliver space-optimized virtual desktop pools:linked clones and instant clones. For this PAAC testing we used instant clones to create VMs. Theuser density per host is not impacted by using one over the other. The differences in the testgraphs for these two methods are a result of the following processes:

l For linked clones, all the VMs are rebooted before the test starts to simulate a boot storm. TheCPU spike during the boot storm phase is due to the CPU being utilized by all VMs during thepowering on process. When the VMs are booted up, CPU utilization drops to near zero asshown in the following figure. During the login phase CPU utilization again increases and onceall users have logged in CPU utilization remains constant as shown in the steady state phase inthe figure. Once the steady state phase is over and users start to log out, CPU utilizationdecreases. It drops to near zero when all users have logged out.

Figure 2 Host CPU utilization for linked clones

l For instant clones, the VMs are rebooted after the session ends because when a user logs outof the instant clone, the clone is destroyed and re-created for the next user. CPU utilizationgradually increases during the login phase when users start logging in and then remainsconstant during the steady state phase when logins have been completed, as shown in thefollowing figure. When the steady state period is over and users start to log off, CPU utilizationagain decreases and drops to near zero when all users have logged off. After user logoff, theinstant clone pool is re-created. During this phase, there is a CPU spike which then drops tonear zero when pool re-creation is complete.



Figure 3 Host CPU utilization for instant clones

Virtual Desktop Profile

The following table summarizes the profile or Desktop VM configurations for the workloads thatwe tested.

Table 8 Desktop VM specifications

Profile name WorkloadName

vCPUsa Configuredmemoryb

Reservedmemoryc

Screenresolution

Operatingsystem

Knowledgeworker

Login VSIKnowledgeworker

2 4 GB 2 GB 1920 x 1080 Windows 10Enterprise 64-bit

Power worker Login VSIPower worker


GraphicsPower worker

Login VSIPower worker


GraphicsMultimediaworker

Login VSIMultimedia


RDSH Taskworker d

Login VSI Taskworker

8 32 GB 32 GB 1280 x 720 Windows 201664-bit

a. vCPUs—The number of virtual CPUs assigned to the desktop virtual machine.b. Configured memory—Memory that is configured for or assigned to the desktop virtual machine.c. Reserved memory—Amount of memory reserved for the desktop virtual machine. Reserved memory is guaranteed.d. Task worker is tested in a Horizon Apps RDSH (published desktop) environment.

Login VSI test analysis and results

We used the Login VSI test suite to simulate the user experience for several profile types underthe typical workload for that type. We performed the PAAC testing on the 3 x Dell EMC



XC740xd-24 cluster using the Density Optimized configuration, details of which are described inthe following table.

We deployed Horizon and vSphere management roles within the cluster on a single host that alsohosted desktops. This optional configuration is beneficial for Proof of Concepts (POCs) or smalldeployments looking to maximize user density.

We allocated 12 vCPUs and 32 GB of memory to the Nutanix CVM when we configured theNutanix cluster. A Nutanix CVM runs on each node of the Nutanix cluster, enabling the pooling oflocal storage from all nodes in the cluster.

Table 9 Density Optimized configuration

Enterpriseplatform

CPU Memory RAID controller HD configuration Network

XC740xd-24 6248 Gold(20-core 2.5GHz)

768 GB @2933 MT/s

HBA 330 2 x 240 GB M.2

2 x 960 GB SSD

4 x 1.8 TB HDD

2 x MellanoxConnect X-4 LX25 GbE SFP RackNDC

Login VSI test results summary

Before we investigate the detailed analysis for each virtual desktop profile or workload that wastested, let us look at the summary of the results. The following table summarizes the test resultsfor the profiles or workloads.

The table headings are defined as follows:

l Density Optimized—The configuration that was used for this validation effort.

l Profile name—The configuration of the virtual desktop: the number of vCPUs and the amountof RAM that is configured on the desktop and available to the user.

l Workload name—The set of applications and tasks that are defined to be used by a simulateduser. See Table 7 for details of the workloads tested in this PAAC testing.

l User density—The number of users per compute host that successfully completed theworkload test within the acceptable resource limits for the host. For clusters, this numberreflects the average per server density that was achieved for all compute hosts in the cluster.

l Average CPU—The average CPU usage over the steady state period. For clusters, thisnumber represents the combined average CPU usage of all compute hosts. On the latest Intelprocessors, the ESXi host CPU metrics exceed the rated 100 percent for the host if TurboBoost is enabled (the default setting). An additional 35 percent of CPU is available from theTurbo Boost feature. However, this additional CPU headroom is not reflected in the VMwarevSphere metrics where the performance data is gathered. Therefore, CPU usage for ESXihosts is adjusted and each CPU graph includes a line indicating the potential performanceheadroom that Turbo boost provides.

l Average active memory—For ESXi hosts, the amount of memory that is actively used asestimated by the VM kernel based on recently accessed memory pages. For clusters, thismemory is the average amount of guest physical memory that is actively used across allcompute hosts over the steady state period.

l Average IOPS per user—IOPS calculated from the average disk IOPS over the steady stateperiod divided by the number of users.



Table 10 Login VSI test results summary

Serverconfiguration

Profile name Workloadname

Displayprotocol

Userdensityper host

AverageCPU

Averageactivememory

AverageIOPSper user

Density Optimized Knowledge worker Login VSIKnowledgeworker

PCOIP 135 85.96% 170 GB 2.65

Density Optimized Power worker Login VSIPower worker

PCOIP 106 86% 206.74GB

3.07

Density Optimized+ 6x NVIDIA TeslaT4

GraphicsMultimedia worker(Virtual PC: T4:1B)

Login VSIMultimediaworker

BlastExtreme

48 84.92% 428.24GB

4.73

Density Optimized+ 6x NVIDIA TeslaT4

Graphics Powerworker (Virtual PC:T4:1B)

Login VSIPower Worker

BlastExtreme

96 95.57% 425 GB 2.75

Density Optimized RDSH Task worker Login VSITask worker

BlastExtreme

233(HorizonAppsRDSH/PublishedDesktop)

88.87% 129 GB 0.23

Knowledge Worker, 135 users per host, ESXi 6.7, Horizon 7.7The following metrics were collected and analyzed for this test case.

CPU

The graph shows the performance data for 405 user sessions across three compute hosts whentested with a Login VSI knowledge worker workload. Each compute host had approximately 135virtual desktops. We used the PC-over-IP (PCOIP) display protocol for this knowledge workertesting.

During the login phase, CPU utilization increased steadily until all logins were complete. Computehost C recorded a peak CPU utilization of 98.21 percent during the login phase. During the steadystate phase, the CPU utilization reached a steady state average of 85.96 percent across all threecompute hosts. This value is close to the pass/fail threshold we set for average CPU utilization(see Table 5). However, it did not exceed the threshold limit. To maintain a good EUE, it isessential that this threshold is not exceeded. You can load more user sessions while exceeding thisthreshold but this might result in a degradation in user experience.

As shown in the following figure, CPU utilization started decreasing after the steady state phasewhen users began logging out of sessions. CPU utilization reached near zero when all users hadlogged out. CPU utilization spiked during the instant clone re-creation phase after user log out.CPU utilization on compute B reached a peak of 91.4 percent during this phase.



Figure 4 CPU utilization on three hosts in the cluster

Memory

As shown in the following figure, an average consumed memory of 561 GB was recorded beforethe testing started. This was because all VMs were already powered on before the loading of usersessions. Memory consumption remained almost constant during the login phase. During thesteady state phase, consumed memory reached an average of 582 GB across the three hosts.With a total memory of 768 GB available per compute host, memory was not a constraint duringthe testing.

Figure 5 Consumed memory utilization on three hosts in the cluster

Active memory usage increased steadily during the login phase. Each host occupied about 58 GBof active memory during the start of the test. This includes memory used by desktop VMs thatwere powered on before the test and the overhead memory used by the hypervisor. During the



steady state phase, active memory remained almost constant and an average steady activememory of 170 GB was recorded. This implies that during the steady state phase, memory was nota concern and there was enough memory available in the ESXi host cluster to meet requirements.Active memory utilization reduced to a minimum when users logged out of their sessions. Duringthe re-creation of instant clones, a peak average active memory of 502.7 GB was recorded acrossall three hosts. This peak in active memory usage is expected during the instant clone re-creationprocess as all VMs that were destroyed after user log out must be re-created—this is a memoryintensive task. No memory ballooning or swapping occurred on any of the hosts during the testingprocess, indicating no memory constraints in the cluster.

Figure 6 Active memory utilization on three hosts in the cluster

Network usage

Network bandwidth was not an issue during testing. An average network usage of 841.48 Mbpswas recorded across the three compute hosts during the steady state operations. The busiestperiod for network usage was during the re-creating of instant clones after user log out. ComputeB recorded a peak network usage of 2946 Mbps during the re-creation of instant clones. With 2 x25 GbE NICs in an active/active team available as an uplink for hosts, network bandwidth usagewas well below the 85 percent threshold set for network throughput.



Figure 7 Network bandwidth usage on three hosts in the cluster

IOPS

Cluster IOPS reached a peak of 7,956 during the instant clone re-creation process. Averagecluster disk IOPS during the steady state phase was 1073. Based on these numbers, the averagedisk IOPS per session during this phase was 2.65. You can select your disk specifications inaccordance with this IOPS figure in your sizing exercise. As shown in Figure 10, I/O latency duringthe steady state phase was 0.37 ms for the steady state IOPS requirement. The low latency figureindicates that storage was not a bottleneck during steady state operations.

Figure 8 Cluster IOPS utilization



Cluster controller IOPS reached a peak of 40306 during the re-creation of instant clones. Clustercontroller IOPS recorded a steady state average of 4495. These are metrics taken directly fromthe Nutanix Controller VMs and give an indication of backend operations taking place in thestorage system. The IOPS metric also includes cache hits served by the memory.

Figure 9 Cluster controller IOPS utilization

Storage I/O latency

The cluster latency reached a peak of 3.32 ms during the re-creation of instant clones. A peak inlatency was expected due to the creation of the new swap files and difference disks required forthe instant clone VMs—these tasks are disk I/O intensive. Average cluster latency during thesteady state phase was 0.37 ms. This value is well below the pass/fail threshold of 20 ms set forstorage I/O latency. Overall during this testing, storage resources did not appear to be abottleneck.



Figure 10 Cluster latency

Login VSI: User experience summary

The baseline score for the Login VSI test was 853. This score falls in the 800 through 1199 rangerated as "Good" by the Login VSI tool. For more information about Login VSI baseline ratings andbaseline calculations, see this Login VSImax article. The Login VSI test was run for 405 usersessions for the Knowledge worker workload. The blue line in the following figure indicates that thesystem reached a VSImax average score of 1222 when 405 sessions were loaded. This is well belowthe VSI threshold score of 1853 set by the Login VSI tool. VSImax was never reached during theduration of testing, which normally indicates a stable system and a better user experience. SeeTable 11 for an explanation of the Login VSI metrics.

Figure 11 Login VSI summary

We also noted that there were no failed sessions during testing, which indicates that the login andlog out processes were smooth. When manually interacting with the sessions during the steadystate phase, the mouse and window movement was responsive and video playback was good.Moreover, all parameters we monitored were within the pass/fail threshold described in Table 5.This indicates that there were no resource constraints on the system and system performance wasgood.

The following table explains the Login VSI metrics.



https://support.loginvsi.com/hc/en-us/articles/115004421905-VSImax-baseline-scores

Table 11 Login VSI metrics

Login VSI Metrics Description

VSImax VSImax shows the number of sessions that can be active on asystem before the system is saturated. It is the point where theVSImax V4 average graph line meets the VSImax V4 thresholdgraph line. A red X indicates this intersection in the Login VSIgraph. This number gives you an indication of the scalability ofthe environment (higher is better).

VSIbase VSIbase is the best performance of the system during a test(the lowest response times). This number is used to determinewhat the performance threshold will be. VSIbase gives anindication of the base performance of the environment (lower isbetter).

VSImax v4 average VSImax v4 average is calculated based on the number of activeusers that are logged in to the system but removes the twohighest and two lowest samples to provide a more accuratemeasurement.

VSImax v4 threshold VSImax v4 threshold indicates at which point the environment'ssaturation point is reached (based on VSIbase).

The following table shows the Login VSI score summary for the knowledge worker workload.

Table 12 Login VSI score summary for the knowledge worker workload

VSIbase VSImax average VSImax threshold VSImax Reached

853 1222 1853 No

Power Worker, 106 users per host, ESXi 6.7, Horizon 7.7The following metrics were collected and analyzed for this test case.

CPU usage

The following graph shows the performance data for 318 user sessions across three compute hostswhen tested with a power worker workload. Each compute host had 106 virtual desktops. We usedthe PC-over-IP (PCOIP) display protocol for this power worker testing.

During the login phase, CPU utilization increased steadily until all logins were complete. During thesteady state phase, the CPU utilization reached a steady state average of 86 percent across allthree compute hosts. This value is close to the pass/fail threshold we set for average CPUutilization.

However, we found that it did not exceed the threshold limits we set, which includes a 5 percentmargin (see Table 5). To maintain a good EUE, it is essential that this threshold is not exceeded.You can load more user sessions while exceeding this threshold for CPU but this might result in adegradation in user experience. As shown in the following figure, CPU utilization starteddecreasing after the steady state phase when users started logging out of sessions.

CPU utilization reached near zero when all users had been logged out. CPU utilization spikedduring the instant clone re-creation phase after user log out. CPU utilization reached almost 100percent on all hosts during the re-creation of instant clones. Because the turbo feature is enabledon CPUs, this spike is not considered to be an issue. During the re-create clones phase all VMsthat are logged out of are deleted and re-created again. Instant clones are created by forking a



parent VM and the process involves allocating new resources for the child VM. This activity isresource-intensive.


Memory

As shown in the following figure, an average consumed memory of 387.35 GB was recorded beforethe testing started. This was because all VMs were already powered on before the loading of usersessions. Memory consumption remained almost constant during the login phase. During thesteady state phase, consumed memory reached an average of 738.54 GB across the three hosts.With a total memory of 768 GB available per compute host, memory was not a constraint duringthe testing.




Active memory usage increased steadily during the login phase. Each host occupied approximately77 GB of active memory during the start of the test. This includes memory used by desktop VMs,which were powered on before the test and the overhead memory used by the hypervisor. Duringthe steady state phase, active memory remained almost constant and an average steady activememory of 206.74 GB was recorded. This indicates that memory was not a concern during thesteady state phase and there was enough memory available in the ESXi host cluster to meetrequirements. Active memory utilization was reduced to a minimum when users logged out of theirsessions. During the re-creation of instant clones, a peak average active memory of 802.71 GB wasrecorded across all three hosts. This peak in active memory usage is expected during the instantclone re-creation process. During this process, all VMs that had been destroyed after users loggedoff have to be re-created, which is a memory intensive task. No memory ballooning or swappingoccurred on any of the hosts during the testing process, indicating no memory constraints in thecluster.


Network usage

Network bandwidth was not an issue during testing. An average network usage of 1031.61 Mbpswas recorded across the three compute hosts during the steady state operations. The busiestperiod for network usage was during the recreating of instant clones after users logged out.Compute A recorded a peak network usage of 3668.65 Mbps during the re-creation of instantclones. With two 25 GbE NICs in an active/active team available as an uplink for hosts, networkbandwidth usage was well under the 85 percent threshold set for network throughput.




IOPS

Cluster IOPS reached a peak of 12,522 during the instant clone re-creation process. Averagecluster disk IOPS during the steady state phase was 976. Based on these numbers, the averagedisk IOPS per session during the steady state phase was 3.07. You can select your diskspecifications in accordance with this IOPS figure in your sizing exercise. As shown in the followingfigure, I/O latency during the steady state phase was 0.37 ms for the steady state IOPSrequirement. The low latency figure indicates that during steady state operations, storageresources were not a bottleneck.


Cluster controller IOPS reached a peak of 38409 during the re-creation of instant clones. Clustercontroller IOPS recorded a steady state average of 4490. These metrics collected from the



Nutanix Controller VMs give an indication of backend operations taking place in the storagesystem. This IOPS metric also includes cache hits served by the memory.


Storage I/O latency

The cluster latency reached a peak of 3.38 ms during the re-creation of instant clones. A peak inlatency was expected due to the creation of the new swap files and difference disks required forthe instant clone VMs. These tasks are disk I/O intensive. Average cluster latency during thesteady state phase was 0.4 ms, a value well below the pass/fail threshold of 20 ms set for storageI/O latency. Overall during this testing, storage resources did not appear to be a bottleneck.





The baseline score for the Login VSI test was 776. This score falls in the range 0-779 rated as"Very Good" by the Login VSI tool. For more information about Login VSI baseline ratings andcalculations, see this Login VSImax article. The Login VSI test was run for 318 user sessions for thepower worker workload. The blue line in the following figure indicates that the system reached aVSImax average score of 1149 when 318 sessions were loaded. This is well below the VSI thresholdscore of 1776 set by the Login VSI tool. During the duration of testing VSImax was never reached,which normally indicates a stable system and a better user experience. See Table 11 for anexplanation of the Login VSI metrics.

Figure 19 Login VSI graph summary

We also noted that there was only one failed session during testing, which indicates that the loginand log out processes were smooth. When manually interacting with the sessions during thesteady state phase, the mouse and window movement was responsive and video playback wasgood. Moreover, all parameters we monitored were within the pass/fail threshold set as shown inthe following table. This indicates that there were no resource constraints on the system and thesystem performance was good.

The following table shows the Login VSI score summary for the power worker workload.

Table 13 Login VSI score summary for the power worker workload

Login VSIbase VSImax Average VSImax Threshold VSImax Reached

776 1149 1776 No

Graphics Multimedia worker, 48 vGPU users per host, ESXi 6.7, Horizon 7.7In this multimedia workload test, one of the nodes in the cluster was enabled with 48 vGPU profilesand loaded with sessions. The other two nodes in the cluster did not host any compute VMs. Weused the VMware Horizon Blast Extreme protocol for this graphics multimedia worker testing. Thefollowing metrics were collected and analyzed for this test case.




CPU usage

The GPU-enabled compute host in the cluster was populated with 48 vGPU-enabled VMs and usedthe NVIDIA Tesla T4-1B profile. With all user VMs powered on before starting the test, the CPUusage was approximately 10 percent on the GPU-enabled compute host.

The following figure shows the CPU utilization metric data for 48 user sessions on the GPU-enabled compute host. During the login phase, CPU utilization increased steadily until all loginswere complete. During the steady state phase, the CPU utilization reached a steady state averageof 84.92 percent across all three compute hosts. This value is close to the pass/fail threshold weset for average CPU utilization (see Table 5). However, it did not exceed the threshold limits weset. To maintain a good EUE it is essential that this threshold is not exceeded. You can load moreuser sessions while exceeding this threshold for CPU utilization but might experience adegradation in user experience. As shown in Figure 20, CPU utilization started decreasing after thesteady state phase when users started logging out of sessions. CPU utilization reached near zerowhen all users had logged out. There was no spike in CPU utilization during the re-creation ofinstant clones.

User density is also limited by the frame-buffer of GPUs. Forty-eight users with 2 GB vGPU framebuffer profiles occupy the total 96 GB frame buffer that is provided by six NVIDIA Tesla T4 GPUson a server node.

Figure 20 CPU utilization on GPU host

GPU usage

We gathered the GPU metrics from the vSphere Web Client. Six NVIDIA Tesla T4 GPUs wereconfigured on the GPU-enabled host. The GPU usage during the steady state phase across the sixGPUs averaged approximately 31.97 percent. The GPU A had a spike of 54.66 percent of CPUutilization. GPUs were used for executing graphics-intensive tasks, thus taking load off CPUs andproviding a better user experience.



Figure 21 GPU utilization of GPU host

Memory

As shown in the following figure, an active memory of 436 GB was recorded before the teststarted. This was because all VMs were already powered on before user sessions were loaded.Active memory remained constant during the login phase. With GPU enabled in the host we notedactive memory usage during the start of the test increased when compared to a test with a non-GPU host. During the steady state phase, active memory remained almost constant and recordedan average steady state active memory of 428.24 GB. This indicates that memory was not aconcern during the steady state phase and there was enough memory available in the ESXi hostcluster to meet requirements. Active memory utilization was reduced when users logged off fromtheir sessions. During the re-creation of instant clones, memory again remained constant around428 GB. No memory ballooning or swapping occurred on any of the hosts during the testingprocess, indicating no memory constraints in the cluster.



Figure 22 Active memory utilization on GPU host

As shown in the following figure, a consumed memory of 453.86 GB was recorded before thetesting started. This was because all VMs were already powered on before the loading of usersessions. Memory consumption remained almost constant during the login phase. During thesteady state phase, consumed memory reached an average of 445.82 GB on the GPU-enabledhost. With a total memory of 768 GB available per compute host, memory was not a constraintduring the testing.

Figure 23 Consumed memory utilization on GPU host

Network usage

Network bandwidth was not an issue during testing. The GPU host recorded an average networkusage of 981.23 Mbps. The busiest period for network usage was during the logging out phase. The



host recorded peak network usage of 1335.3 Mbps. With two 25 GbE NICs in an active/activeteam available as an uplink for hosts, network bandwidth usage was well under the 85 percentthreshold set for network throughput.

Figure 24 Network bandwidth usage on GPU host

IOPS

The cluster reached a maximum of 7,504 disk IOPS during the logging out phase and averaged227.31 IOPS during the steady state phase. Based on these numbers, each user session generated4.73 disk IOPS during the steady state phase. You can select your disk specifications inaccordance with this IOPS figure in your sizing exercise. As shown in Figure 28, I/O latency duringthe steady state phase was 0.45 ms for the steady state IOPS requirement. The low latency figureindicates that storage resources were not a bottleneck during steady state operations.




Cluster controller IOPS reached a peak of 21,192 disk IOPS during the logging out phase. Clustercontroller IOPS recorded a steady state average of 6,480.78. These are metrics gathered directlyfrom Nutanix Controller VMs and give an indication of backend operations taking place in thestorage system. These IOPS metrics also include cache hits served by the memory.

Figure 26 Cluster Controller IOPS utilization

GPU host disk IOPS

The GPU host reached a maximum of 2755 disk IOPS during the logging out phase and averaged165 disk IOPS during the steady state phase. Based on these numbers, each user sessiongenerated 3.43 IOPS in the steady state phase.



Figure 27 GPU host disk IOPS utilization

Storage I/O latency

The cluster latency reached a peak of 1.81 ms during the re-creation of instant clones. A peak inlatency was expected due to the creation of new swap files and difference disks required for theinstant clone VMs. These tasks are disk I/O intensive. Average cluster latency during the steadystate phase was 0.45 ms. This value is well below the pass/fail threshold of 20 ms set for storageI/O latency. Overall during this testing, storage resources did not appear to be a bottleneck.

Figure 28 Cluster Latency

The GPU host latency reached a maximum of 1.57 ms during the boot storm and averaged 0.42 msduring the steady state phase.



Figure 29 GPU host latency

Login VSI: User Experience Summary

The following figures show that the user experience score did not reach the Login VSI maximumfor this test. When manually interacting with the sessions during the steady state phase, themouse and window movement was responsive and video playback was good. The baselineperformance of 1088 indicates that the user experience for this test run was good. The Indexaverage reached 1473, which was well below the threshold of 2088.

The baseline score for the Login VSI test was 1088. This score falls in the 800 through 1199 rangerated as "Good" by the Login VSI tool. For more information about Login VSI baseline ratings andcalculations, see this Login VSImax article. The Login VSI test was run for 48 user sessions for themultimedia workload. The blue line in the following figure indicates that the system reached aVSImax average score of 1473 when 48 sessions were loaded. This is well below the VSI thresholdscore of 2088 set by the Login VSI tool. VSImax was never reached during the duration of the test,which normally indicates a stable system and a better user experience. See Table 11 for anexplanation of the Login VSI metrics.





We also noted that there were no failed sessions during testing. This indicates that the login andlogging out processes were smooth. When manually interacting with the sessions during thesteady state phase, the mouse and window movement was responsive and video playback wasgood. Moreover, all the parameters we monitored were within the pass/fail threshold set out inTable 5. This indicates that there were no resource constraints on the system and systemperformance was good.

The following table shows the Login VSI score summary for the graphics multimedia workerworkload.

Table 14 Login VSI score summary for the graphics multimedia worker workload

VSIbase VSImax average VSImax threshold VSImax reached

1088 1473 2088 No

Graphics Power Worker, 96 vGPU users per host, ESXi 6.7, Horizon 7.7In this graphics power worker test, one of the nodes in the cluster was GPU enabled. The host wasconfigured with 96 vGPU profiles and loaded with sessions. The other two nodes in the cluster didnot host any compute VMs. We used the VMware Horizon Blast Extreme protocol for the testing.The following metrics were collected and analyzed.

CPU usage

The GPU-enabled compute host in the cluster was populated with 96 vGPU-enabled VMs and usedthe NVIDIA Tesla T4-1B profile. With all user VMs powered on before starting the test, the CPUusage was approximately 15 percent on the GPU-enabled compute host.



The following figure shows the CPU utilization metric data for 96 user sessions on the GPU-enabled compute host in the cluster. During the login phase, CPU utilization increased steadily untilall logins were complete. The CPU reached a steady state average of 95.57 percent during the testcycle when all users were logged in to the GPU-enabled compute host. Our standard threshold of85 percent for average CPU utilization was relaxed for this testing to demonstrate theperformance when graphics resources are fully utilized (96 profiles per host). You might get abetter user experience by managing CPU at a threshold of 85 percent, by decreasing user density,or by using a higher-binned CPU.

Figure 31 CPU utilization on GPU host

GPU usage

We gathered the GPU metrics from the vSphere Web Client. Six NVIDIA Tesla T4 GPUs wereconfigured on the GPU-enabled host. The GPU usage during the steady state phase across the sixGPUs averaged approximately 34 percent. The GPUs were used for executing graphics-intensivetasks in the power workload, thus taking a load off CPUs and providing a better user experiencefor graphics-intensive tasks.



Figure 32 GPU utilization on GPU host

Memory

As shown in the following figure, an active memory of 424.72 GB was recorded before the teststarted. This was because all VMs were already powered on before the loading of user sessions.Active memory remained constant during the login phase. With GPU enabled in the host, we notedactive memory usage during the start of the test increased when compared to a test where GPUswere not used. During the steady state phase, active memory remained almost constant andrecorded an average steady active memory of 425 GB. This indicates that memory was not aconcern during the steady state phase and there was enough memory available in the ESXi hostcluster to meet requirements. Active memory utilization reduced when users logged out of theirsessions and it reached around 59 GB for the GPU host. During the re-creation of instant clones,memory again remained constant at around 424 GB. No memory ballooning or swapping occurredon any of the hosts during the testing process, indicating no memory constraints in the cluster.



Figure 33 Active memory utilization on GPU host

As shown in the following figure, a consumed memory of 450.24 GB was recorded before thetesting started. This was because all VMs were already powered on before the loading of usersessions. Memory consumption remained almost constant during the login phase. During thesteady state phase, consumed memory reached an average of 450.35 GB on the GPU-enabledhost. With a total memory of 768 GB available per compute host, memory was not a constraintduring the testing.

Figure 34 Consumed memory utilization on GPU host



Network usage

Network bandwidth was not an issue during testing. An average network usage of 654.42 Mbpswas recorded on the GPU host. The busiest period for network usage was during the re-creation ofinstant clones phase. The host recorded peak network usage of 1,326.37 Mbps. With two 25 GbENICs in an active/active team available as an uplink for hosts, network bandwidth usage was wellunder the 85 percent threshold set for network throughput.

Figure 35 Network bandwidth utilization on GPU host

IOPS

The cluster reached a maximum of 2,262 disk IOPS during the logging out phase and averaged264.47 IOPS during the steady state phase. Based on these numbers, each user session generated2.75 disk IOPS during the steady state phase. You can select your disk specifications inaccordance with this IOPS figure in your sizing exercise. As shown in Figure 36, I/O latency duringthe steady state phase was 0.45 ms for the steady state IOPS requirement. The low latency figureindicates that storage resources were not a bottleneck during steady state operations .




Cluster controller IOPS reached a peak of 16,382 disk IOPS during the logging out phase. Clustercontroller IOPS recorded a steady state average of 1,354. These are metrics taken directly fromNutanix Controller VMs and give an indication of backend operations taking place in the storagesystem. These IOPS metrics also include cache hits served by the memory.




GPU host disk IOPS

The GPU host reached a maximum of 2210 disk IOPS during the logging out phase and averaged227.28 disk IOPS during the steady state phase. Based on these numbers, each user sessiongenerated 5.5 IOPS in the steady state phase. You can select your disk specifications inaccordance with this IOPS figure in your sizing exercise.

Figure 38 Graphics host disk IOPS utilization



Storage I/O latency

The cluster latency reached a peak of 1.9 ms during the re-creation of instant clones. A peak inlatency was expected due to the creation of the new swap files and difference disks required forthe instant clone VMs. These tasks are disk I/O intensive. Average cluster latency during thesteady state phase was 0.45 ms. This value is well below the pass/fail threshold of 20 ms set forstorage I/O latency. Overall during this testing, storage resources did not appear to be abottleneck.


The GPU host latency reached a maximum of 2.83 ms during the re-creation of instant clones andaveraged 0.38 ms during the steady state phase.



Figure 40 GPU host latency

Login VSI: User experience

The baseline score for the Login VSI test was 1153. This score falls in the 800 through 1199 rangerated as "Good" by the Login VSI tool. For more information about Login VSI baseline ratings andcalculations, see this Login VSImax article. The Login VSI test was run for 48 user sessions for themultimedia workload. The blue line in the following figure indicates that the system reached aVSImax average score of 1153 when 96 sessions were loaded. This is well below the VSI thresholdscore of 2041 set by the Login VSI tool. VSImax was never reached during the duration of testing,which normally indicates a stable system and a better user experience. See Table 11 for anexplanation of the Login VSI metrics.





We also noted that there were no failed sessions during testing. This indicates that the login andlogging out processes were smooth. When manually interacting with the sessions during thesteady state phase, the mouse and window movement was responsive and video playback wasgood. Moreover, all parameters we monitored were within the pass/fail threshold set out in Table5. This indicates there were no resource constraints on the system and system performance wasgood.

The following table shows the Login VSI score summary for the graphics power worker workload.

Table 15 Login VSI score summary for the graphics power worker workload

VSIbase VSImax average VSImax threshold VSImax reached

1153 2041 2153 No

RDSH Task Worker, 233 users per host, ESXi 6.7, Horizon 7.7The following metrics were collected and analyzed for this test case.

CPU

The following figure shows the performance data for 700 Remote Desktop Session Host (RDSH)user sessions across three compute hosts in a Nutanix cluster. The test was carried out with aLogin VSI task worker workload. Each compute host in the cluster was provisioned with six RDSHVMs, which were installed with the Windows 2016 Server operating system. We used the VMwareBlast Extreme display protocol for this testing.

During the login phase, CPU utilization increased steadily until all logons were complete. During thesteady state phase, the CPU utilization reached a steady state average of 88.87 percent across allthree compute hosts. This value is close to the pass/fail threshold we set for average CPU



utilization (see Table 5). However, it did not exceed the threshold limit, which includes a 5 percentmargin. To maintain a good EUE it is essential that this threshold is not exceeded. You can loadmore user sessions while exceeding this threshold for CPU but this might result in a degradation ofthe user experience.

CPU utilization started decreasing after the steady state phase when users began logging off fromsessions. CPU utilization reached near zero when all users had logged out.


Memory

As shown in the following figure, an average consumed memory of 185 GB was recorded beforethe testing started. This was because all VMs were already powered on before the loading of usersessions. Memory consumption remained almost constant during the logon phase. During thesteady state phase, consumed memory reached an average of 190 GB across the three hosts.Memory was not a constraint during the testing.




Active memory usage increased steadily during the logon phase. Around 68 GB of active memorywas occupied by each host during the start of the test. This includes memory used by server VMswhich were powered on before the test and the overhead memory used by the hypervisor. Duringthe steady state phase an average active memory of 129 GB was recorded. This indicates thatduring the steady state phase, memory was not a concern and there was enough memory availablein the cluster to meet requirements. Active memory utilization decreased to a minimum when userslogged off from their sessions.


Network usage

Network bandwidth was not an issue during testing. An average network usage of 850 Mbps wasrecorded across the three compute hosts during the steady state operations. The busiest periodfor network usage was during the logoff phase. Peak network usage of 1,402 Mbps was recorded



by compute B during this phase. With two 25 GbE NICs configured as an uplink in an active/activeteam, network bandwidth usage was well under the 85 percent threshold set for networkthroughput.


IOPS

Cluster IOPS reached a peak of 1,478 during the logoff phase. Average cluster disk IOPS duringthe steady state phase was 167 and peak IOPS recorded during this phase was 350. Based onthese numbers, the average disk IOPS per session during the steady state phase was 0.23 IOPS.You can select your disk specifications in accordance with this IOPS figure in your sizing exercise.As shown in Figure 47, I/O latency during the steady state phase was 0.43 ms for the steady stateIOPS requirement. The low latency figure indicates that storage was not a bottleneck duringsteady state operations.




Cluster controller IOPS reached a peak of 25,172 during the re-creation of instant clones. Clustercontroller IOPS recorded a steady state average of 4,899. These metrics were taken directly fromthe Nutanix Controller VMs and give an indication of backend operations taking place in thestorage system. The IOPS metric also includes cache hits served by the memory.

Figure 47 Cluster Controller IOPS utilization

Storage I/O latency

The cluster latency reached a peak of 1.7 ms during the steady state phase. Average clusterlatency during the steady state phase was 0.43 ms. This value is well below the pass/fail thresholdof 20 ms set for storage I/O latency. Overall during this testing, storage resources did not seem tobe a bottleneck.





The baseline score for the Login VSI test was 643. This score falls in the 0 through 799 range ratedas "Very Good" by the Login VSI tool. For more information about Login VSI baseline ratings andcalculations, see this Login VSImax article. The Login VSI test was run for 700 user sessions forthe task worker workload. The blue line in the following figure indicates that the system reached aVSImax average score of 1114 when 700 sessions were loaded. This is well below the VSI thresholdscore of 1643 set by the Login VSI tool. VSImax was never reached during the duration of testing,which normally indicates a stable system and a better user experience. See Table 11 for anexplanation of the Login VSI metrics.

Figure 49 Login VSI summary

We noted that there were only seven failed sessions during testing which is below the 2 percentthreshold we set for failed sessions. When manually interacting with the sessions during the steadystate phase, the mouse and window movement was responsive and video playback was good.Moreover, all of the parameters we monitored were within the pass/fail threshold set out in Table5. This indicates there were no resource constraints on the system and system performance wasgood.

The following table shows the Login VSI score summary for the RDSH task worker workload.

Table 16 Login VSI score summary for the RDSH task worker workload

VSIbase VSImax average VSImax threshold VSImax Reached

643 1114 1643 No




CHAPTER 4

Conclusion

l Test results and density recommendations........................................................................... 60l Summary...............................................................................................................................60


Test results and density recommendations

The recommended user densities for this testing are shown in the following table. The userdensities were achieved by following Nutanix best practices with Redundancy Factor 2 and Cachededuplication enabled. All configurations were tested with Microsoft Windows 10 and MicrosoftOffice 2016. We implemented all mitigations to patch the Spectre, Meltdown and L1TFvulnerabilities at the hardware, firmware, and software levels to ensure an improved performanceimpact, which is reflected in the achieved user densities.

Table 17 User density recommendations for VMware vSphere ESXi 6.7 with VMware Horizon

Server configuration Profile name Workload name User density

Density Optimized Knowledge worker Login VSI Knowledgeworker

135

Density Optimized Power worker Login VSI Power worker 106

Density Optimized + 6xNVIDIA Tesla T4

Graphics Multimediaworker (Virtual PC: T4-1B)

Login VSI Multimediaworker

48

Density Optimized + 6xNVIDIA Tesla T4

Graphics Power worker(Virtual PC: T4-1B)

Login VSI Power worker 96 a

Density Optimized RDSH Task worker Login VSI Task worker 233 (Horizon Apps RDSH/Published Desktop)

a. The user density of 96 users was achieved at 95% CPU utilization. The CPU utilization threshold of 85% is relaxedwhen testing with graphics cards. This test represents maximum utilization of the graphical resources available tothe system as well as full user concurrency. Ideally, in a production environment, you would decrease the userdensity slightly or use higher bin processors to bring the CPU utilization closer to the 85% threshold. All LoginVSItests completed successfully without reaching VSI maximum, indicating that user experience was good.

All Login VSI tests were completed successfully without reaching the Login VSI maximum,indicating that the user experience was good. Except for the Graphics Power worker profile, themetrics for all other workloads were well within the thresholds that we set. You can get better userdensities by increasing the thresholds that we set—however, there might be a degradation in userexperience.

For additional resources on this topic, see the VMware documentation section.

Summary

The configurations for the XC Family devices—the XC740xd-24 and the XC640-10—areoptimized for performance intensive VDI workloads. We selected the memory and CPUconfigurations that provides optimal performance. You can change these configurations to meetyour own requirements. Keep in mind that changing the memory and CPU configurations fromthose that have been validated in this document will affect the user density per host.

In the Density Optimized configuration used in this testing we leveraged 2nd Generation Intel XeonScalable processors (Cascade Lake) which have in-hardware mitigations for Spectre (variant 2),Meltdown (variant 3), and L1 Terminal Fault side-channel methods. With mitigations in thehardware, the new processors provide better performance and user densities than first-generationIntel Xeon Scalable Processors (Skylake) or other previous generation processor-based VDIsystems, which still require software-level fixes to protect against side-channel vulnerabilities.Vulnerabilities for which fixes are not available at hardware-level are mitigated through software-

Conclusion


level fixes. Cascade Lake processors also come with an improved architecture and higher thermalefficiency that boosts the performance of the VDI system.

With the introduction of the six-channels-per-CPU requirement for Skylake and Cascade Lake, theserver memory configuration recommendation has increased from the previous guidance of 512 GBto 768 GB. This change was necessary to ensure a balanced memory configuration and optimizedperformance for your VDI solution. The additional memory is advantageous, considering theresulting increase in operating system resource utilization and the enhanced experience for userswhen they have access to additional memory allocations.

Conclusion


Conclusion


CHAPTER 5

References


l Dell EMC documentation.......................................................................................................64l VMware documentation........................................................................................................ 64l NVIDIA documentation.......................................................................................................... 64


Dell EMC documentationThe following Dell EMC documentation provides additional and relevant information. Access tothese documents depends on your login credentials. If you do not have access to a document,contact your Dell EMC representative. Also see the VDI Info Hub for Ready Solutions for acomplete list of VDI resources.

l Dell EMC Virtual Desktop Infrastructure

l Dell EMC XC Series and XC Core Technical Resource Center

This document is part of the documentation set for this architecture, which includes the following:

l Dell EMC Ready Architectures for VDI: Designs for VMware Horizon on XC Family DesignGuide

l Dell EMC Ready Architectures for VDI: Designs for VMware Horizon on XC Family DeploymentGuide

l Dell EMC Ready Architectures for VDI: Designs for VMware Horizon on XC Family ValidationGuide

VMware documentationThe following VMware documentation provides additional and relevant information:

l VMware vSphere documentation

l VMware Horizon 7 documentation

l VMware Compatibility Guide

l Horizon 7 Enterprise Edition Reference Architecture

l Horizon 7 Enterprise Edition Multi-Site Reference Architecture

For additional information about advanced architectural considerations (for example, NUMA-related topics):

l Best Practices for Published Applications and Desktops in VMware Horizon Apps and VMwareHorizon 7

NVIDIA documentation

The following NVIDIA documentation provides additional and relevant information:

l NVIDIA Virtual GPU Software Quick Start Guide

References


https://infohub.delltechnologies.com/t/solutions/vdi/

https://www.dellemc.com/en-us/solutions/vdi/index.htm

https://www.dellemc.com/en-us/converged-infrastructure/xcseries/technical-resources.htm

http://www.dellemc.com/en-us/collaterals/unauth/technical-guides-support-information/solutions/h17385-xc-horizon-design-guide.pdf

http://www.dellemc.com/en-us/collaterals/unauth/technical-guides-support-information/solutions/h17385-xc-horizon-design-guide.pdf

http://www.dellemc.com/en-us/collaterals/unauth/technical-guides-support-information/solutions/h17387-xc-horizon-deployment-guide.pdf

http://www.dellemc.com/en-us/collaterals/unauth/technical-guides-support-information/solutions/h17387-xc-horizon-deployment-guide.pdf

http://www.dellemc.com/en-us/collaterals/unauth/technical-guides-support-information/solutions/h17386-xc-horizon-validation-guide.pdf

http://www.dellemc.com/en-us/collaterals/unauth/technical-guides-support-information/solutions/h17386-xc-horizon-validation-guide.pdf

https://docs.vmware.com/en/VMware-vSphere/index.html

https://docs.vmware.com/en/VMware-Horizon-7/index.html

https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan&details=1&vsan_type=vsanreadynode&vsan_partner=23&vsan_releases=278&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc

https://techzone.vmware.com/resource/workspace-one-and-horizon-reference-architecture#component-design-horizon-architecture

https://techzone.vmware.com/resource/workspace-one-and-horizon-reference-architecture#multi-site-architecture

https://techzone.vmware.com/resource/best-practices-published-applications-and-desktops-vmware-horizon-apps-and-vmware-horizon-7

https://techzone.vmware.com/resource/best-practices-published-applications-and-desktops-vmware-horizon-apps-and-vmware-horizon-7

http://docs.nvidia.com/grid/latest/grid-software-quick-start-guide/index.html

Date post:	20-May-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Dell EMC Ready Architectures for VDI Designs for VMware ... · negative impact on your total cost...

Documents