XenApp and XenDesktop 7.12 on vsan 6.5 All-Flash January 08, 2018 1
Table of Contents 1. Executive Summary 1.1.Business Case 1.2.Key Results 2. Introduction 2.1.Scope 2.2.Audience 3. Technology Overview 3.1.VMware vsphere 6.5 3.2.VMware vsan 6.5 3.3.Citrix XenApp and XenDesktop 7.12 3.4.Citrix Provisioning Services 3.5.Citrix Machine Creation Services 3.6.VMware App Volumes 2.11 4. Solution Configuration 4.1.Architecture Diagram 4.2.Hardware Resources 4.3.Software Resources 4.4.Virtual Machine Test Image Build 4.5.Network Configuration 4.6.vSAN Configuration 4.7.VMware Cluster Configuration 4.8.VMware ESXi Server: Storage Controller Mode 4.9.Desktop Provisioning Mechanism 5. Solution Validation 5.1.Testing Overview 5.2.Testing Tools 5.3.PVS XenDesktop with Natively Installed Application 5.4.MCS XenDesktop with AppStack 5.5.PVS XenApp with Windows Server 5.6.MCS XenApp with Windows Server 6. Best Practices 6.1.AppStack Storage Policy 6.2.vSAN Sizing 7. Recommendation 7.1.Recommendation 8. Conclusion 8.1.Conclusion 9. Reference 9.1.Reference 10. About the Author 10.1.Author 2
1. Executive Summary This is the executive summary of the solution RA. 3
1.1 Business Case Business Case Customers today wanting to deploy a virtual desktop infrastructure on all-flash require a costeffective, highly scalable, and an easy-to-manage solution. Applications need to be refreshed and published at will and should not require multiple levels of IT administration. Most importantly, the infrastructure itself must be able to scale with minimal cost impact yet still provide enterprise-class performance. All-flash storage products have traditionally been regarded as too expensive. VMware vsan changes this by supporting all-flash configurations with extreme performance and radically simple management at a cost that is lower than many competing solutions. This solution demonstrates the performance of virtual desktops enabled by vsan 6.5 all-flash with Citrix XenApp and XenDesktop 7.12, and VMware vsphere 6.5. Through extensive tests, we provide an optimal configuration for virtual desktop infrastructure (VDI) deployments including various provisioning methods. Using Login VSI, we validate the performance to ensure the optimal configuration. 1.2 Key Results Key Results VSImax v4.1: Not reached Login Virtual Session Indexer (Login VSI) Knowledge Worker workload 1,000* PVS XenDesktops, 100 percent concurrency VSImax v4.1: Not reached Login Virtual Session Indexer (Login VSI) Knowledge Worker workload 1,000* MCS Desktops with VMware App Volumes, 100 percent concurrency VSImax v4.1: Not reached Login Virtual Session Indexer (Login VSI) Knowledge Worker workload 1,000* sessions PVS XenApp, 100 percent concurrency VSImax v4.1: Not reached Login VSI Knowledge Worker workload 1,000* sessions MCS XenApp, 100 percent concurrency Outstanding Performance with Substantial Space Saving Up to 80 percent space saving by vsan deduplication and compression, erasure coding. Excellent user experience characteristics, even with diverse use cases and burst-heavy workloads 4
Real-time Application Delivery and Management Provision, deliver, update, and retire applications in real time at scale Dynamically attach applications to users, groups, or devices Ease of VDI management Simplified storage configuration and provisioning Tight integration with other vsphere features (high availability, VMware vsphere Distributed Resource Scheduler, and others) * Workloads push the limits of cost-effective hardware, particularly CPUs 5
2. Introduction This document is the reference architecture of VDI deployments, which is enabled by vsan 6.5 allflash, Citrix XenApp and XenDesktop 7.12, and VMware vsphere 6.5. 6
2.1 Scope Scope This reference architecture: Demonstrates the storage performance of VDI deployments using vsan 6.5 all-flash with Citrix XenApp and XenDesktop. Proves that vsan with space efficiency features enabled can easily support sustainable workloads with minimal resource overhead and impact on desktop application performance. Validates that Citrix XenApp and XenDesktop 7.12 with App Volumes 2.11 works well with vsan to manage desktops and applications. 2.2 Audience Audience This reference architecture is intended for customers IT architects, consultants, and administrators involved in the early phases of planning, design, and deployment of VDI solutions running on all-flash vsan. It is assumed that the reader is familiar with the concepts and operations of Citrix XenApp and XenDesktop technologies and VMware vsphere products. 7
3. Technology Overview This section provides an overview of the technologies that are used in this solution. 8
3.1 VMware vsphere 6.5 VMware vsphere 6.5 VMware vsphere is the industry-leading virtualization platform for building cloud infrastructures. It enables users to run business-critical applications with confidence and respond quickly to business needs. vsphere accelerates the shift to cloud computing for existing data centers and underpins compatible public cloud offerings, forming the foundation for the industry s best cloud model. VMware vsphere 6.5 accelerates customer transition to digital transformation and cloud computing by addressing key challenges: Environments growing increasingly complex Growing IT security threads The need to support both existing and new applications and services 3.2 VMware vsan 6.5 VMware vsan 6.5 VMware vsan is VMware s software-defined storage solution for hyper-converged infrastructure, a software-driven architecture that delivers tightly integrated compute, networking, and shared storage from virtualized x86 servers. vsan 6.5 delivers new capabilities that further help customers respond faster to dynamic business needs across a broader set of workloads while lowering total cost of ownership of your IT infrastructure. The most significant new capabilities and updates include: License required: support all-flash in all vsan editions providing greater choice and flexibility to deploy all-flash solutions for any workload. 2-node direct connect: minimize the upfront cost of deployment in remote sites by directly connecting two vsphere servers together using simple crossover cables. Full-featured PowerCLI: improve automation with a complete set of PowerCLI cmdlets. All-Flash Architecture All-flash vsan aims at delivering extremely high IOPS with predictable low latencies. In an all-flash architecture, two different grades of flash devices are commonly used: lower capacity and higher endurance devices for the cache layer; more cost-effective, higher capacity, and lower endurance devices for the capacity layer. Writes are performed at the cache layer and then destaged to the capacity layer, only as needed. This helps extend the usable life of lower endurance flash devices in the capacity layer and lower the overall cost of the solution. 9
Figure 1. vsan All-Flash Datastore Deduplication and Compression Near-line deduplication and compression happens during destaging from the caching tier to the capacity tier. Deduplication and compression is a cluster-wide setting that is disabled by default and can be enabled using a simple drop-down menu. The deduplication algorithm utilizes a 4K-fixed block size and is performed within each disk group. In other words, redundant copies of a block within the same disk group are reduced to one copy, but redundant blocks across multiple disk groups are not deduplicated. Bigger disk groups might result in a higher deduplication ratio. The blocks are compressed after they are deduplicated. 10
Figure 2. Deduplication for Space Efficiency Erasure Coding Erasure coding provides the same levels of redundancy as mirroring, but with a reduced capacity requirement. In general, erasure coding is a method of taking data, breaking it into multiple pieces and spreading it across multiple devices, while adding parity data so it may be recreated in the event that one or more pieces are corrupted or lost. In vsan, two modes of erasure coding are supported: RAID 5 in 3+1 configuration, which means 3 data blocks and 1 parity block per stripe. RAID 6 in 4+2 configuration, which means 4 data blocks and 2 parity blocks per stripe. RAID 5 In this case, RAID 5 requires four hosts at a minimum because it uses a 3+1 logic. With four hosts, one can fail without data loss. This results in a significant reduction of required disk capacity. Normally, a 20GB disk would require 40GB of disk capacity in a mirrored protection, but in the case of RAID 5, the requirement is only around 27GB. 11
Figure 3. RAID 5 Data and Parity Placement RAID 6 With RAID 6, two host failures can be tolerated the same as RAID 1 protection. In the RAID 1 scenario for a 20GB disk, the required disk capacity would be 60GB. However, the required disk capacity is 30 GB with RAID 6. Note that the parity is distributed across all hosts and there is no dedicated parity host. A 4+2 configuration is used in RAID 6, which means that at least six hosts are required in this configuration. Figure 4. RAID 6 Data and Parity Placement Space efficiency features (including deduplication, compression, and erasure coding) work together to provide up to 10x reduction in dataset size. Client Cache vsan has a small in-memory read cache. Small in this case means 0.4 percent of a host s memory capacity up to a max of 1GB. Note that this in-memory cache is a client side cache, meaning that the blocks of a VM are cached on the host where the VM is located. This feature is enabled by default. 3.3 Citrix XenApp and XenDesktop 7.12 Citrix XenApp and XenDesktop 7.12 Citrix provides a complete virtual app and desktop solution to meet customers needs from a single, easy-to-deploy platform. Citrix XenApp and XenDesktop 7.12 integrates Citrix XenApp application delivery technologies and XenDesktop desktop virtualization technologies into a single architecture 12
and management experience. This new architecture unifies both management and delivery components to enable a scalable, simple, efficient, and manageable solution for delivering Windows applications and desktops as secure mobile services to users anywhere on any device. Figure 5. XenDesktop 7.12 Architecture Components The XenDesktop 7.12 architecture includes the following components: Citrix Director Director is a web-based tool that enables IT support and helps desk teams to monitor an environment, troubleshoot issues before they become system-critical, and performs support tasks for end users. Citrix Receiver Installed on user devices, Citrix Receiver provides users with quick, secure, selfservice access to documents, applications, and desktops from any of the user s devices including smartphones, tablets, and PCs. Receiver provides on-demand access to Windows, web, and software-as-a-service (SaaS) applications. Citrix StoreFront StoreFront provides authentication and resource delivery services for Citrix Receiver. It enables centralized control of resources and provides users with on-demand, selfservice access to their desktops and applications. Citrix Studio Studio is the management console that enables you to configure and manage your deployment, eliminating the need for separate consoles for managing delivery of applications and desktops. Studio provides various wizards to guide you through the process of setting up your environment, creating your workloads to host applications and desktops, and assigning applications and desktops to users. Delivery Controller Installed on servers in the data center, Delivery Controller consists of services that communicate with the hypervisor to distribute applications and desktops, authenticate and manage user access, and broker connections between users and their virtual desktops and applications. Delivery Controller manages the state of the desktops, starting and stopping them based on demand and administrative configuration. In some editions, the controller enables you to install profile management to manage user personalization settings in virtualized or physical Windows environments. License Server License server assigns a user or device license to the XenDesktop environment. Install License Server along with other Citrix XenDesktop components or on a separate virtual or physical machine. Virtual Delivery Agent (VDA) Installed on server or workstation operating systems, VDA enables connections for desktops and applications. For remote PC access, install the VDA on the office PC. Database Database stores all the XenDesktop site configuration and session information. Microsoft SQL server is required as a database server. 13
Server OS machines Virtual machines or physical machines, based on the Windows Server operating system, used for delivering applications or hosted shared desktops (HSDs) to users. Desktop OS machines Virtual or physical machines, based on the Windows Desktop operating system, deliver personalized desktops to users or applications from desktop operating systems. 3.4 Citrix Provisioning Services Citrix Provisioning Services Citrix Provisioning Services (PVS) takes a different approach from traditional desktop imaging solutions by fundamentally changing the relationship between hardware and software that runs on it. By streaming a single shared disk image (vdisk) instead of copying images to individual machines, PVS lets organizations reduce the number of disk images that they manage. Because the number of machines continues to grow, PVS provides the efficiency of centralized management with the benefits of distributed processing. Because machines stream disk data dynamically in real time from a single shared image, machine image consistency is ensured. In addition, large pools of machines can completely change their configuration, applications, and even the operating system during a reboot operation. 3.5 Citrix Machine Creation Services Citrix Machine Creation Services Machine Creation Services (MCS) is a provisioning mechanism that is integrated with the XenDesktop management interface, Citrix Studio, to provision, manage, and decommission desktops throughout the desktop lifecycle from a centralized point of management. MCS enables the management of several types of machines within a catalog in Citrix Studio. Desktop customization is persistent for machines that use the Personal vdisk (PvDisk or PvD) feature, while non-personal vdisk machines are appropriate if desktop changes are discarded when the user logs off. Desktops provisioned using MCS share a common base image within a catalog. Because of this, the base image is typically accessed with sufficient frequency to naturally use the VMware vsan cache, where frequently accessed data is promoted to flash drives to provide optimal I/O response time with fewer physical disks. 3.6 VMware App Volumes 2.11 VMware App Volumes 2.11 VMware App Volumes 2.11 is an integrated and unified application delivery and end-user management system for VDI and virtual environments: Quickly provision applications at scale. Dynamically attach applications to users, groups, or devices, even when users are logged into their desktop. Provision, deliver, update, and retire applications in real time. Provide a user-writable volume allowing users to install applications that follow them across desktops. App Volumes makes it easy to deliver, update, manage, and monitor applications and users across VDI and published application environments. It uniquely provides applications and user environment settings to desktop and published application environments and reduces management costs by 14
efficiently delivering applications from one virtual disk to many desktops or published application servers. Provisioning applications requires no packaging, no modification, and no streaming. App Volumes works by binding applications and data into specialized virtual containers called AppStacks, which are attached to each Windows user session at login or reboot, ensuring the most current applications and data are delivered to the user. App Volumes integrates a simple agent-server-database architecture into an existing VDI deployment. Centralized management servers are configured to connect to deploy virtual desktops that run an App Volumes Agent. An administrator can grant application access to shared storage volumes for users or virtual machines or both. Figure 6. App Volumes High-Level Architecture 15
4. Solution Configuration This section introduces the resources and configurations for the solution including. 16
4.1 Architecture Diagram Architecture Diagram Figure 7 shows the solution architectural design. Figure 7. vsphere Cluster Design 4.2 Hardware Resources Hardware Resources Table 2 shows two vsan Clusters used in the environment. One 8-node all-flash vsan Cluster was deployed to support 1,000 virtual desktops. One 4-node hybrid vsan Management Cluster was deployed to support infrastructure, management, and Login VSI launcher virtual machines used for the scalability testing. Table 2. Server Profile Property Server CPU Specification 8 x rack server 2 sockets, Intel(R) Xeon(R) CPU of 3 GHz 10- core 17
Property RAM Network adapter Storage adapter Specification 512GB 2 x Intel 10 Gigabit SFI/SFP 2 x 12Gbps SAS PCI-Express Disks SSD: 2 x 800GB class-d 6Gbps SAS drive as cache SSD SSD: 8 x 400GB class-d 6Gbps SAS drive as capacity SSD Note: The recommendation cache value is updated on Designing vsan Disk Groups All-flash Cache Ratio Update and you can adjust it based on your real environment requirements. The high cache setting in this solution is unnecessary in your environment. 4.3 Software Resources Software Resources Table 3 shows software resources used in this solution and Table 4 lists the system configurations for different server roles. Table 3. Software Resources Software Version Purpose VMware vcenter and ESXi 6.5 ESXi Cluster to host virtual machines and provide vsan Cluster. VMware vcenter Server provides a centralized platform for managing VMware vsphere environments. VMware vsan 6.5 Software-defined storage solution for a hyperconverged infrastructure. Citrix XenApp and XenDesktop 7.12 Provides a complete virtual app and desktop solution to meet customers needs from a single, easy-to-deploy platform. The Citrix Hotfix for XenApp and XenDesktop 7.12 MCS is valid for all vsan 6.x releases. 18
Software Version Purpose Citrix Provisioning Service 7.12 Allows customers to have a single instance image management of XenApp and XenDesktop VMs. VMware App Volumes 2.11 An integrated and unified application delivery and enduser management system for VDI and virtual environments. Table 4. System Configuration Infrastructure VM Role vcpu RAM (GB) Storage (GB) OS Domain Controller and DNS) 2 8 100 Windows Server 2012 R2 64-bit Table 5 lists the configuration details of Citrix XenApp and XenDesktop. Table 5. Citrix XenApp and XenDesktop Configuration Infrastructure VM Role Quantity vcpu RAM (GB) Storage (GB) OS XenDesktop Controllers 2 4 8 100 Windows Server 2012 R2 64-bit StoreFront Servers 2 4 4 100 Windows Server 2012 R2 64-bit License Server 1 4 4 100 Windows Server 2012 R2 64-bit PVS Servers 2 4 16 4.4 Virtual Machine Test Image Build 100 (OS) 250 (Store) Windows Server 2012 R2 64-bit Virtual Machine Test Image Build Two different virtual machine images were used to provision desktop sessions in the Citrix environment, one for desktop image and one for Server OS image. Table 6 lists the virtual machine test images. We used optimization tools according to VMware OS Optimization Tool and the Citrix 19
XenDesktop Windows 7 Optimization Guide. The test image configurations were the same for MCS and PVS except that the PVS template installed a PVS target device to create the vdisk image. Table 6. Virtual Machine Test Images Attribute login vsi XenDesktop Image Login VSI XenAPP IMAGE Desktop OS Windows 7 Enterprise SP1 (32-bit) Windows 2012 R2 (64-bit) Hardware VMware Virtual Hardware version 11 VMware Virtual Hardware version 11 CPU 2 8 Memory 2,048MB 24,576MB Memory reserved 0MB 0MB Video RAM 35MB 35MB 3D graphics off off NICs 1 1 Virtual network adapter 1 VMXNet3 Adapter VMXNet3 Adapter Virtual SCSI controller 0 VMware Paravirtual VMware Paravirtual Virtual disk VMDK 1 30GB 100GB Virtual disk VMDK 2 10GB 40GB Applications Adobe Acrobat 11 Adobe Flash Player 16 Doro PDF 1.82 FreeMind Internet Explorer 11 Microsoft Office 2010 Adobe Acrobat 11 Adobe Flash Player 16 Doro PDF 1.82 FreeMind Internet Explorer 11 Microsoft Office 2010 VMware Tools 10.0.6.3560309 10.0.6.3560309 Citrix VDA 7.12 7.12 4.5 Network Configuration Network Configuration A VMware vsphere Distributed Switch (VDS) acts as a single virtual switch across all associated hosts in the data cluster. This setup allows virtual machines to maintain a consistent network configuration as they migrate across multiple hosts. 20
Figure 8. vsphere Distributed Switch Network I/O control was enabled for the distributed switch. The following settings and share values were applied on the resource allocation as shown in Table 7. Table 7. Resource Allocations for Network Resources in vsphere Distributed Switch Network Resource Pool Host Limit (Mbps) Shares vsphere vmotion 8000Mbit/s Low 25 Management Unlimited Normal 50 Virtual machines Unlimited High 100 vsan traffic Unlimited Normal 50 4.6 vsan Configuration vsan Configuration Each ESXi server had the same configuration of two disk groups, each consisting of one 800GB cachetier SSD and four 400GB capacity-tier SSDs. 21
vsan Storage Policy vsan can set availability, capacity, and performance policies per virtual machine if the virtual machines are deployed on the vsan datastore. Citrix uses the default storage policy. We need to modify the default storage policy to enable or disable certain vsan features. Table 8 shows the storage policy setting of RAID 5. Table 8. vsan Storage Settings with RAID 5 Storage Capability Setting Number of FTT 1 Number of disk stripes per object 1 Flash read cache reservation 0% Object space reservation 0% Failure tolerance method RAID 5 (erasure coding) capacity Several vsan features were used in this solution including deduplication and compression, software checksum, and Erasure Coding (RAID 5). App Volumes Setting We tested all the applications in a single AppStack except that IE was installed on the OS by default on MCS XenDesktop. Table 9. App Volumes-AppStack Configuration ATTRIBUTE Location Template SPECIFICATION [vsandatastore] cloudvolumes/apps/ newapp.vmdk (6,536 MB) [vsandatastore] cloudvolumes/ apps_templates/template.vmdk (2.11.0) Assignments 1,000 Attachments 1,000 Applications Adobe_Flash_Player_16_ActiveX, Adobe_Reader_XI_-11.0.10, Doro_1.82, FreeMind, Microsoft_Office_Professional_Plus_2010) 4.7 VMware Cluster Configuration 22
VMware Cluster Configuration Table 10 lists the VMware Cluster configuration. We should enable VMware vsphere High Availability (vsphere HA) and DRS features in VMware Cluster. Table 10. ESXi Cluster Configuration Property Setting Default Revised vsphere HA Enabled Cluster features DRS Enabled 4.8 VMware ESXi Server: Storage Controller Mode VMware ESXi Server: Storage Controller Mode The storage controller supports both pass-through and RAID mode. It is recommended to use controllers that support the pass-through mode with vsan to lower complexity and ensure performance. 4.9 Desktop Provisioning Mechanism Desktop Provisioning Mechanism Overview This solution was validated using PVS and MCS virtual desktops, both random and static (with PvD), to observe any performance and scaling differences between various provisioning methods. PVS Desktops Provisioning Services streaming technology allows computers to be provisioned and re-provisioned in real-time from a single shared-disk image. vdisks can exist on a Provisioning Server, file share, or in larger deployments, on a storage system that the Provisioning Server can communicate with (iscsi, SAN, NAS, and CIFS). vdisks can be assigned to a single target device as Private Image Mode, or to multiple target devices as Standard Image Mode. When a target device is turned on, it is set to boot from the network and to communicate with a Provisioning Server: 1. Unlike the thin-client technology, processing takes place on the target device. 2. The target device downloads the boot file from a Provisioning Server, and then the target device boots. 3. Based on the device boot configuration settings, the appropriate vdisk is located and mounted on the Provisioning Server. The software on that vdisk is streamed to the target device as needed. To the target device, it appears like a regular hard drive to the system. Figure 9 shows the process of booting a target device. 23
Figure 9. Boot Process of a PVS Target Device MCS Desktops Citrix XenDesktop 7.12 with MCS supports the use of linked clones to quickly provision virtual desktops. In a linked clone desktop, the operating system reads all the common data from the read-only base disk, and creates the unique data on the linked clone. Figure 10 shows a logical representation of this relationship. Figure 10. Logical Representation of an MCS-base Disk and Linked Clone Note: The Citrix Hotfix for XenApp and XenDesktop 7.12 MCS must be applied on MCS desktops. See Binary fix for Catalog Deletion Error on vsan 6.2 for detailed information. 24
5. Solution Validation The solution validates the VDI performance with vsan 6.5 all-flash, Citrix XenDesktop and XenApp 7.12, and VMware vsphere 6.5. 25
5.1 Testing Overview Testing Overview The solution validates the VDI performance with vsan 6.5 all-flash, Citrix XenDesktop and XenApp 7.12, and VMware vsphere 6.5. We deployed Windows 7 virtual desktops for both PVS and MCS, and recorded the performance and resource utilization differences for these two provisioning methods: For PVS mode, we used native applications installed on the OS image. For MCS mode, we used VMware AppStack to provision and assign the applications. For XenApp, we used Windows 2012 R2 as the Server OS and validated the performance and resource utilization for PVS and MCS provisioning methods. We used Login VSI to load the target environment with simulated user workloads and activities. Common applications such as Microsoft Office, Internet Explorer, and Adobe PDF Reader were utilized during the testing. Login VSI 4.1 has several different workload templates depending on the type of user to be simulated. Each workload differs in application operations executed and also in the number of operations executed simultaneously. The medium-level Knowledge Worker workload was selected for this test because it was the closest analog to the average desktop user in our customer deployments. The testing was based on the Login VSI in the benchmark mode, which was a locked-down workload test based on the Knowledge Worker template. In benchmark mode, if you select one workload, all the parameters are fixed (read only). This is an accurate way of performing a side-by-side comparison between VSIMax results in different configurations and platforms. Note: You might notice the wording of VSImax was not reached in some of the test results. This is because we have more server capacity available for Login VSI. We have previously determined the number of sessions to run concurrently to achieve optimal results. 5.2 Testing Tools Testing Tools We used the following monitoring and benchmark tools in the solution: Monitoring tools vsan Performance Service The performance service collects and analyzes performance statistics and displays the data in a graphical format. vsan administrators can use the performance charts to manage the workload and determine the root cause of problems. When the vsan Performance Service is turned on, the cluster summary displays an overview of vsan performance statistics, including IOPS, throughput, and latency. vsan administrators can view detailed performance statistics for the cluster, for each host, disk group, and disk in the vsan Cluster. esxtop esxtop is a command line tool that can be used to collect data and provide real-time information about the resource usage of a vsphere environment such as CPU, disk, memory, and network usage. We measure the ESXi Server performance by this tool. Workload testing tool Login VSI 4.1.5 26
Use the Login VSI in Benchmark mode with 20 sessions to measure VDI performance in terms of Login VSI baseline performance score (also called VSIbase or Login VSI index average score). The Login VSI baseline performance score is based on the response time reacting to the Login VSI workloads. A lower Login VSI score is better because it reflects that the desktops can respond in less time. In the tests, the workload type is Knowledge Worker * 2vCPU. For various Login VSI notations, see VSImax. Monitoring Parameters We took the following parameters into consideration to measure the testing performance: Benchmark VSImax CPU memory usage vsan IO latency and IOPS Capacity and deduplication ratio 5.3 PVS XenDesktop with Natively Installed Application PVS XenDesktop with Natively Installed Applications Testing Scenarios In this test, PVS Imaging Wizard was used to create a vdisk image from the master target device, then a collection of 1,000 streamed Windows 7 VM desktops was provisioned on the vsan datastore from the PVS server Console and was added to the machine catalogue from the Delivery Controller. The applications were installed with OS disk and a deliver group was created for Login VSI benchmark testing. The standard vdisk image was configured with cache in device RAM with overflow on the hard disk. The maximum RAM size was 512 MB. Testing Results As shown in Figure 11, there were 1,012GB used space and 1.23TB deduplication and compression overhead, which was 5 percent of the vsan datastore capacity. Deduplication and compression ratio was 4.35x, which was original used space/space used after deduplication and compression. The total capacity used was 23.29-21.07=2.22TB. Figure 11. Capacity Information about 1,000 PVS Windows 7 Desktops 27
Login VSI Knowlege Worker Results As shown in Figure 12, the 1,000 Windows 7 PVS desktops passed the Knowledge Worker workload easily without reaching VSIMax v4.1 at the baseline of 671. This was a stress testing so the peaks were acceptable while running 1,000 PVS desktops. Figure 12. VSImax on Login VSI Knowlege Worker Workload, PVS XenDesktop From the average ESXi CPU usage in Figure 13, the CPU usage increased steadily because the number of active session increased. The peak average CPU usage was 71 percent. Figure 13. CPU Usage during Login VSI Knowledge Worker Workload, PVS XenDesktop Figure 14 illustrates the average peak memory consumed was 249,814MB (around 244GB). ESXi memory was 512GB, which was about 48 percent usage. The average kernel memory usage was 29,718MB (around 29GB). 28
Figure 14. Memory Usage during Login VSI Knowledge Worker Workload, PVS XenDesktop From vsan Performance Service as shown in Figure 14, peak write IOPS was 5,770 and peak read IOPS was 6,068. IOPS increased as the number of active sessions increased. vsan IOPS was low because Login VSI testing was CPU bound. Figure 15. vsan IOPS during Login VSI Knowledge Workload, PVS XenDesktop As shown in Figure 16, vsan peak write latency was 0.960ms and peak read latency was 0.491ms. There was a sharp increase in latency when sessions became active. Figure 16. vsan Latency during Login VSI Knowledge Worker Workload, PVS XenDesktop 5.4 MCS XenDesktop with AppStack 29
MCS XenDesktop with Appstack Testing Scenarios In this test, 1,000 MCS random Windows 7 virtual desktops were deployed from the Delivery Controller in the machine catalog and a delivery group was created. The AppStack was assigned to those 1,000 desktops. Testing Results There were 1.21TB used space for 1,000 desktops with AppStack on vsan datastore as shown in Figure 17 and 1.23TB deduplication and compression overhead, which was 5 percent of the vsan datastore capacity. Deduplication and compression ratio was 2.43x. The total capacity used was 2.44TB. Figure 17. Capacity Information about 1,000 MCS XenDesktops with AppStack Login VSI Knowlege Worker Results As shown in Figure 18, the MCS Windows 7 desktops with AppStack passed the Knowledge Worker workload without reaching VSIMax v4.1 at the baseline of 1,206 and average of 1,482. Figure 18. VSImax on Login VSI Knowlege Worker Workload, MCS XenDesktop with AppStack 30
From the average ESXi CPU usage in Figure 19, the peak average CPU usage was 80 percent during the Login VSI testing. Figure 19. CPU Usage during Login VSI Knowledge Worker Workload, MCS XenDesktop Figure 20. Memory Usage during Login VSI Knowledge Worker Workload, MCS XenDesktop From vsan Performance Service, IOPS increased nearly steadily as the number of active sessions increased. Peak read IOPS was 9,540 and peak write IOPS was 6,896 during the Login VSI test. 31
Figure 21. vsan IOPS during Login VSI Knowledge Worker Workload, MCS XenDesktop Figure 22. vsan Latency during Login VSI Knowledge Worker Workload, MCS XenDesktop 5.5 PVS XenApp with Windows Server PVS XenApp with Windows Server Testing Scenarios PVS Imaging Wizard was used to create a vdisk image from the master target device Windows 2012 R2 Server, then a collection of 25 streamed Windows 2012 R2 VMs was provisioned on the vsan datastore from the PVS server Console and was added to the machine catalog from the Delivery Controller. The applications were installed with the OS disk and a deliver group was created for Login VSI benchmark testing. Testing Results As shown in Figure 23, there were 895.15GB used space and 1.23TB deduplication and compression overhead, which was 5 percent of the vsan datastore capacity. Deduplication and compression ratio was 2.23x. The ratio was relatively low because only 25 Windows 2012 VMs were deployed for 1,000 sessions. The total capacity used was 2.11TB. Figure 23. Capacity Information about 25 PVS Windows 2012 VMs Login VSI Knowlege Worker Results During the testing with 1,000 sessions, VSImax 4.1 was not reached with a baseline score of 566 and an average of 995. This was a stress testing so the peaks were acceptable while running the 1,000 sessions. 32
Figure 24. VSImax on Login VSI Knowlege Worker Workload, PVS XenApp During the Login VSI test, CPU usage was high and peak average CPU usage was 90 percent as shown in Figure 25. Figure 25. CPU Usage during Login VSI Knowledge Worker Workload, PVS XenApp The memory usage increased less than 1 percent during Login VSI tests as shown in Figure 26. Peak average memory consumed was 75,200MB (around 73GB). The ESXi memory was 512GB, which was about 14 percent usage. The average kernel memory usage was 29,005MB (around 28GB). 33
Figure 26. Memory Usage during Login VSI Knowledge Worker Workload, PVS XenApp From vsan Performance Service as shown in Figure 27, IOPS increased steadily as the number of active session increased. Peak write IOPS was 8,896. Figure 27. vsan IOPS during Login VSI Knowledge Worker Workload, PVS XenApp Figure 28. vsan Latency during Login VSI Knowledge Worker Workload, PVS XenApp 5.6 MCS XenApp with Windows Server 34
MCS XenApp with Windows Server Testing Scenarios In this test, 25 MCS random Windows 2012 R2 virtual machines were deployed from the Delivery Controller using the machine catalog wizard and a delivery group was created for the applications. These virtual machines are server OS that allows multiple users to log on. Testing Results Capacity As shown in Figure 29, there were 1.01TB used space and 1.23TB deduplication and compression overhead, which was 5 percent of the vsan datastore capacity. Deduplication and compression ratio was 1.68x. The ratio was relatively low because only 25 Windows 2012 VMs were deployed for 1,000 sessions. The total capacity used was 2.24TB. Figure 29. Capacity Information about 25 MCS Windows 2012 R2 VMs Login VSI Knowlege Worker Results Figure 30 shows that 986 sessions ran successfully. VSImax V4.1 was not reached with the baseline score of 570 and average of 1,112 for 1,000 sessions. Note: VSImax is measured by the average VSI response time. When the threshold is not exceeded by the average VSI response time during the test, VSImax is considered as the maximum amount of users that have launched. See VSImax for detailed information. 35
Figure 30. VSImax on Login VSI Knowlege Worker Workload, MCS XenApp From the average ESXi CPU usage as shown in Figure 31, CPU usage increased because the number of active sessions increased. Peak CPU usage was high, which was about 84 percent. The CPU usage went down when the sessions logged off. Figure 31. CPU Usage on Login VSI Knowlege Worker Workload, MCS XenApp Memory usage increased at the first half hour during Login VSI tests as shown in Figure 32. Peak average memory consumed was 75,683MB (around 75GB). ESXi total memory was 512GB. The average kernel memory usage was 28,408MB (around 28GB). 36
Figure 32. Memory Usage on Login VSI Knowledge Worker Workload, MCS XenApp From the backend view of vsan Performance Service as shown in Figure 33, peak write IOPS was 21,216 and peak read IOPS was 27,540. The IOPS was high from the vsan backend because vsan split the client IOs to several disk IOs. Figure 33. vsan IOPS during Login VSI Knowledge Worker Workload, MCS XenApp Figure 34. vsan Latency during Login VSI Knowledge Worker Workload, PVS XenApp 37
6. Best Practices We provided the best practices based on our solution validation. 38
6.1 AppStack Storage Policy AppStack Storage Policy When we place AppStack on vsan datastore, make sure FTT is not less than the FTT value of the desktop policy because AppStack is shared by users and desktops. Do not set it to be the availability bottleneck. 6.2 vsan Sizing vsan Sizing Acceptable performance of a virtual desktop is the ability to complete any desktop operation in a reasonable amount of time from a user s perspective. This means the backend storage that supports the virtual desktop must be able to deliver the data (read or write operation) quickly. Therefore, sizing storage configuration should meet the IOPS requirements in a reasonable response time. With various space efficiency features, the required capacity differs. Refer to the vsan TCO and Sizing Calculator for the virtual desktop sizing on vsan. 39
7. Recommendation We provided the solution recommendation in this section. 40
7.1 Recommendation Recommendation For both PVS and MCS, if the user to core ratio (user number/core number per host) value equals or is less than 6.25, it is recommended to enable deduplication and compression, RAID 5, and software checksum features to achieve a good balance of performance and cost. 41
8. Conclusion Check out the solution conclusion in this section. 42
8.1 Conclusion Conclusion VMware vsan is a low-cost and high-performance storage platform for a virtual desktop infrastructure that is rapidly deployed and easy to manage. Moreover, it is fully integrated into the industry-leading VMware vsphere Cloud Suite. Using SSDs in all-flash vsan with space efficiency features offers the enterprise performance while reducing capacity cost substantially and other Operating Expense (OPEX) costs such as maintenance by IT as well as power consumption and cooling costs. Extensive workload and operation tests show that Citrix XenApp and XenDesktop with App Volumes 2.11 on an all-flash vsan delivers exceptional performance, a consistent end-user experience, and a resilient architecture, all with a relative low price. All-flash vsan provides an easily scalable Citrix XenApp and XenDesktop 7.12 environment in both PVS and MCS provisioning methods together with App Volumes 2.11, which provides superior performance and manageability. 43
9. Reference Check out the references for additional resources. 44
9.1 Reference Reference White Paper For additional information, see the following white papers: VMware vsan 6.2 Space Efficiency Technologies Product Documentation For additional information, see the following product documents: vsan Management VMware APP Volumes 2.10 Citrix XenApp 7.6 Feature Pack 2 Blueprint Citrix XenApp and XenDesktop Other Documentation For additional information, see the following documents: VMware OS Optimization Tool Citrix PVS RAM Cache Overflow Sizing Citrix XenDesktop Windows 7 Optimization Guide 45
10. About the Author This section contains the author information. 46
10.1 Author Author Sophie Yin, solution architect in the Product Enablement team of the Storage and Availability Business Unit wrote the original version of this paper. Catherine Xu, technical writer in the Product Enablement team of the Storage and Availability Business Unit edited this paper to ensure that the contents conform to the VMware writing style. 47