VMware Horizon 6 Reference Architecture TECHNICAL WHITE PAPER

Transcription

1 VMware Horizon 6 Reference Architecture TECHNICAL WHITE PAPER

2 Table of Contents Executive Summary Workload Test Result Highlights VMware Reference Architectures Horizon 6 Solution Hardware Components Server Network Storage Software Components VMware vsphere VMware Horizon 6 with View Horizon 6 Reference Architecture Modular Pod and Block Design Horizon Pod Management Block Desktop Blocks Software-Defined Data Center Networking Storage Storage Sizing for Server Workloads Storage Sizing for Desktop Workloads Virtual Desktop Storage Workload Virtual Desktop Storage Capacity ESXi Hosts CPU Sizing Virtual Desktop Memory Sizing RDSH Memory Sizing VMware vcenter Server VMware vsphere Clusters Virtual Networking VMware vrealize Operations for Horizon Architecture Components Configuration TECHNICAL WHITE PAPER / 2

3 Unified Access with Workspace Portal Architecture Components Configuration Windows Desktops and Remote Applications with View Architecture Components Configuration Virtual Desktop Machine Image Build Remote Desktop Services Host Configuration Single Image Management with Mirage Architecture Configuration User Experience Blast Features PCoIP Settings Persona and User Data Desktop Persistence Integration Active Directory VMware SQL Server Windows File Services Availability Test Results Functional Testing Workload Testing RDSH Desktops Mirage Operations Testing Test: Assign an Updated Base Layer to Full-Clone Virtual Desktops Appendix A: Bill of Materials Appendix B: View Planner View Planner Operations Run Phases Quality of Service References TECHNICAL WHITE PAPER / 3

4 Executive Summary This reference architecture provides guidance for implementing a VMware Horizon 6 deployment that supports 2,000 10,000 users with an existing server and storage infrastructure. Although hardware is specified for 2,000 users, you can scale the deployment up to 10,000 users using the pod and block architecture approach. This reference architecture combines the technologies of standard rack mount server hardware running on EMC VNX storage leveraging View Storage Accelerator (to accelerate existing SAN) with VMware ESXi 5.5 and Horizon 6 software to produce a highly efficient, robust, and scalable next-generation virtual workspace deployment. This document includes information on View, VMware Mirage 5.0, and VMware Workspace Portal 2.1 running on top of VMware vsphere Users per ESXi Host 100 Users per ESXi Host Passed Passed Passed 14 Minutes Consolidation Ratio per 16 core ESXi host for Remote Desktop Services (RDS) apps (light worker) Consolidation Ratio per 16 core ESXi host for View virtual desktops (medium worker) Access from Any Device to applications and desktops using VMware Horizon Client Access from Workspace Portal to View desktops and applications Single Image Management with dedicated virtual desktops managed by Mirage Set up Hosted Applications and Virtual Desktops from View Administrator Desktops and applications delivered through a single platform Streamline management and easily entitle end users by delivering virtual or remote desktops and applications through a single platform. Unified workspace with great user experience Securely provide a consistent end-user experience across devices, locations, media, and connections. Central image management Easily manage physical, virtual, and bring your own devices (BYOD). Optimized for the software-defined data center Dynamically allocate resources with virtual storage, computing, and networking to simply and cost-effectively manage and deliver desktop services on demand. Figure 1: Solution Highlights This document describes how to size and configure a solution that encompasses View, Mirage, and Workspace Portal, as well as the VMware vcenter and vsphere core technologies. You can provision, manage, and access hosted applications and virtual desktops from a single place quickly and efficiently. The example solution supports 1,000 hosted application users, 800 stateless virtual desktop users, and 200 persistent virtual desktop users. As part of the architecture validation, VMware performed functional, operational, and workload tests to highlight how the entire software stack integrates to provide a complete virtual workspace solution. TECHNICAL WHITE PAPER / 4

5 Workload Test Result Highlights Horizon 6 harnesses the capabilities of Remote Desktop Services (RDS) to allow multiple users to connect to a single Windows Server, but have individual desktop instances and applications. The user can connect to an application or a full desktop using PC over IP (PCoIP) for a rich end-user experience. Test highlights include the following results: RDSH access using PCoIP and VMware View Planner office worker workload validated for 120 users per ESXi, 30 RDSH desktop sessions per RDSH server. View Planner testing passed comfortably within operational latency thresholds. ESXi average CPU usage was 71 percent, with a peak of 96 percent, and memory usage was 78 percent with a peak of 79 percent. RDSH server average CPU usage was 70 percent, with a peak of 96 percent, and average memory usage was 40 percent, with peak of 59 percent. Peak of 218 IOPS per RDSH server; peak reads of 100 and peak writes of 167. A single ESXi 5.5 host was provisioned with four Windows 2012 RDSH servers as a View RDSH desktop pool. View Planner was used to simulate 120 end-user desktop sessions over PCoIP to the RDSH desktop pool and carrying out office worker tasks. The View Planner workload test performed five test run iterations. During this time, ESXi CPU usage averaged 71 percent, with a peak of 96 percent. The four RDSH servers averaged 70 percent CPU usage, with a peak of 96 percent. Figure 2: ESXi and RDSH Server CPU Usage TECHNICAL WHITE PAPER / 5

6 The ESXi 5.5 host averaged 78 percent memory usage, with a peak of 79 percent throughout View Planner testing. The four Windows 2012 RDSH servers averaged 40 percent memory usage, with a peak of 59 percent. Figure 3: ESXi and RDSH Server Memory Usage TECHNICAL WHITE PAPER / 6

7 VMware Reference Architectures VMware reference architectures, built and validated in the field by VMware and supporting partners, address common use cases, such as enterprise desktop replacement, remote access, and disaster recovery. This reference architecture guide helps customers IT architects, consultants, and administrators involved in the early phases of planning, designing, and deploying Horizon 6 solutions. It provides a standard and scalable design that can be easily adapted to specific environments and customer requirements. The reference architecture building-block approach uses common components to minimize support costs and deployment risks. It is based on information and experiences from large VMware deployments that are currently in production. It draws on best practices and integrates easily into existing IT processes and procedures. VMware reference architectures offer customers Standardized, validated, repeatable components Scalable designs that allow room for future growth Validated and tested designs that reduce implementation and operational risks Quick implementation, reduced costs, and minimized risk Horizon 6 Solution The Horizon 6 virtual workspace solution combines the best-of-breed data center and desktop virtualization technologies. The high-level infrastructure consists of ESXi hosts with a 2.1 GHz Intel E or 2.9 GHz E processor 128 GB RAM per ESXi host EMC VNX5500 based NFS storage (20 TB) 10 Gigabit Ethernet (GbE) networking Windows 7 virtual machines with one vcpu and 1 GB vram Microsoft Remote Desktop Session Host (RDSH) virtual machines with four vcpus and 24 GB RAM TECHNICAL WHITE PAPER / 7

8 Thin Client Mac OS PC Horizon Clients Kiosk ios/android View Security Servers View Connection Servers Workspace Portal vapp File Print Server Mirage Servers Mirage Mgmt MS SQL Active Directory View RDSH Apps & Desktops View Virtual Desktops View Composer vcenter vrealize Operations for Horizon SSD RDSH Cluster SSD Desktop Cluster Management Cluster NFS Shared Storage HTTPS/PCoIP DMZ (HTTPS/PCoIP) PCoIP ESX, vcenter, View, Mirage, AD traffic NFS Storage Figure 4: Horizon with View Components TECHNICAL WHITE PAPER / 8

9 Hardware Components This section provides an overview of the hardware components of the architecture. Extreme Summit x670 10GbE Desktop & RD Session Hosts 5 x Supermicro 2027TR Chassis 11 x Supermicro X9DRT-HF System Boards for VDI 9 x Supermicro X9DRT-HF System Boards for RDSH 16 Cores, 128 GB RAM VDI & RDSH VMs EMC VNX 5500 Horizon 6 Server Workloads Linked-Clone Desktops Full-Clone Desktops RD Session Hosts User Profiles User Data ThinApp Repository Mirage Single-Instance Store Management Hosts 1 x Supermicro 2027TR Chassis 3 x Supermicro X9DRT-HF System Boards 16 Cores, 128 GB RAM - Horizon 6 Server Workload VMs Figure 5: Hardware Components Server Supermicro SuperServer provides four hot-pluggable nodes in a 2U form factor. The system is ideal for running virtualized and cloud computing environments in a highly dense form factor. The Supermicro SuperServer system includes the following components: Intel Xeon ES-2600 and ES-2600 v2 processor family 128 GB DDR3 ECC registered memory Two 300 GB SSDs Intel 82599EB 10 GB SFI/SFP+ dual-port interconnection for connectivity Network The Extreme Summit x670 series switches are versatile, purpose-built, top-of-rack switches that support the emerging 10GbE-enabled servers in enterprise and cloud data centers. Benefits include High-density 10GbE switching in a small 1U form factor Scalable, with up to 48 ports in a single system and up to 352 ports in a stacked system Enterprise-ready High-availability ExtremeXOS operating system provides simplicity and ease of operation by using a single OS throughout the network TECHNICAL WHITE PAPER / 9

10 Storage All virtual desktops, virtual RDSH servers, management server virtual machines, user profiles, user data, and Mirage storage use the EMC VNX5500 model for NFS storage. VNX5500 can hold 250 drives, scalable up to 480 TB. It has up to 12 GB system memory at the block level, with support for Fibre Channel (FC), iscsi, and FC over Ethernet (FCoE) connectivity. VNX5500 is suitable for those who want to take advantage of enterpriselevel storage at a lower TCO. Note: This reference architecture assumes that the existing server platform, whether it is blade or rack-mount server, cannot accommodate the VMware Virtual SAN hardware requirements, and therefore will use VNX as the storage solution. Virtual SAN is a viable solution for Horizon 6. For more information, see the VMware Horizon with View and Virtual SAN Reference Architecture. Software Components This section provides an overview of the software components of the architecture. VMware vsphere 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. VMware 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 hybrid cloud model. VMware Horizon 6 with View Horizon 6 delivers hosted virtual desktops and applications to end users through a single platform. These desktop and application services including RDSH applications, packaged applications with VMware ThinApp, software-as-a-service (SaaS) applications, and even virtualized applications from Citrix can all be accessed from one unified workspace across devices, locations, media, and connections. Leveraging closed-loop management and optimized for the software-defined data center, Horizon helps IT control, manage, and protect the Windows resources that end users want at the speed they expect and with the efficiency that business demands. Horizon 6 also provides the ability to manage both virtual and physical desktop images using VMware Mirage. Mirage allows you to manage persistent, full-clone desktops. Horizon 6 allows users to access desktops and applications via VMware Workspace Portal. Workspace Portal also provides IT a central place to entitle and deliver Windows applications, desktops, SaaS applications, ThinApp packaged applications, and XenApp applications to users. TECHNICAL WHITE PAPER / 10

11 VMware Workspace Portal SaaS Apps ThinApp Repository VMware Workspace Portal VA Core Infrastructure Active Directory vcenter Server vrealize Operations Manager VMware Mirage View VMware Mirage Servers View Security Server View Connection Server View Composer Physical/Containerized Desktops Windows 7 Full Clone Windows 7 Linked Clone Full-Clone and Linked-Clone Virtual Desktop Pools Windows 7 3D Desktop RDSH-Hosted Desktops and Applications Figure 6: Horizon 6 Components TECHNICAL WHITE PAPER / 11

12 Horizon 6 Reference Architecture The architecture leverages the benefits of the VMware software-defined data center (SDDC) stack to provide an enterprise-class virtualization platform. Horizon with View for virtual desktops and hosted applications, Workspace Portal for unified application and desktop access, and Mirage for single image management run on top of the vsphere platform. The solution uses VMware vrealize Operations Manager to provide a single point to monitor the health and performance of all components. In addition, the solution offers a best-of-breed user experience through Blast Adaptive UX (including PCoIP and an HTML5 protocol) and a huge number of supported clients. Modular Pod and Block Design This Horizon 6 reference architecture is based on the proven approach of scalable and modular pod and block design principles. The View, Mirage, and Workspace Portal server workloads are placed in the management block of a Horizon 6 pod. All desktop workloads are in the desktop block within the pod, with the separation of desktop and RDSH server workloads maintained via distinct clusters and ESXi hosts. Horizon 6 Pod ~1,000 Desktops ~1,000 RD Sessions Desktop Block Desktop Cluster Desktop Cluster View Desktop Pools View RDSH Desktop Pools Shared Storage Switched Ethernet Network vcenter Server and View Composer View Connection Server View Connection Server View Security Server vrealize Operations Manager View Security Server Mirage Server Mirage Management Server Server Cluster Workspace Portal Horizon Management Block Figure 7: Horizon Pod and Management Block TECHNICAL WHITE PAPER / 12

13 Horizon Pod A Horizon pod is a logical administrative entity that can support up to 10,000 users or sessions. You can increase that limit to 20,000 users or sessions using 2 4 pods. A pod contains a management block and one or more desktop blocks. In this reference architecture, the pod supports 2,000 users or sessions. Management Block The management block contains all the Horizon server virtual machines. In customer production deployments, VMware vcenter Server is typically deployed for every 2,000 virtual desktops. VMware supports up to 10,000 desktop virtual machines in a single vcenter instance, but keeping to 2,000 desktops improves power and provisioning operation times. VMware supports a maximum of 2,000 concurrent sessions per View Connection Server. An additional View Connection Server is deployed for redundancy (n+1). Two additional View Connection Servers are paired with View security servers to provide secure, redundant external access to View desktops. Each security server can handle up to 2,000 connections. A single Workspace Portal virtual appliance can scale to extremely high numbers (30,000 users); therefore we recommend deploying a single instance. You can add virtual appliances for each component to provide redundancy. A single Mirage server can handle up to 1,500 managed desktops. You can use multiple Mirage servers to provide redundancy. A Mirage Management server is also required to manage the Mirage servers and desktop operations. A single vrealize Operations Manager virtual appliance can handle up to 10,000 virtual desktops. You can easily scale out each management component to support 10,000 users within a Horizon pod. TECHNICAL WHITE PAPER / 13

14 The management block has a single vsphere cluster that supports the Horizon server virtual machines shown in Figure 8. vsphere Cluster vcenter Server 2x View Security Server 2x Workspace Portal VA View Composer 2x View (Int.) Connection Server 2x View (Ext.) Connection Server vrealize Operations Manager UI VA 2x Mirage Server Mirage Management Server vrealize Operations Manager Analytics VA SQL Server Active Directory 3x ESXi 5.5 Host 2.1 GHz. 128 GB RAM 2x 2 TB LUN EMC VNX5500 NFS TEMP, ISO LUN EMC VNX5500 NFS Figure 8: VMware vsphere Cluster Desktop Blocks In a standard View reference architecture design, a desktop block, delineated by a dedicated vcenter instance, supports 2,000 concurrent sessions. You can architect multiple desktop blocks within a pod to support up to 10,000 concurrent sessions. In this reference architecture, the desktop block supports 2,000 sessions 1,000 virtual desktops and 1,000 RD sessions, running on virtual RDSH servers. The desktop block contains two vsphere clusters to isolate the differentiated workloads of hosted virtual desktop instances from the RDSH server instances. One cluster supports 800 linked-clone and 200 full-clone Windows 7 virtual desktops across 11 ESXi hosts. The other cluster supports 32 RDSH virtual machines on 9 ESXi hosts, sized to support approximately 1,000 hosted application sessions running between 4 6 applications. TECHNICAL WHITE PAPER / 14

15 Linked-clone desktop workloads and RDSH virtual machines are stored on the VNX5500 presented as an NFS datastore. Linked-clone desktops and RDSH servers are part of a pool of resources. If a host fails, users can be quickly connected to an alternative desktop or server on another host. Shared storage also allows linked-clone desktops and RDSH servers to be quickly recovered and run on another host in the cluster. Full-clone desktops are also deployed on the VNX5500 NFS-based datastore. Using shared storage reduces the impact of potential host failures for dedicated persistent desktop users. Management Block vcenter ESXi Desktop Cluster ESXi Desktop Cluster Windows 7 Full-Clone Pool 200 Desktops 6x 2 TB LUN EMC VNX5500 NFS 4x 1 TB LUN EMC VNX5500 NFS Windows 7 Linked-Clone Pool 800 Desktops 32x Remote Desktop Services Host 11x ESXi 5.5 Host 2.9 GHz, 128 GB RAM TEMP, ISO LUNS EMC VNX5500 NFS 9x ESXi 5.5 Host 2.9 GHz, 128 GB RAM Figure 9: Desktop Block Logical Infrastructure Design TECHNICAL WHITE PAPER / 15

16 Software-Defined Data Center Horizon leverages the VMware SDDC platform to ensure performance, security, manageability, scalability, availability, and reliability. Horizon 6 vsga / vdga CBRC Linked Clones SE Sparse Disk VAAI Virtual SAN Network Specifications Availability VMware vsphere Security Scalability Application Services vmotion Storage vmotion HA Fault Tolerance Data Recovery vshield Zones VMsafe DRS Hot Add vcompute vstorage vnetwork Infrastructure Services ESX and ESXi DRS and DPM Memory Overcommit VMFS Thin Provisioning Storage I/O Control Distributed Switch Network I/O Control Figure 10: Software-Defined Data Center Platform Horizon benefits from proven vsphere features, such as a distributed resource scheduler, high availability, VMware VMsafe, distributed vswitch, thin provisioning, transparent page sharing, and memory compression. Horizon also takes advantage of and integrates with several unique features within vsphere 5.5, including View Storage Accelerator Host-based memory cache of the most commonly read disk blocks to help reduce read I/O storms during boot or login events Linked clones Single image management and storage optimization to reduce the desktop storage requirement Space-efficient (SE) sparse disks Reclamation of unused disk blocks in linked clones, providing the ability to manage the growth of linked clones over time GPU virtualization Support for a wide range of 3D-based use cases, using both shared (vsga) and dedicated (vdga) GPU virtualization vsphere Storage APIs Array Integration Ability to offload virtual machine provisioning operations to a storage array Virtual SAN Storage layer abstraction and virtualization by pooling local storage resources into a virtual shared storage array In addition, Horizon can be managed and monitored using vcenter Server and vrealize Operations for Horizon. TECHNICAL WHITE PAPER / 16

17 Networking The physical networking infrastructure is standardized on 10GbE. Each host includes a dual port 10GbE card and a dual port 1GbE card. Each host is connected to a 10GbE Extreme Summit x670 Ethernet switch in its associated rack. Each Extreme x670 switch is connected to a core 10GbE switch, providing connectivity across racks. See the Virtual Networking section for more information on virtual machine networking. Configuring a third-party firewall and load balancing are out of the scope of this reference architecture. Storage This reference architecture leverages an existing EMC VNX5500 storage system to host all linked-clone and fullclone desktops, RDSH servers, server workloads, user profiles, user data, and Mirage storage. Local solid-state drives (SSD) were not used, but could be, for example, to host RDSH server workloads. In any virtual desktop deployment, it is critical to use storage acceleration technologies for desktop performance. Storage acceleration technologies include read/write cache, inline deduplication, I/O optimization, I/O compression, and storage tiering. Storage acceleration can occur as part of the hypervisor or as part of the storage solution. To reduce the read I/O requirements on the VNX, View Storage Accelerator caches read I/O locally on the ESXi host. To reduce the capacity requirement for linked clones, the SE sparse disk format is used to reclaim unused disk blocks. Software-defined storage solutions, such as VMware Virtual SAN, can also reduce the impact on or need for legacy SAN devices by performing acceleration at the ESXi host. Virtual SAN is a viable storage platform for Horizon and many of the workloads described in this reference architecture. However, this architecture did not use Virtual SAN to demonstrate how to use existing server platforms that might not support the Virtual SAN hardware requirements. For more information on Horizon with View running on Virtual SAN, see the VMware Horizon with View and Virtual SAN Reference Architecture. Horizon Desktop Cluster 2x 300 GB SSD Horizon Management Cluster 2x 300 GB SSD 10GbE 4x 1 TB RD Session Hosts 10GbE 2x 2 TB All Servers 1x 490 GB ISO 1x 1 TB TEMP EMC VNX5500 NFS 6x 2 TB Full Clones, Linked Clones, Linked-Clone Replicas EMC VNX5500 NFS Figure 11: Storage Options TECHNICAL WHITE PAPER / 17

18 Based on the powerful new family of Intel Xeon 5600 processors, the EMC VNX5500 implements a modular architecture that integrates hardware components for object-based storage with concurrent support for native network-attached storage, iscsi, FC, and FCoE protocols. The series delivers file functionality via 2 8 X-blade data movers and block storage via dual storage processors leveraging full 6Gb SAS disk drive topology. The EMC VNX5500 has 20 TB of usable disk available. ISO (490 GB) and temp (1 TB) datastores are presented to ESXi hosts across both clusters. In this reference architecture, VNX is configured to present two 2 TB datastores via NFS to all hosts in the management cluster. It is also configured to present six 2 TB datastores via NFS to all hosts in the desktop cluster and four 1 TB datastores to all hosts in the RDSH cluster. Both the 2 TB and 1 TB datastores provide about 3,000 IOPS, based on the number of disks provided per datastore. VNX caching features increase the number of IOPS that each datastore can deliver. Work with your storage vendor to understand the datastore s configuration, sizing, and IOPS capability. Keep in mind the following sizing and performance calculations and that you need to size for peak average IOPS. When consulting the storage vendor, ensure that the front-end IOPS requirement and the RAID-level impact on the backend IOPS are understood. Storage Sizing for Server Workloads All server workloads running in the management block are hosted on the EMC VNX5500 array. The solution uses 22 server virtual machines, vsphere components, and infrastructure services. The server workloads require about 2 TB of disk for virtual machine disk format (VMDK) files. Each server workload also requires swap files. The size of the swap file is equivalent to the amount of memory allocated to the virtual machine. Virtual machine swap files total 272 GB no memory reservation is used. With an additional 20 percent overhead, the total disk requirement is 2.83 TB. The VNX presents two 2 TB NFS datastores to each host in the management cluster, with room to add additional server workloads as necessary. Storage Sizing for Desktop Workloads Storage plays an important role in desktop performance and the user experience. The following tables provide sample calculations for working out the capacity and performance requirements for datastores hosting desktop workloads. The tables do not take specific storage optimization or acceleration technologies into consideration. Consult your storage vendor to validate desktop storage sizing. In many implementations, it is more important that the limit on the number of virtual machines per datastore be influenced by the I/O requirements of the virtual machine and the spindle types. When considering the number of virtual machines to place on a single datastore, consider the following factors in conjunction with any recommended virtual machines per datastore ratio: Types of disks used (SATA, SAS, SSD) Typical virtual machine size (including configuration files, logs, swap files, snapshots) Virtual machine workload and profile (specifically, the IOPS) The following table shows the IOPS for two different types of disks, which affects the overall number of disks required per datastore. DISK TYPE SIZE IOPS 15 K RPM SAS 600 GB ~150 SSD 300 GB ~1,500+ Table 1: Disk Properties TECHNICAL WHITE PAPER / 18

19 Virtual Desktop Storage Workload When designing a storage solution, it is important to understand the I/O profile of the virtual machines that will be placed on the storage. For instance, some applications are heavy on reads, some are heavy on writes, some are heavy on sequential access, and some are heavy on random access. Although the profile can be assumed based on application type, it is best to measure the I/O patterns before rolling out to a production implementation. The profile dictates the RAID type to use. This reference architecture uses an existing VNX SAN offering 2 TB datastores capable of about 3,000 IOPS without caching. Based on this, the number of virtual machines per datastore was calculated to be 168, with an 80/20 mix of linked-clone and full-clone desktops. The following table shows the storage calculations for desktops on a per datastore basis. Numbers are always rounded up in these calculations. ATTRIBUTE VALUE Virtual machines per datastore 168 IOPS per virtual machine (normal user) 10 IOPS per virtual machine (heavy user) 20 Total IOPS (80% normal user, 20% heavy user) Average throughput per virtual machine (normal user) Average throughput per virtual machine (heavy user) Total throughput (80% normal user, 20% heavy user) (135 x 10 IOPS) + (34 x 20 IOPS) = 1350 IOPS IOPS = 2030 IOPS 200 KBps (estimated) 300 KBps (estimated) (135 x 200 KBps) + (34 x 300 KBps) = 27,000 KBps + 10,200 KBps = 37,200 KBps (37.2 MBps) RAID 5 penalty for writes 4 RAID 10 penalty for writes 2 Total IOPS required (70% reads, 30% writes) Total IOPS required (50% reads, 50% writes) Total IOPS required (30% reads, 70% writes) (609 x 4) = 3857 IOPS (RAID 5) (609 x 2) = 2639 IOPS (RAID 10) (1015 x 4) = 5075 IOPS (RAID 5) (1015 x 2) = 3045 IOPS (RAID 10) (1421 x 4) = 6293 IOPS (RAID 5) (1421 x 2) = 3451 IOPS (RAID 10) Table 2: Desktop Storage Performance Calculations Note: Based on the read/write I/O split, the worst case during steady state not boot or login storm is 6293 IOPS per datastore. The best case is 2639 IOPS per datastore. You can use the total IOPS to calculate the number of disks required to back the datastore. For example, based on the IOPS capability of the disks, between SAS hard-disk drives (HDD) would be required as compared to just one or two SSDs. This number does not take storage caching or acceleration into account. You can calculate RDSH workloads in a similar manner. The IOPS per RDSH user session can be between 3 10 for steady state. TECHNICAL WHITE PAPER / 19

20 Virtual Desktop Storage Capacity Full-clone and linked-clone desktops share the same datastores, so the total datastore size is a combination of both datastores. ATTRIBUTE SPECIFICATION DESCRIPTION Number of OS disks per datastore 2 TB datastores offering 3,000 IOPS were already provisioned. Based on storage performance calculations, each datastore could accommodate 168 desktops, consisting of 135 linked clones and 34 full clones. OS disk datastore size At least 1.47 TB Size is based on the following calculations: Desktop size 40 GB (Windows 7) Swap file size 256 MB (75% memory reservation) Log file size (max) 10 MB Free space allocation 10% additional overhead Minimum allocated datastore size: 1.47 TB (34 virtual machines * ( ) + 10% free space overhead Total number of datastores (based on capacity) 1 per 34 virtual machines Six datastores required for 200 desktops. These are the same datastores used for linked clones. Hosts per datastore 11 All hosts in the desktop cluster have access to six NFS datastores of 2 TB each, provided by the VNX. Table 3: Full-Clone Desktop Datastore Sizing The following table lists the datastore sizing calculations for linked clones. ATTRIBUTE SPECIFICATION DESCRIPTION OS disks per datastore VMFS 140 with VAAI 250+ NFS Based on best practices, 64 VMFS datastores is conservative, while 128 is possible, depending on the IOPS of the physical array and desktop performance expectations. More than 250 linked clones per datastore is possible with NFS. Maximum of 512 linked clones per replica. OS disk datastore size At least 376 GB Size is based on the following calculations: Master replica size 40 GB (Windows 7) Swap file size 256 MB (75% memory reservation) Page file 1024 MB Log file size (max) 10 MB Maximum VMDK growth 1024 MB (optimistic) Free space allocation 10% additional overhead Minimum allocated datastore size: 376 GB (134 virtual machines * ( ) + 40 GB replica + 10% free space overhead) Swap file can be eliminated or reduced by reserving memory for all virtual desktops. TECHNICAL WHITE PAPER / 20

21 ATTRIBUTE SPECIFICATION DESCRIPTION Total number of datastores (based on capacity) 1 per 134 virtual machines (NFS) Six datastores required for 800 virtual machines. Hosts per datastore 11 hosts per datastore For floating-pool linked clones, each host must have access to each datastore hosting linked clones. Table 4: Linked-Clone Desktop Datastore Sizing The following table lists the datastore sizing calculations for RD Session Hosts. ATTRIBUTE SPECIFICATION DESCRIPTION Number of OS disks per datastore 1 TB datastores offering 3,000 IOPS were already provisioned. Assuming 3 IOPS per RDSH session (known light worker test I/O profile), the datastore can support about 1,000 sessions. Given 120 sessions per RDSH, the datastore can support 8 RDSH virtual machines. OS disk datastore size At least 524 GB Size is based on the following calculations: Server size 40 GB (Windows Server 2012 R2) Swap file size 24 GB Log file size (max) 10 MB Free space allocation 10% additional overhead Minimum allocated datastore size: 524 GB (8 virtual machines * ( ) + 10% free space overhead) Spare capacity is available if RDSH servers need to be larger than 40 GB. Total number of datastores (based on capacity) 1 per 8 virtual machines Four datastores required for 32 RDSH servers. Hosts per datastore 9 All hosts in the desktop cluster have access to four NFS datastores of 1 TB each, provided by the VNX. Table 5: RDSH Datastore Sizing TECHNICAL WHITE PAPER / 21

22 ESXi Hosts This architecture uses standard rack mount servers with dual socket, 8-core, 2.1 GHz or 2.9 GHz CPUs, and 128 GB RAM running ESXi version 5.5. The desktop and RDSH workloads use the 2.9 GHz hosts, and the management workloads use the 2.1 GHz hosts. The hosts are split into three clusters. The management cluster uses 3 hosts, the virtual desktop cluster uses 11 hosts, and the RDSH workload cluster uses 9. Figure 12: ESXi Host Specification VMware has conducted a number of performance and system tests to validate the scalability of View in terms of desktop workloads. The results were used to size the hosts for this reference architecture. To determine sizing calculations, it is recommended to assess your user workloads and CPU, memory, and disk I/O requirements. In this reference architecture, virtual desktop users are considered normal office workers, and RDSH users are considered light office workers (five common applications). CPU Sizing Based on VMware testing, experience from field deployments, and industry analysis of RDSH sizing, this reference architecture uses the recommended specification of four vcpu virtual RD Session Hosts with no CPU overcommit. This specification means that a 2-CPU, 8-core host with 16 physical cores can support up to 4 vcpu RD Session Hosts on a single ESXi server. Our testing indicates that we can expect approximately 30 light office worker sessions per RDSH. 1 x 4 vcpu virtual RD Session Host per 4 CPU cores / 16 cores = 4 RDSH per ESXi host with 30 sessions per RDSH (120 sessions per ESXi host) TECHNICAL WHITE PAPER / 22

23 VMware testing and field experience shows that customers can expect anywhere from vcpu virtual desktops per physical core. For a normal office worker workload, we are using eight 1 vcpu virtual desktops per core. 8 x 1vCPU virtual desktops per CPU core * 16 cores * 80% (max. CPU) = 100 virtual desktops per host DESKTOP PERFORMANCE METRIC Average number of CPUs per physical desktop system Average CPU utilization per physical desktop system RECORDED VALUE MHz vcpu overhead 10% ATTRIBUTE SPECIFICATION Number of CPUs (sockets) per host 2 Number of cores per CPU 8 GHz per CPU core Total GHz per CPU Total CPU GHz per host 2.9 GHz 23.2 GHz 46.4 GHz Proposed maximum host CPU utilization 80% Available CPU GHz per host Virtual machines per host Total ESXi hosts required GHz ~100 (37.12 GHz / 385 MHz) 10 (+1 for HA) Table 6: ESXi Host CPU Requirements TECHNICAL WHITE PAPER / 23

24 Virtual Desktop Memory Sizing In View deployments, the majority of Windows 7 x86 virtual desktops have between 1 GB and 2 GB vram, with no memory overcommit. For this reference architecture, we are simulating a known office-user workload that does not exceed 1 GB RAM, therefore we are using 1 GB RAM per virtual desktop. For your deployment, assess the memory requirements for the expected user workloads and size the virtual desktops appropriately. This reference architecture uses existing server hardware that is already configured with 128 GB RAM. To handle a host failure, an additional host to the cluster is added to ensure that hosts are running above 80 percent only in the event of a host failure. ATTRIBUTE Total amount of RAM per virtual machine SPECIFICATION 1024 MB Memory reservation Resolution Memory overhead per virtual machine Total RAM required for desktop virtual machines Total RAM required per host (100 virtual machines) Impact of additional host for HA purposes Anticipated savings from transparent page sharing (in event of a host failure) 25% (256 MB) 1920 x 1600 (1 monitor) 41 MB 104 GB 128 GB 10% saving 10% 20% Proposed maximum host memory usage 80% Total amount of RAM per host 128 GB Table 7: Virtual Desktop Memory Sizing for a 1 GB RAM Workload TECHNICAL WHITE PAPER / 24

25 RDSH Memory Sizing RDSH workloads vary in memory requirements depending on the application workload. In VMware testing of light, normal, and heavy workloads, the memory requirement is approximately 512 MB, 768 MB, and 1 GB RAM per session, respectively. The light workload for RDSH in this instance consists of Microsoft Office (Excel, Word, and PowerPoint) Adobe Acrobat Reader Internet Explorer (browsing a picture library) 7Zip (compressing and decompressing files) Firefox (browsing a picture library) Internet Explorer (browsing text pages) RDSH (with PCoIP) workload calculation: 512 MB * 30 sessions per RDSH = 16 GB RAM used 4 * 16 GB RDSH per ESXi host = 64 GB RAM used To accommodate peaks in memory usage, RDSH servers are given 24 GB RAM, with an expectation that on average only 16 GB is consumed. ATTRIBUTE Total amount of RAM per RDSH session SPECIFICATION 512 MB Total number of sessions per RDSH 30 Total RAM required per RDSH 16 GB Number of RDSH per ESXi host 4 Memory overhead per virtual machine Total RAM required per ESXi host Total RAM allocated per RDSH Total RAM required per host 41 MB 64 GB 24 GB 97 GB Proposed maximum host memory usage 80% Total amount of RAM per host 128 GB Table 8: RDSH Memory Sizing for Light Workloads TECHNICAL WHITE PAPER / 25

26 VMware vcenter Server VMware vcenter Server manages the ESXi hosts, vsphere clusters, virtual networking, VMFS and NFS datastores, and the provisioning of virtual machines. For the purposes of automated testing using View Planner, a single vcenter Server manages the management cluster and the desktop clusters. In production implementations, VMware recommends deploying an additional vcenter Server to separate the management of server and desktop workloads. Ideally, a vcenter Server running on an existing vsphere platform manages the management block, and another vcenter Server running in the management block manages the desktop block. vcenter Server is sized to accommodate both server workloads and up to 2,000 virtual desktops. vcenter Server can scale to 10,000 virtual machines, if appropriately sized. You can also deploy multiple vcenter Servers for provisioning concurrency and higher availability. ATTRIBUTE VCENTER SERVER APPLIANCE OS Microsoft Windows Server 2012 vcpu vram Storage 4 vcpus 24 GB 100 GB Table 9: VMware vcenter Server Configuration VMware vsphere Clusters The following vsphere clusters were configured using vcenter Server. CLUSTER NUMBER OF HOSTS DESCRIPTION Management 3 Contains all server workload virtual machines for View, Mirage, Workspace Portal, and vcenter. Desktop 11 Contains all full-clone and linked-clone virtual desktops created by View. 1,000 users / 100 virtual machines per host = 10 hosts + 1 host for HA RDSH 9 Contains all RDSHs created for View. 1,000 users / 30 sessions per RDSH = 34 / 4 RD Sessions per host = 9 hosts Table 10: VMware vsphere Clusters TECHNICAL WHITE PAPER / 26

27 Virtual Networking In typical customer deployments, a vsphere implementation uses three types of network connections: virtual machine, management network, and VMkernel. Each type connects to a virtual switch that has one or more physical adapters at least two adapters are required for resilience to provide connectivity to the physical networks. External Workloads RDSH Virtual Desktop Server Workloads Storage Management EMC VNX NFS vmotion VMNet-10 VMNet-172 dvswitch1 vmk 10GbE NICs Figure 13: Virtual Network The Horizon environment has a distributed vswitch (dvswitch) to handle ESXi management, Horizon workloads, NFS, and VMware vsphere vmotion. The dvswitch uses dual port NICs connected to redundant switches, providing resiliency across network adapters. TECHNICAL WHITE PAPER / 27

28 The port groups and VLANs created on each ESXi host are shown in the following figure. Figure 14: Port Groups and VLANs The virtual machine port groups are dvpg-management Network for ESXi management dvpg-vmnet-10 Network for external access dvpg-vmnet-172 Network for all virtual machines dvpg-storage Network for EMC VNX5500 NFS traffic dvpg-vmotion Network for moving virtual machines between hosts in the cluster TECHNICAL WHITE PAPER / 28

29 VMware vrealize Operations for Horizon VMware vrealize Operations for Horizon simplifies the management of your virtual desktop infrastructure (VDI) and provides end-to-end visibility into its health and performance. It presents data through alerts, in configurable dashboards, and on predefined pages in the user interface. VMware vrealize Operations for Horizon extends the functionality of VMware vrealize Operations Manager Enterprise and enables IT administrators and help desk specialists to monitor and manage Horizon with View environments. Architecture VMware vrealize Operations Manager uses an adapter to pull data from View Connection Server and View Agent. The View adapter obtains the topology from the Horizon environment, collects metrics and other types of information from the desktops, and passes the information to vrealize Operations Manager. Another vcenter Server adapter pulls data relating to vsphere, networking, storage, and virtual machine performance. Out-of-the-box dashboards monitor the health of the Horizon infrastructure and components. You can access the dashboards via the Web-based vrealize Operations Manager console. Desktop VMs V4H Desktop Agent View Connection Server V4H Desktop Agent Database Server View Events Database Desktop metrics (PCoIP, CPU, memory, disk, session info) View topology and events vcenter Server vrealize Operations Manager 5.7 vapp vsphere metrics (ESXi, VM, datastore, data center) View Adapter View Adapter 1 vrealize Operations Manager Enterprise Objects, metrics, KPIs, alert, events vrealize Operations Manager Console (Browser) Custom UI View Dashboards Figure 15: VMware vrealize Operations for Horizon Architecture TECHNICAL WHITE PAPER / 29

30 Components VMware vrealize Operations for Horizon consists of two SUSE Linux Enterprise 11 (64-bit) virtual appliances that support 1,000 virtual desktops. The analytics appliance collects data from vcenter Server, VMware vcenter Configuration Manager, and third-party sources, such as metrics, topology, and change events. Raw data is stored in a scalable file system database (FSDB). The Web UI appliance allows you to access the results of the analytics and the Administration Portal to perform management tasks. ATTRIBUTE WEB UI APPLIANCE ANALYTICS APPLIANCE OS SUSE Linux Enterprise 11 (64-bit) SUSE Linux Enterprise 11 (64-bit) vcpu 4 vcpus 4 vcpus vram 11 GB 14 GB Storage 100 GB 800 GB Table 11: VMware vrealize Operations for Horizon Sizing Configuration VMware vrealize Operations for Horizon is configured as described in the installation guide with no additional modifications. After deploying the virtual appliance, the configuration steps are 1. On the Admin Web console Update tab, deploy the vcenter Operations Manager for Horizon PAK file to add the custom dashboards. 2. Log in to vcenter Operations Manager for Horizon and create the adapter instance. 3. Select the full metric set and set pairing credentials for the broker agent. 4. Install the broker agent on a View Connection Server. TECHNICAL WHITE PAPER / 30

31 For most environments, it is necessary to dedicate a View Connection Server for the broker agent. Figure 16: VMware vrealize Operations for Horizon Broker Agent Configuration Unified Access with Workspace Portal Workspace Portal provides an easy way for users to access applications and virtual desktops on any device and enables IT to centrally deliver, manage, and secure these assets. For end users, the result is true mobility: anytime, anywhere access to everything they need to work productively. For IT, it offers more control over corporate access across devices. In this reference architecture, Workspace Portal is the primary way to access View virtual desktops, RDSH desktops, ThinApp packaged applications, and SaaS-based applications. Architecture Workspace Portal is delivered as a SUSE Linux-based virtual appliance, an Open Virtualization Archive (OVA) file consisting of a single virtual appliance deployed through vcenter. This solution uses the Workspace Portal virtual appliance described below, plus View and ThinApp. You can configure Workspace Portal with additional virtual appliances to scale out the solution. TECHNICAL WHITE PAPER / 31

32 Thin Client Mac OS PC Horizon Clients Kiosk ios/android Private Cloud (vsphere) Internal Load Balancer External Load Balancer Workspace Portal VA x 2 ThinApp Repository Oracle/vPostgres Database View RDSH Apps and Desktops View Virtual Desktops View Connection Servers Active Directory Management Cluster HTTPS HTTPS (DMZ) View, Workspace Portal Traffic Figure 17: Workspace Portal Architecture TECHNICAL WHITE PAPER / 32

33 Access to Workspace Portal is via HTTPS, from anywhere, including from within a View or RDSH desktop. Workspace Portal supports both internal and external access. The user is connected to Workspace Portal to access their applications and desktops. All Workspace Portal components sit within the internal network. When launching a View desktop, RDSH desktop, or hosted application, Workspace Portal launches the Horizon Client if it is available. Alternatively, HTML5 protocol can be used to access View desktops if a Horizon Client is not installed. You can use a third-party load balancer to provide highly available access to multiple Workspace Portal virtual appliances. Do not deploy the Workspace Portal virtual appliance in the DMZ. Components Workspace Portal 2.1 is composed of a single virtual appliance that can be duplicated for scaling purposes. Application Proxy / Reverse Proxy Workspace Portal VA Workspace Portal VA API Core Services Connector Services tcserver DB (vpostgres) OS (SLES) API Workspace Portal VA Services Connector API Workspace Portal tcserver VA DB Services Connector API OS (SLES) tcserver DB Services Connector OS (SLES) tcserver DB OS (SLES) Figure 18: Workspace Portal Virtual Appliances Workspace Portal virtual appliance enables a single, user-facing domain for access to Workspace Portal for both user and administrators. The Workspace Portal virtual appliance is the single point of entry for all purposes. It contains all the components for integrating with Horizon with View or third-party solutions. vcpu RAM HDD VIRTUAL APPLIANCE SIZING 8 8 GB 72 GB Table 12: Sizing for a Single Workspace Portal VA for 30,000 Users TECHNICAL WHITE PAPER / 33

34 Configuration Workspace Portal virtual appliances get their time from the ESXi hosts that they are running on. Before installing Workspace Portal virtual appliances, make sure that the time settings across all ESXi hosts are accurate and have no skew because this can affect the Security Assertion Markup Language (SAML) configuration. SAML 2.0 authentication is configured across the participating View Connection Servers. After SAML 2.0 authentication is configured, the View Connection Servers are added to the connector virtual appliance used for synchronization operations. The View Client Access URL is configured in the Workspace Admin Console interface (Network Ranges) to point to the load balancer in front of the participating View Connection Servers so that all traffic is load balanced. The virtual appliance used for single sign-on (SSO) via Kerberos is joined to the domain, and Windows authentication is enabled on the administrative interface, providing users a seamless experience without prompts when accessing resources. Windows Desktops and Remote Applications with View View provides access to and management of virtual desktops, RDSH desktops, and hosted applications. In this reference architecture, View is sized and configured to provision 800 stateless desktops, 200 persistent desktops, and 1,000 RDSH sessions running 4 5 applications each. Architecture View is accessed via a Horizon Client installed on a user s device that connects to View security servers for external access or View Connection Servers for internal access. View Connection Servers provision and broker to virtual desktops, hosted applications, or RDSH desktops running on vsphere ESXi hosts. View Administrator and vcenter Server provide ESXi host and virtual machine management functions. In addition, VMware View Composer and Mirage provide single image management, and vrealize Operations Manager provides health and performance monitoring for all components within the architecture. TECHNICAL WHITE PAPER / 34

35 PCoIP UDP 4172 HTTPS TCP 443 HTTPS TCP 443 PCoIP (Direct) UDP 4172 Active Directory Security Servers File/Print/ThinApp Virtual Desktops RDSH Servers View Administrator Console View Composer Connection Servers SQL Desktop Admin vrealize Operations for Horizon vcenter vsphere Admin vsphere Client VMware ESXi VMware ESXi Private Cloud (vsphere) Figure 19: Windows Desktops and Remote Applications with View View Connection Server handles authentication to Active Directory and then brokers a connection to a virtual desktop, RDSH desktop, or hosted application using either PCoIP or HTML5 if using a Web browser. For external users, PCoIP traffic is forwarded by the View security server to the desktop session. For internal users, the client is connected directly to the desktop session. If a desktop is not available, View Connection Server can provision additional desktops automatically via vcenter Server. Entitling users or a group to preconfigured pools of desktops in View Administrator enables automatic provisioning. View Composer minimizes storage requirements by using linked clones for virtual desktops. View easily scales by adding more View Connection Servers or security servers. Each View Connection Server can handle up to 2,000 concurrent connections. Additional View Connection Servers also provide high availability. TECHNICAL WHITE PAPER / 35

36 View Connection Servers and security servers are installed in the management block. A Horizon pod can support up to seven View Connection Servers, not to exceed 10,000 concurrent sessions. Up to four View security servers per View Connection Server are permitted. It is recommended to deploy one vcenter Server per desktop block, along with a single instance of View Composer. View Composer can be installed on vcenter Server or be standalone. Components View consists of the following components: Horizon Client Horizon Clients are available for Windows, Mac, Ubuntu Linux, ios, and Android to provide the connection to remote desktops from your device of choice. By installing Horizon Client on each endpoint device, end users can access their virtual desktops from smartphones, zero clients, thin clients, Windows PCs, Macs, and ios and Android mobile devices. Unity Touch for Horizon Clients makes it easier to run Windows apps on iphone, ipad, and Android devices. View Connection Server View Connection Server streamlines the management, provisioning, and deployment of virtual desktops. Administrators can centrally manage thousands of virtual desktops from a single console. End users connect through View Connection Server to securely and easily access their personalized virtual desktops. View Connection Server acts as a broker for client connections by authenticating and directing incoming user desktop requests. View security server A View security server is an instance of View Connection Server that adds an additional layer of security between the Internet and your internal network. Outside the corporate firewall, in the DMZ, you can install and configure View Connection Server as a View security server. Security servers in the DMZ communicate with View Connection Servers inside the corporate firewall. Security servers ensure that the only remote desktop traffic that can enter the corporate data center is traffic on behalf of a strongly authenticated user. Users can only access the desktop resources for which they are authorized. View Composer View Composer is an optional service that enables you to manage pools of like desktops, called linked-clone desktops, by creating master images that share a common virtual disk. Linked-clone desktop images are one or more copies of a parent virtual machine that share the virtual disks of the parent, but which operate as individual virtual machines. Linked-clone desktop images can optimize your use of storage space and facilitate updates. You can make changes to a single master image through VMware vsphere Client. These changes trigger View Composer to apply the updates to all cloned user desktops that are linked to that master image, without affecting users settings or persona data. View Agent (including Remote Experience Pack) The View Agent service communicates between virtual machines and Horizon Client. You must install View Agent on all virtual machines managed by vcenter Server so that View Connection Server can communicate with them. View Agent provides features such as connection monitoring, virtual printing, persona management, and access to locally connected USB devices. View Agent is installed in the guest OS. View requires Active Directory for authentication and vcenter Server for virtual desktop provisioning and management. SQL Server is required by vcenter Server, View Composer, and View Connection Server for database purposes. COMPONENT QUANTITY VCPU VRAM HDD View Connection Server 4 (2 internal, 2 external) GB View security server 4 (2 per external View Connection Server) GB View Composer GB TECHNICAL WHITE PAPER / 36

37 COMPONENT QUANTITY VCPU VRAM HDD File print server GB SQL Server GB RDSH server GB Windows 7 desktops 1, GB Table 13: Sizing for View Deployment of 2,000 Users Configuration You use the Web-based View Administrator console to configure and manage View. You can also configure View Connection Servers and security servers from the console. This reference architecture uses the following settings: Global Policies View is configured to allow USB and PCoIP hardware acceleration, but to deny multimedia redirection (MMR). MMR is out of the scope of this reference architecture. View Configuration Settings All View Connection Servers and security servers are added to the View instance to create the View pod. Each externally facing View Connection Server is paired with two security servers. A ThinApp repository was not configured. Instead, Workspace Portal is used to access ThinApp packaged applications. An event database is configured and implemented on a standalone SQL Server. View Connection Server Settings Workspace Portal is the delegated authentication mechanism for View. The SAML authenticator is set to the externally facing fully qualified domain name of the Workspace Portal Gateway virtual appliance load-balanced IP address. vcenter Settings vcenter is configured to reclaim virtual machine disk space (for SE sparse disks). View Storage Accelerator is enabled with a 1 GB host cache. The settings 32, 50, 32, and 32 were used for concurrent operation limits. These settings are increased based on the storage device capabilities. Resources The created application farm, AppFarm01, consists of 32 RDSH servers. The farm is used for all RDSH desktop and application sessions. An RDSH desktop pool allows users to access a Windows 2012 RDSH desktop running via PCoIP. An application pool was created for each application tested and assigned to AppFarm01, again using PCoIP as the protocol. An automated floating desktop pool with 800 Windows 7 linked-clone desktops is provisioned with View Composer to enable load testing. No persistent disk or disposable disks are used. Replica and OS disks are stored on the same NFS datastore. The default settings are used for the advanced storage options. Another automated dedicated desktop pool with 200 Windows 7 full-clone desktops is provisioned using vcenter Server. The full clones are deployed across the six 2 TB NFS datastores. View Storage Accelerator is enabled to regenerate the manifest every 7 days. TECHNICAL WHITE PAPER / 37

38 Virtual Desktop Machine Image Build A single master OS image is used to provision desktop sessions in the View environment. Use a fresh installation of the guest OS so that the correct versions of the HAL, drivers (including the optimized network and SCSI driver), and OS components are installed. A fresh install also avoids performance issues with legacy applications or configurations of the desktop virtual machine. The reference architecture used a Windows 7 golden image with the specifications listed in the following table. The image is optimized in accordance with the VMware Horizon with View Optimization Guide for Windows 7 and Windows 8. It is modified to meet View Planner 3 requirements (see Sections A, B, and C of the View Planner Installation and User s Guide). We used the free VMware OS Optimization Tool (available for download at labs.vmware.com) to make the changes. ATTRIBUTE Desktop OS SPECIFICATION Windows 7 Enterprise SP1 (32-bit) Hardware VMware virtual hardware version 9 CPU 1 Memory Memory reserved Video RAM 3D graphics 1024 MB 256 MB Up to 128 MB Off NICs 1 Virtual network adapter 1 Virtual SCSI controller 0 Virtual disk VMDK VMXNet3 Adapter LSI Logic SAS 40 GB Table 14: Windows 7 Golden Image Virtual Machine Specifications TECHNICAL WHITE PAPER / 38

39 Remote Desktop Services Host Configuration The RD Session Hosts are Microsoft Windows 2012 R2 servers with the RDS feature and RDSH role added. View Agent is also installed on each RDSH server and registered to one of the View Connection Servers. ATTRIBUTE Desktop OS SPECIFICATION Windows Server 2012 R2 Hardware VMware virtual hardware version 9 CPU 4 Memory Memory reserved Video RAM 24 GB 0 MB 128 MB NICs 1 Virtual network adapter 1 Virtual SCSI controller 0 VMXNet3 Adapter LSI Logic SAS Virtual disk VMDK 40 GB C: 174 GB View Planner workload data (not required outside of testing) Table 15: RD Session Host Specifications Single Image Management with Mirage Mirage provides unified image management for physical desktops, virtual desktops, and bring your own devices. Dynamic layering and full system recovery ensure that IT can quickly and cost-effectively deliver, manage, and protect updates to operating systems and applications across tens of thousands of endpoints. Designed for distributed environments, Mirage requires little to minimal infrastructure at branch sites, reducing CapEx. Mirage also complements and extends PC Lifecycle Management tools to drive down IT help desk and support costs. This reference architecture uses Mirage to manage full-clone, persistent virtual desktops and linked-clone parent virtual machine images. For more information on managing physical endpoints with Mirage, see the VMware Horizon Mirage Branch Office Reference Architecture. TECHNICAL WHITE PAPER / 39

40 Architecture Mirage consists of a Mirage Management server, Mirage server, and Windows file server, which are used to manage and store data from Mirage clients (endpoints). Endpoints can be physical or virtual desktops (full clones only). External Physical Endpoints Physical Endpoints Mirage Edge Gateway Mirage Server Active Directory Mirage Admin Mirage Console SQL Mirage Management Server Mirage Windows File Server Mirage Server Virtual Desktop (Full Clone) VMware ESXi VMware ESXi Private Cloud (vsphere) Figure 20: Mirage Architecture To manage View desktops with Mirage, you need the following desktop virtual machines: Reference Windows desktop virtual machine for base layer capturing Windows desktop virtual machine for app layer capturing to add updates or new applications Template Windows desktop virtual machine to create a persistent full-clone pool TECHNICAL WHITE PAPER / 40

41 Mirage has the following components: Mirage Management server The management server is the main component that controls and manages the Mirage server cluster and coordinates all Mirage operations, including backup, migration, and operating system deployment. Mirage server Mirage servers perform backups, migrations, and the deployment of base and app layers to endpoints. Multiple Mirage servers can be deployed as a server cluster to provide system redundancy and support larger organizations. Mirage Web and Protection Manager These Web-based tools enable help desk personnel to efficiently respond to service queries and ensure that endpoints are protected by Mirage backup capabilities. Mirage client The Mirage client enables an endpoint to be managed by Mirage. It supports both physical and virtual desktops, including those hosted by both Type 1 and Type 2 hypervisors. SERVER QUANTITY VCPU VRAM HDD Mirage Management server and Mirage server GB Mirage Server GB SQL Server Mirage Single-Instance Store Uses the same SQL Server as View (see SQL Server section for sizing) Set up as a file share on the file and print server: Base layer Allow up to the size of the used disk in virtual desktop image per layer CVD storage (only metadata for full clones) ~500 MB per full clone Table 16: Recommended Sizing for Mirage for a 200 Full-Clone Desktop Deployment Configuration For this reference architecture, Mirage Management server is installed on one of the two Windows 2012 R2 virtual machines that also function as Mirage servers in the environment. The Mirage database is hosted on a Windows 2012 R2 virtual machine that is running SQL Server 2008 R2 Standard Edition. The SQL Server also hosts databases for View Composer and View events within the environment. Each Mirage server is configured with a separate 150 GB virtual disk to host the server local cache. This location is specified during server installation. The Mirage Console is a plug-in that is installed on and run from Mirage Management server. It is the single pane of glass for all Mirage management tasks across the environment; creating and deploying reference CVDs, base layers, and application layers are performed in this management tool. Built-in wizards to perform many of these tasks streamline management operations. TECHNICAL WHITE PAPER / 41

42 Figure 21: Mirage Console Built-in Wizards This Mirage install manages images for 200 full-clone, persistent desktops in View. A Mirage client is installed on a Windows desktop virtual machine (the reference desktop). A reference CVD is created, and a base layer that had 138 Microsoft updates and an application is captured with the Capture Base Layer wizard. Do not optimize the CVD policy for Horizon. The following two services must be enabled for Mirage when optimizing the virtual machine template: Volume Shadow Copy Microsoft Software Shadow Copy Provider The script attached to the VMware Horizon with View Optimization Guide for Windows 7 and Windows 8 disables these services. Either edit the script to enable these services or re-enable them on the template before deploying your pool of full-clone desktops. A Mirage client is installed on a Windows desktop machine, which is used to manage application updates. An administrator can capture an application layer by recording the state of the virtual desktop before and after an application install or update. The Mirage client is then installed on a template virtual machine to be used for full-clone desktops. A full-clone dedicated desktop pool can now be created using the template virtual machine and View. Each new virtual desktop in the pool appears as a pending device in the Mirage Console. TECHNICAL WHITE PAPER / 42

43 Now the full-clone desktops can be centralized using the CVD upload policy. Ensure that the CVD policy includes the option Optimize for VMware Horizon View. This option disables uploading of user data, which can cause considerable network, storage, and CPU load per desktop, so you cannot revert to a snapshot or restore user files to previous versions. However, user data and applications are not lost on base layer or application layer updates. VM for App Layer Capturing Mirage Server Mirage Management Server App Layer Base Layer Reference CVD VM User- Defined Layer (Optional) App Layer App Layer App Layer App Layer Base Layer Base Layer Base Layer Base Layer VM-1 VM-2 VM-n Template VM Full-Clone Pool Figure 22: Creating a Full-Clone Desktop Pool An administrator can use the Mirage Management server to apply the base layer or application layers to the full-clone desktops. Before applying new layers, it is recommended to run a layer conflict report to ensure that the changes do not interfere with user-installed applications. After the layers are applied, the user can continue without loss of user data or applications. TECHNICAL WHITE PAPER / 43

44 User Experience All client devices use either Workspace Portal or Horizon Client to connect to desktops and applications. Horizon Client is publicly available for download and can be installed on many different devices. This reference architecture uses the following Horizon Clients to access desktops and applications: Apple iphone 5 Apple ipad 2 Apple MacBook Android tablet Microsoft PC running Windows 7, single monitor The Horizon Client is required to access View-hosted (RDSH) applications and View RDSH desktops. To access View virtual desktops, either Horizon Client or a supported HTML5 browser is used. Blast Features With Horizon, IT can deliver desktops and applications to end users through a unified workspace using the Blast features to enable consistently great experiences across devices, locations, media, and connections. Blast includes the following features: Adaptive UX Optimized access across the WAN and LAN through an HTML browser or the purpose-built desktop protocol PCoIP Multimedia High-performance multimedia streaming for a rich user experience 3D Rich virtualized graphics delivering workstation-class performance Live communications Fully optimized unified communications and real-time audio and video support (Horizon 6 includes support for Microsoft Lync with Windows 8) Unity Touch Intuitive and contextual user experience across devices, making it easy to run Windows on mobile Local access Access to local devices, USB, and device peripherals For this reference architecture, not all the Blast features were tested. The reference architecture tested the adaptive UX, Unity Touch, and local access features. TECHNICAL WHITE PAPER / 44

45 PCoIP Settings PCoIP is the default protocol for View desktops and applications. It can be configured using a Group Policy Administrative Template. An Active Directory organizational unit (OU) is established for both RDSH services and virtual desktops. A single PCoIP policy is set across two OUs. Figure 23: PCoIP Policy Settings Persona and User Data To provide a consistent experience for users, it is imperative to maintain desktop and application configurations and settings across user sessions. This reference architecture uses View Persona profiles for all users across virtual desktops and a Microsoft RDSH profile (redirected to a network drive) for when users access RD Session Hosts (because View Persona does not support RDS session Profiles). View Persona is configured to synchronize the user profile every 90 minutes to a network share. Folder redirection for documents is used to minimize the profile size, and redirect user data to a network drive. Desktop Persistence For users requiring a dedicated desktop where they can install applications, a full-clone dedicated desktop is provided. Mirage is used to patch the operating system of the dedicated desktops. All user changes to the desktop are maintained. The benefit of using Mirage is that it provides a single point to manage both physical and virtual desktops. For more information, see Single Image Management with Mirage in this guide. For linked-clone, nonpersistent desktops, changes to the desktop operating system are lost when the desktops are refreshed or recomposed. View Composer is used to refresh, reset, or recompose linked-clone desktops. It uses a single desktop image, known as the Parent VM. Optionally, Mirage can update the Parent VM to provide true single-image management. TECHNICAL WHITE PAPER / 45

46 Integration This section details the integration considerations for this reference architecture. Active Directory The design uses OUs created specifically for View desktops and RD Session Hosts, An OU is an Active Directory subdivision that contains users, groups, computers, or other OUs. By creating dedicated OUs, View policies are applied via Group Policy Objects (GPOs) to all machines created dynamically by View without knowing the workstation account name. RD Session Hosts can also be added manually to an OU to apply RDSH-specific policies. View has administrative templates for managing View virtual desktops and RD Session Hosts. Administrators can import these templates and apply them via GPO to the respective OUs. This method provides a straightforward and consistent way to manage policies specific to View virtual desktops and users. For this reference architecture The created OUs allow management of users, virtual desktops, and RDSH. Virtual desktops are added automatically to the VirtualDesktops OU when provisioned by vcenter or View Composer. RD Session Hosts are added manually to the RDSH Services OU when provisioned using vcenter. Group policies are applied to RD Session Hosts and virtual desktops for folder redirection, profile management, and PCoIP. RD Session Hosts and virtual desktops need Allow Log On Locally and Allow Log on Through Remote Desktop Services to be set for the appropriate user groups. Group policy loopback processing is enabled to ensure that policies are applied to users accessing computers within the RDSH Services or Virtual Desktop OUs. Figure 24: Group Policy for Home Drive Redirection TECHNICAL WHITE PAPER / 46

47 VMware SQL Server VMware vcenter, View, and Mirage require database connectivity to store information. This reference architecture uses a single server running SQL Server 2008 R2. The following tables list the SQL Server specifications. For more information, see VMware vcenter Server 5.1 Database Performance Improvements and Best Practices for Large-Scale Environments. ATTRIBUTE Version SPECIFICATION SQL Server 2008 R2 Standard Virtual machine hardware VMware Virtual Hardware version 10 OS Windows Server 2012 R2 Standard vcpu 4 vmemory 16 GB vnics 1 Virtual network adapter 1 Virtual SCSI controller 0 Virtual disk VMDK VMXNet3 Adapter LSI Logic SAS 40 GB Windows OS 100 GB mssql01 SQL Server master and msdb databases, VCDB, View Composer database, View events database, and Mirage database (.mdf,.ldf) Table 17: SQL Server Virtual Machine Specifications The following settings were used to create the databases. ATTRIBUTE Vendor and version SPECIFICATION Microsoft SQL Server 2008 R2 Standard Authentication method Recovery method Database autogrowth Transaction log autogrowth Database size SQL authentication Simple Enabled in 1 MB increments In 10% increments, restricted to 2 GB maximum 5 GB Table 18: View Composer and Events Database Specifications TECHNICAL WHITE PAPER / 47

48 The following settings were used to create the Mirage database. ATTRIBUTE Vendor and version SPECIFICATION Microsoft SQL Server 2008 R2 Standard Authentication method Recovery method Database autogrowth Transaction log autogrowth Database size SQL authentication Simple Enabled in 1 MB increments In 10% increments, restricted to 2 GB maximum <1 GB Table 19: Mirage Database Specifications Windows File Services View, Workspace Portal, and Mirage rely on file services to provide users with access to data, applications, and image updates. Two Microsoft Windows file servers provide network shares for user data, View Persona user profiles, RDS profiles, ThinApp applications, and Mirage data. Each file server is allocated a 100 GB disk. Microsoft Distributed File System (DFS) is a highly available file services solution. The following table shows how the DFS shares are set up to replicate the data between the two file servers. Note: Size your file shares based on user quota, expected profile size, ThinApp application sizes, and Mirage Single Instance Store sizing. ATTRIBUTE SPECIFICATION Number of file servers 2 VM hardware VMware Virtual Hardware version 10 OS Windows Server 2012 R2 (64-bit) vcpu 4 vmemory 10 GB vnics 1 Virtual network adapter 1 Virtual SCSI controller 0 VMXNet3 Adapter LSI Logic Parallel TECHNICAL WHITE PAPER / 48

49 ATTRIBUTE Virtual disk VMDK SPECIFICATION 40 GB Windows OS 100 GB data disk: User home drives \HomeDrives View Persona \Persona RDS profiles \RDSProfiles Mirage Single Instance Store \Mirage ThinApps \ThinApp Table 20: Windows File Services Specifications Availability The system is resilient in the event of a component system failure. The design does not cover a disaster recovery scenario in which the entire site is lost, but it does cover limited component failure. ATTRIBUTE Workspace Portal Gateway Workspace Portal Service virtual appliance Workspace Portal Connector virtual appliance Mirage server failure View security server View Connection Server View desktop RD Session Host vcenter Server SPECIFICATION Multiple Gateway virtual appliances provide a highly available access solution. A third-party load balancer is required. Multiple Service virtual appliances provide a highly available Workspace Portal solution. No load balancer is required. Multiple Connector virtual appliances provide a highly available Workspace Portal solution. No load balancer is required. Multiple Mirage servers provide a highly available solution. A third-party load balancer is required for inbound traffic. Desktop use is not impacted, but image or application updates cannot be delivered to desktops. At least two load-balanced View security servers are required for redundancy. If a server fails, users are disconnected from their session. User data is not lost, and a user can reconnect quickly. A third-party load balancer is required. At least two load-balanced View Connection Servers are required for redundancy. If a server fails, users are not disconnected from their session. A third-party load balancer is required. If a desktop fails, the user might lose data. A new desktop can be provisioned if the current desktop cannot be fixed. Alternatively, a pool of preprovisioned desktops allows users to quickly connect to another desktop. Users are disconnected from their session. View supports RDSH farms in which multiple RD Session Hosts are pooled for desktop or application access. Users can reconnect to a different RD Session Host, but might have lost data. If vcenter Server fails, View is not affected. Virtual desktops can still be connected, but new desktops cannot be provisioned. Workloads are not balanced across clustered hosts. Desktops cannot be powered on or off. TECHNICAL WHITE PAPER / 49

50 ATTRIBUTE ESXi host View desktop cluster failure Management cluster failure SPECIFICATION If a virtual desktop host fails, the user loses connection to the desktop. The desktop can be migrated to another host in the cluster and started (if using shared storage). The user can connect to the desktop within minutes. Users might lose data. If all hosts in a View desktop cluster lose connectivity or fail, users assigned to the desktop pools hosted on the affected cluster cannot access a virtual desktop until the cluster is restored. The service is unavailable if the management cluster fails. Users directly accessing virtual desktops and RDSH sessions are disconnected, but might lose services, such as printing, Active Directory, and user profile data. Table 21: Potential Failure Points and Redundancy TECHNICAL WHITE PAPER / 50

51 Test Results Testing consisted of manual functional tests to highlight usability and manageability, operational tests to verify provisioning and administration tasks, and workload testing to validate performance and the user experience. Functional Testing Functional testing was performed across a number of client devices manually and also included common administrative tasks. After Horizon is installed and configured, it takes 14 minutes to set up and provide access to RDSH desktops and applications. It takes an additional 18 minutes to provision an initial pool of 100 desktops. Users can connect to desktops or applications in 10 seconds after being authenticated. FUNCTIONAL TEST TIME TO COMPLETE VALIDATION RESULT Configure Workspace Portal to integrate with View 7 minutes Entitled application appears in Workspace Portal PASSED Install a Mirage client on a template virtual machine (for full clones) 3 minutes Template virtual machine appears in the Mirage Console as a pending device PASSED Create desktop base layer in Mirage (14 GB used) 23 minutes Base layer appears in Mirage Console PASSED Provision RDSH server using vcenter Server 6 minutes RDSH virtual machine appears in vcenter Server as powered on PASSED Create RDSH farm in View 3 minutes Added RD Sesssion Hosts show up in the created farm PASSED Create RDSH desktop pool in View 5 minutes Desktop pool shows up in View Administration console, and entitled users can access the pool PASSED Create application pools in View 2 minutes Applications chosen from the RDSH farm show up in View Administration console and can be accessed by users PASSED Entitle users to RDSH desktops in View 2 minutes Entitlements show up in View Administration console PASSED Entitle users to RDSH applications in View 2 minutes Entitlements show up in View Administration console PASSED Access RDSH desktop from Horizon Client (ios, Mac OS, Windows, Android) 10 seconds (6 8 second reconnect) Clicking an RDSH desktop in Horizon Client after user login presents the desktop to the user PASSED TECHNICAL WHITE PAPER / 51

52 FUNCTIONAL TEST TIME TO COMPLETE VALIDATION RESULT Access RDSH application from Horizon Client (ios, Mac OS, Windows, Android) 8 10 seconds (6 8 second reconnect) Clicking an RDSH application in Horizon Client after user login presents the application to the user PASSED Access any RDSH application from Workspace Portal 8 10 seconds (6 8 second reconnect) Clicked RDSH application entitled from View and synced to Workspace Portal catalog PASSED Create a floating desktop pool (linked clones) for 800 desktops in View 63 minutes View desktops for the pool appear in the View Administration console PASSED Create a dedicated desktop pool (full clones) of 32 desktops in View 89 minutes View desktops for the pool appear in the View Administration Console PASSED Entitle users to floating desktop pool in View 2 minutes Entitlements show up in View Administration console PASSED Entitle users to dedicated desktop pool in View 5 minutes Each individual entitlement shows up in View Administration console PASSED Access floating desktop from Horizon Client (ipad, Mac OS, PC, Android) 10 seconds (6 8 second reconnect) Clicking a View desktop in Horizon Client after user login presents the desktop to the user PASSED Access dedicated desktop from Horizon Client (ipad, Mac OS, PC, Android) 10 seconds (6 8 second reconnect) Clicking a View desktop in Horizon Client after user login presents the desktop to the user PASSED Access any virtual desktop from Workspace Portal 10 seconds (6 8 second reconnect) Clicking an RDSH desktop in Horizon Client after user login presents the desktop to the user PASSED Access any RDSH application from within a virtual desktop session 8 10 seconds (8 10 second reconnect) Clicking an RDSH application in Horizon Client after user login presents the application to the user PASSED Centralize 32 full-clone virtual desktops 2 minutes Full clones appear as CVDs in Mirage Console PASSED Update 32 full-clone virtual desktops using Mirage (base layer updates 2080 MB) 35 minutes New base layer is deployed to virtual desktops with new OS updates, and user changes are maintained PASSED Table 22: Functional Test Results TECHNICAL WHITE PAPER / 52

53 Workload Testing RDSH Desktops Horizon 6 with View harnesses the capabilities of RDS, allowing multiple users to connect to a single Windows Server but have individual desktop instances and applications. Users can connect to a single application or a full desktop over PCoIP for a rich end-user experience. For testing, a single ESXi 5.5 host was provisioned with four Windows 2012 RDSH servers. The RDSH servers were clones, each with the same base applications and configuration. The RDSH servers were added to a new farm in Horizon with View. The farm was then added to a new RDSH desktop pool. VMware View Planner was used to simulate 120 end-user desktop sessions carrying out office worker tasks over PCoIP to the RDSH desktop pool. The application set consisted of seven common office applications and simulated 35 different user operations. The latency of these operations was used to calculate the View Planner score, as described in more detail in Appendix B. Figure 25: View Planner Operational Latencies To satisfy View Planner test requirements, Group A operation latencies had to be less than 1 second, and Group B application latencies less than 6 seconds. The workload passed comfortably: The Group A scored seconds, and Group B scored seconds. TECHNICAL WHITE PAPER / 53

54 TEST GROUP OPERATION TYPE RESULT Group A Interactive or fast-running operations that are CPU bound, like browsing through a PDF file, modifying a Word document, etc. 95th percentile: s (BR: <= 1.0 s) Group B Long-running, slow operations that are IO bound, like opening a large document, saving a PowerPoint file, etc. 95th percentile: s (BR: <= 6.0 s) Table 23: Test Groups The View Planner workload test performed five test run iterations. During this time, ESXi CPU usage averaged 71 percent, with a peak of 96 percent. The four RDSH servers averaged 70 percent CPU usage, with a peak of 96 percent. Figure 26: ESXi and RDSH Server CPU Usage TECHNICAL WHITE PAPER / 54

55 The ESXi 5.5 host averaged 78 percent memory usage, with a peak of 79 percent. The four Windows 2012 RDSH servers averaged 40 percent memory usage, with a peak of 59 percent. Figure 27: ESXi and RDSH Server Memory Usage RDSH server commands per second peaked at 218 during View Planner workload. Peak reads reached 100 per second, and peak writes 167 per second. Figure 28: RDSH Server Average IOPS TECHNICAL WHITE PAPER / 55

56 Mirage Operations Testing Mirage is a layered image management solution that separates desktop, laptop, or virtual endpoints into logical layers that are owned and managed by either IT or the end user. The base layer usually contains the operating system, core or infrastructure software, and common applications, such as MS Office. App layers are useful when you are distributing certain applications to a particular group of users. You can also use app layers to update or replace specific applications, instead of capturing new base layers. When you need to update a base layer or app layer, assign the new base or app layers to the Horizon with View desktop pool, and all the machines in the pool are updated. Test: Assign an Updated Base Layer to Full-Clone Virtual Desktops A pool of Windows 7 (32-bit) full-clone virtual desktops was provisioned in Horizon with View. A new base layer containing Windows updates, office files, and an application was captured from a reference virtual machine. The base layer was assigned to the pool. The base layer was 2080 MB (1910 MB when compressed). It took just 35 minutes to deploy the new base layer image to the pool of 32 full-clone virtual desktops. Figure 29: Time to Assign a Base Layer to Full-Clone Virtual Desktops TECHNICAL WHITE PAPER / 56

57 The Mirage server had low resource usage throughout testing, with peak CPU usage of 26 percent and peak memory usage of 13 percent. Figure 30: Mirage Server CPU and Memory Usage The Mirage server had a peak network transmit of 85 MBps and receive of over 15 MBps. Figure 31: Mirage Server Network Usage TECHNICAL WHITE PAPER / 57

58 Average full-clone CPU usage peaked at 57 percent. Average full-clone memory usage peaked at 97 percent during the base layer assignment operation. Figure 32: Full Clone Average CPU and Memory Usage Average full-clone network transmits peaked at 64 KBps, while average network receives peaked at 4485 KBps during the base layer assignment operation. Figure 33: Full Clone Average Network Transmits and Receives TECHNICAL WHITE PAPER / 58

59 The base layer assignment operation goes through an intensive read and write phase, with full-clone virtual desktop average reads per second peaking at 209 per desktop, and average writes per second peaking at 304 per desktop. Figure 34: Full Clone Average Read and Writes TECHNICAL WHITE PAPER / 59

60 Appendix A: Bill of Materials Extreme Summit x670 10GbE Desktop & RD Session Hosts 5 x Supermicro 2027TR Chassis 11 x Supermicro X9DRT-HF System Boards for VDI 9 x Supermicro X9DRT-HF System Boards for RDSH 16 Cores, 128 GB RAM VDI & RDSH VMs EMC VNX 5500 Horizon 6 Server Workloads Linked-Clone Desktops Full-Clone Desktops RD Session Hosts User Profiles User Data ThinApp Repository Mirage Single-Instance Store Management Hosts 1 x Supermicro 2027TR Chassis 3 x Supermicro X9DRT-HF System Boards 16 Cores, 128 GB RAM - Horizon 6 Server Workload VMs Figure 35: Hardware Components The test configuration bill of materials is summarized in the following table. AREA COMPONENT QUANTITY Server Supermicro 2027TR chassis 6 Supermicro X90RT-HF system boards (2 x Intel E GHz 8-core, 128 GB RAM) 20 Supermicro X90RT-HF system boards (2 x Intel E GHz 8-core, 128 GB RAM) 3 Storage EMC VNX5500 (20 TB) Desktop pools: 6 x 2 TB RDSH servers: 4 x 1 TB Management servers: 2 x 2 TB 1 Network Extreme Summit x670 10GbE switch 2 TECHNICAL WHITE PAPER / 60

61 AREA COMPONENT QUANTITY Software Horizon Enterprise Edition (View, Mirage, Workspace Portal) 2,000 users vcenter Server Included in Horizon Enterprise Edition ESXi Included in Horizon Enterprise Edition vrealize Operations for Horizon Included in Horizon Enterprise Edition Microsoft Windows 7 VDA 1,000 users Microsoft RDS CAL 1,000 users Microsoft Windows Server 2012 Datacenter Edition 1 Microsoft SQL Server 2008 R2 2 Table 24: Bill of Materials TECHNICAL WHITE PAPER / 61

62 Appendix B: View Planner 3.5 The View Planner tool simulates application workloads for various user types by running applications typically used in a Windows desktop environment. During the execution of a workload, applications are randomly called to perform common desktop user operations. Web Interface Harness VMware vcenter View View Planner Appliance Manage Client Management Desktop Management Virtual Client VMs Virtual Desktops Physical Servers Remote Display Protocol Physical Servers Storage Storage Figure 36: View Planner Simulation Tool View Planner Operations The View Planner workload consisted of seven applications, performing a total of 35 user operations. These user operations are separated into three groups, as shown in the following table. Group A are interactive operations, Group B are I/O operations, and Group C includes background load operations. The operations in Group A are used to determine quality of service (QoS). The Group C operations generate additional load. GROUP A GROUP B GROUP C AdobeReader: Browse AdobeReader: Open 7zip: Compress AdobeReader: Close Excel_Sort: Open PowerPoint: SaveAs AdobeReader: Maximize Excel_Sort: Save TECHNICAL WHITE PAPER / 62