VMware Horizon 6 Reference · PDF fileVMware Horizon 6 Reference Architecture ... using...

VMware Horizon 6 Reference ArchitectureT E C H N I C A L W H I T E PA P E R

VMware Horizon 6 Reference Architecture

T E C H N I C A L W H I T E PA P E R / 2

Table of Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Workload Test Result Highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

VMware Reference Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Horizon 6 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

VMware vSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

VMware Horizon 6 with View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Horizon 6 Reference Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Modular Pod and Block Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Horizon Pod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Management Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Desktop Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Software-Defined Data Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Storage Sizing for Server Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Storage Sizing for Desktop Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Virtual Desktop Storage Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Virtual Desktop Storage Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

ESXi Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

CPU Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Virtual Desktop Memory Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

RDSH Memory Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

VMware vCenter Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

VMware vSphere Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Virtual Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

VMware vRealize Operations for Horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30



Unified Access with Workspace Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Windows Desktops and Remote Applications with View . . . . . . . . . . . . . . . . . . . . . . 34

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Virtual Desktop Machine Image Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Remote Desktop Services Host Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Single Image Management with Mirage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Blast Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

PCoIP Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Persona and User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Desktop Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

VMware SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Windows File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Functional Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Workload Testing RDSH Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Mirage Operations Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Test: Assign an Updated Base Layer to Full-Clone Virtual Desktops . . . . . . . . . . . . 56

Appendix A: Bill of Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Appendix B: View Planner 3.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

View Planner Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Run Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65



Executive SummaryThis 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® 5.5.

120 Users perESXi Host

Consolidation Ratio per 16 core ESXi host for Remote Desktop Services (RDS) apps (light worker)

100 Users perESXi Host

Consolidation Ratio per 16 core ESXi host for View virtual desktops (medium worker)

PassedAccess from Any Device to applications and desktops using VMware Horizon Client

PassedAccess from Workspace Portal to View desktops and applications

PassedSingle Image Management with dedicated virtual desktops managed by Mirage

14 MinutesSet up Hosted Applications and Virtual Desktops from View Administrator

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.

•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.



Workload Test Result HighlightsHorizon 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



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



VMware Reference ArchitecturesVMware 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 SolutionThe 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 E5-2658 or 2.9 GHz E5-2690 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



ViewComposer

vCenter vRealize Operations for Horizon

MirageServers

File PrintServer

MirageMgmt

Workspace Portal vApp

View Connection Servers

View RDSH Apps & Desktops

NFS Shared Storage

SSD

RDSH Cluster Desktop Cluster

HTTPS/PCoIP

DMZ (HTTPS/PCoIP)

PCoIPESX, vCenter, View, Mirage, AD tra�cNFS Storage

View Virtual Desktops

Management Cluster

View Security Servers

Thin Client

HorizonClients

PCMac OS

iOS/Android

Kiosk

MSSQL

ActiveDirectory

SSD

Figure 4: Horizon with View Components



Hardware Components

This section provides an overview of the hardware components of the architecture.

Extreme Summit x670 10GbE

Desktop & RD Session Hosts5 x Supermicro 2027TR Chassis11 x Supermicro X9DRT-HF System Boards for VDI9 x Supermicro X9DRT-HF System Boards for RDSH16 Cores, 128 GB RAM

EMC VNX 5500Horizon 6 Server WorkloadsLinked-Clone DesktopsFull-Clone DesktopsRD Session HostsUser Pro�lesUser DataThinApp RepositoryMirage Single-Instance Store

Management Hosts1 x Supermicro 2027TR Chassis3 x Supermicro X9DRT-HF System Boards16 Cores, 128 GB RAM - Horizon 6 Server Workload VMs

VDI & RDSH VMs

Figure 5: Hardware Components

ServerSupermicro 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

NetworkThe 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

T E C H N I C A L W H I T E PA P E R / 1 0


StorageAll 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 enterprise-level 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 vSphereVMware 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 ViewHorizon 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.

http://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-virtual-san-reference-architecture.pdf




VMware Mirage

VMware Workspace Portal

Core Infrastructure

vRealize Operations

Manager

Active Directory

vCenterServer

View

View ConnectionServer

ViewComposer

View SecurityServer

Windows 7Full Clone

Windows 7Linked Clone

Windows 73D Desktop

Full-Clone and Linked-CloneVirtual Desktop Pools

RDSH-HostedDesktops and Applications

SaaS Apps

VMware WorkspacePortal VA

ThinApp Repository

Physical/ContainerizedDesktops

VMware MirageServers

Figure 6: Horizon 6 Components



Horizon 6 Reference ArchitectureThe 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

Switched Ethernet Network

Server Cluster

vRealize OperationsManager

View SecurityServer

View SecurityServer

View Connection Server View Connection Server

vCenter Server and View Composer

Horizon Management Block

WorkspacePortal

MirageManagement

Server

MirageServer

View Desktop Pools

Desktop Cluster

View RDSH Desktop Pools

Desktop Cluster

Shared Storage

Desktop Block

Figure 7: Horizon Pod and Management Block



Horizon PodA 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 BlockThe 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.



The management block has a single vSphere cluster that supports the Horizon server virtual machines shown in Figure 8.

vSphere Cluster

vCenter Server 2x ViewSecurity Server

2x Workspace PortalVA

ViewComposer

2x View (Int.)Connection Server

2x View (Ext.)Connection Server

vRealize OperationsManager UI VA

2x MirageServer

Mirage Management

Server

vRealize OperationsManager Analytics VA

3x ESXi 5.5 Host2.1 GHz. 128 GB RAM

2x 2 TB LUNEMC VNX5500 NFS

SQL Server ActiveDirectory

TEMP, ISO LUNEMC VNX5500 NFS

Figure 8: VMware vSphere Cluster

Desktop BlocksIn 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.



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.

ESXi DesktopCluster

Windows 7Full-Clone Pool –

200 Desktops

Management BlockvCenter

Windows 7Linked-Clone Pool –

800 Desktops

11x ESXi 5.5 Host2.9 GHz, 128 GB RAM

6x 2 TB LUNEMC VNX5500

NFS

32x RemoteDesktop Services

Host

TEMP, ISO LUNSEMC VNX5500 NFS

ESXi DesktopCluster

9x ESXi 5.5 Host2.9 GHz, 128 GB RAM

4x 1 TB LUNEMC VNX5500

NFS

Figure 9: Desktop Block Logical Infrastructure Design



Software-Defined Data Center

Horizon leverages the VMware SDDC platform to ensure performance, security, manageability, scalability, availability, and reliability.

Horizon 6

VMware vSphere

vSGA /vDGA

LinkedClones

VirtualSAN

NetworkSpeci�cations

SESparse

DiskCBRC VAAI

Availability

ApplicationServices

Security Scalability

vMotionStorage vMotionHAFault ToleranceData Recovery

vShield ZonesVMsafe

DRSHot Add

vCompute

InfrastructureServices

vStorage vNetwork

ESX and ESXiDRS and DPMMemoryOvercommit

VMFSThin ProvisioningStorage I/O Control

Distributed SwitchNetwork 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.



NetworkingThe 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.

StorageThis reference architecture leverages an existing EMC VNX5500 storage system to host all linked-clone and full-clone 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 Horizon Management Cluster

2x 300 GBSSD

4x 1 TB RD Session

Hosts10GbE 10GbE

6x 2 TB Full Clones,

Linked Clones, Linked-Clone

ReplicasEMC VNX5500

NFS

2x 2 TBAll Servers

1x 490 GB ISO1x 1 TB TEMP

EMC VNX5500NFS

2x 300 GB SSD

Figure 11: Storage Options





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 WorkloadsAll 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 WorkloadsStorage 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



Virtual Desktop Storage WorkloadWhen 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)

(135 x 10 IOPS) + (34 x 20 IOPS) =1350 IOPS + 680 IOPS = 2030 IOPS

Average throughput per virtual machine (normal user)

200 KBps (estimated)

Average throughput per virtual machine (heavy user)

300 KBps (estimated)

Total throughput (80% normal user, 20% heavy user)

(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)

1421 + (609 x 4) = 3857 IOPS (RAID 5)1421 + (609 x 2) = 2639 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 18–43 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.



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 MBFree space allocation – 10% additional overhead

Minimum allocated datastore size:1.47 TB (34 virtual machines * (40960 + 256 +10) + 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.


OS disks per datastore 64–128 VMFS140 with VAAI250+ 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 MBLog file size (max) – 10 MBMaximum VMDK growth – 1024 MB (optimistic)Free space allocation – 10% additional overhead

Minimum allocated datastore size:376 GB (134 virtual machines * (256 + 1024 + 10 + 1024) + 40 GB replica + 10% free space overhead)

Swap file can be eliminated or reduced by reserving memory for all virtual desktops.





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.


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 GBLog file size (max) – 10 MBFree space allocation – 10% additional overhead

Minimum allocated datastore size:524 GB (8 virtual machines * (40960 + 24576 +10) + 10% free space overhead)

Spare capacity is available if RDSH servers need to be larger than 40 GB.


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



ESXi HostsThis 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)



VMware testing and field experience shows that customers can expect anywhere from 5–10 1 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 RECORDED VALUE

Average number of CPUs per physical desktop system

1

Average CPU utilization per physical desktop system 350 MHz

vCPU overhead 10%

ATTRIBUTE SPECIFICATION

Number of CPUs (sockets) per host 2

Number of cores per CPU 8

GHz per CPU core 2.9 GHz

Total GHz per CPU 23.2 GHz

Total CPU GHz per host 46.4 GHz

Proposed maximum host CPU utilization 80%

Available CPU GHz per host 37.12 GHz

Virtual machines per host ~100 (37.12 GHz / 385 MHz)

Total ESXi hosts required 10 (+1 for HA)

Table 6: ESXi Host CPU Requirements



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.


Total amount of RAM per virtual machine 1024 MB

Memory reservation 25% (256 MB)

Resolution 1920 x 1600 (1 monitor)

Memory overhead per virtual machine 41 MB

Total RAM required for desktop virtual machines 104 GB

Total RAM required per host (100 virtual machines) 128 GB

Impact of additional host for HA purposes 10% saving

Anticipated savings from transparent page sharing (in event of a host failure)

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



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.


Total amount of RAM per RDSH session 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 41 MB

Total RAM required per ESXi host 64 GB

Total RAM allocated per RDSH 24 GB

Total RAM required per host 97 GB

Proposed maximum host memory usage 80%

Total amount of RAM per host 128 GB

Table 8: RDSH Memory Sizing for Light Workloads



VMware vCenter ServerVMware 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 4 vCPUs

vRAM 24 GB

Storage 100 GB

Table 9: VMware vCenter Server Configuration

VMware vSphere ClustersThe 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



Virtual NetworkingIn 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.

RDSHVirtual

DesktopServer

Workloads

EMC VNXNFS

VMNet-172

dvSwitch1

10GbENICs

Management

VMNet-10

vMotion

vmk

ExternalWorkloads

Storage

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.



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



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.

ArchitectureVMware 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.

vSphere metrics(ESXi, VM, datastore,

data center)

Objects, metrics, KPIs,alert, events

Desktop metrics(PCoIP, CPU, memory,

disk, session info)

View topologyand events

Desktop VMs

vRealize Operations Manager 5.7 vApp

vRealize Operations Manager Console (Browser)

Database ServerView Connection Server

View EventsDatabase

View Adapter

Custom UI

vRealize Operations Manager Enterprise

View Adapter 1

V4H DesktopAgent

V4H DesktopAgent

vCenterServer

View Dashboards

Figure 15: VMware vRealize Operations for Horizon Architecture



ComponentsVMware 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

ConfigurationVMware 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.

http://pubs.vmware.com/vcops-view-15/topic/com.vmware.ICbase/PDF/vcops-view-15-installation-guide.pdf



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.

ArchitectureWorkspace 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.



View RDSH Apps and Desktops

View VirtualDesktops

HTTPS

HTTPS (DMZ)View, Workspace Portal Tra�c

Private Cloud (vSphere)

Management Cluster

External Load Balancer

Internal Load Balancer

https://myworkspace.company.com https://myworkspace.company.com

Workspace Portal VA x 2

Thin Client

HorizonClients

PCMac OS

iOS/Android

Kiosk

ActiveDirectory

ViewConnection

Servers

ThinAppRepository

Oracle/vPostgres Database

Figure 17: Workspace Portal Architecture



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.

ComponentsWorkspace Portal 2.1 is composed of a single virtual appliance that can be duplicated for scaling purposes.

API

OS (SLES)

ConnectorServices

tcserver DB

API

OS (SLES)

ConnectorServices

tcserver DB

API

Workspace Portal VA

OS (SLES)

Connector ServicesCore Services

tcserver DB (vPostgres)

API

Workspace Portal VA

Workspace Portal VA

Workspace Portal VA

OS (SLES)

ConnectorServices

tcserver DB

Application Proxy / Reverse Proxy

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



ConfigurationWorkspace 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.

ArchitectureView 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.



vRealize Operations for Horizon

ViewComposer

ConnectionServers

DesktopAdmin

vSphereAdmin

ViewAdministrator

Console

vSphereClient

File/Print/ThinAppSecurityServers

vCenter

VirtualDesktops

ActiveDirectory

HTTPS TCP 443PCoIP (Direct)UDP 4172

PCoIP UDP 4172HTTPS TCP 443

RDSHServers

SQL

VMware ESXi


VMware ESXi

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.



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.

ComponentsView 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)

4 16 50 GB

View security server 4 (2 per external View Connection Server)

4 16 40 GB

View Composer 1 4 16 30 GB



COMPONENT QUANTITY VCPU VRAM HDD

File print server 1 4 10 140 GB

SQL Server 1 4 16 140 GB

RDSH server 32 4 24 40 GB

Windows 7 desktops 1,000 1 1 40 GB

Table 13: Sizing for View Deployment of 2,000 Users

ConfigurationYou 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 PoliciesView 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 SettingsAll 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 SettingsvCenter 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.

ResourcesThe 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.



Virtual Desktop Machine Image BuildA 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.


Desktop OS Windows 7 Enterprise SP1 (32-bit)

Hardware VMware virtual hardware version 9

CPU 1

Memory 1024 MB

Memory reserved 256 MB

Video RAM Up to 128 MB

3D graphics Off

NICs 1

Virtual network adapter 1 VMXNet3 Adapter

Virtual SCSI controller 0 LSI Logic SAS

Virtual disk – VMDK 40 GB

Table 14: Windows 7 Golden Image Virtual Machine Specifications

http://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdf


https://my.vmware.com/web/vmware/details%3FdownloadGroup%3DVIEW-PLAN-300%26productId%3D320

https://my.vmware.com/web/vmware/details%3FdownloadGroup%3DVIEW-PLAN-300%26productId%3D320



Remote Desktop Services Host ConfigurationThe 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.


Desktop OS Windows Server 2012 R2

Hardware VMware virtual hardware version 9

CPU 4

Memory 24 GB

Memory reserved 0 MB

Video RAM 128 MB

NICs 1



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.

http://www.vmware.com/files/pdf/techpaper/vmware-horizon-mirage-reference-architecture-branch-office.pdf



ArchitectureMirage 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).

Virtual Desktop(Full Clone)

SQL

MirageWindows

File ServerMirageServer

MirageAdmin

MirageEdge Gateway

MirageConsole

MirageManagement

Server

MirageServer

ExternalPhysicalEndpoints

PhysicalEndpoints

ActiveDirectory


VMware ESXiVMware ESXi

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



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

1 4 16 190 GB

Mirage Server 1 4 16 190 GB

SQL Server Uses the same SQL Server as View (see SQL Server section for sizing)

Mirage Single-Instance Store 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

ConfigurationFor 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.



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.




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 LayerCapturing

Mirage Server

Full-Clone Pool

Mirage ManagementServer

App Layer

Base Layer

App Layer

User-De�ned

Layer(Optional)

Base Layer

App Layer

Base Layer

App Layer

Base Layer

ReferenceCVD VM

VM-1 VM-2 VM-n Template VM

App Layer

Base Layer

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.



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 FeaturesWith 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.



PCoIP SettingsPCoIP 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 DataTo 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 PersistenceFor 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.



Integration

This section details the integration considerations for this reference architecture.

Active DirectoryThe 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



VMware SQL ServerVMware 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.


Version 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 disk – VMDK 40 GB Windows OS100 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.


Vendor and version Microsoft SQL Server 2008 R2 Standard

Authentication method SQL authentication

Recovery method Simple

Database autogrowth Enabled in 1 MB increments

Transaction log autogrowth In 10% increments, restricted to 2 GB maximum

Database size 5 GB

Table 18: View Composer and Events Database Specifications

http://www.vmware.com/files/pdf/techpaper/VMware-vCenter-DBPerfBestPractices.pdf




The following settings were used to create the Mirage database.


Vendor and version Microsoft SQL Server 2008 R2 Standard

Authentication method SQL authentication

Recovery method Simple

Database autogrowth Enabled in 1 MB increments

Transaction log autogrowth In 10% increments, restricted to 2 GB maximum

Database size <1 GB

Table 19: Mirage Database Specifications

Windows File ServicesView, 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.


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 SCSI controller 0 LSI Logic Parallel




Virtual disk – VMDK 40 GB Windows OS100 GB data disk:User home drives – \HomeDrivesView Persona – \PersonaRDS profiles – \RDSProfilesMirage Single Instance Store – \MirageThinApps – \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.


Workspace Portal Gateway

Multiple Gateway virtual appliances provide a highly available access solution. A third-party load balancer is required.

Workspace Portal Service virtual appliance

Multiple Service virtual appliances provide a highly available Workspace Portal solution. No load balancer is required.

Workspace Portal Connector virtual appliance

Multiple Connector virtual appliances provide a highly available Workspace Portal solution. No load balancer is required.

Mirage server failure 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.

View security server 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.

View Connection Server 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.

View desktop 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.

RD Session Host 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.

vCenter Server 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.




ESXi host 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.

View desktop cluster failure

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.

Management cluster failure

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



Test ResultsTesting 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


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



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


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


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)


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)


Clicking a View desktop in Horizon Client after user login presents the desktop to the user

PASSED

Access any virtual desktop from Workspace Portal


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


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



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 0.513369 seconds, and Group B scored 4.023978 seconds.



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: 0.513369 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: 4.023978 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



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



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 DesktopsA 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



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



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



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



Appendix A: Bill of Materials

Extreme Summit x670 10GbE

Desktop & RD Session Hosts5 x Supermicro 2027TR Chassis11 x Supermicro X9DRT-HF System Boards for VDI9 x Supermicro X9DRT-HF System Boards for RDSH16 Cores, 128 GB RAM

EMC VNX 5500Horizon 6 Server WorkloadsLinked-Clone DesktopsFull-Clone DesktopsRD Session HostsUser Pro�lesUser DataThinApp RepositoryMirage Single-Instance Store

Management Hosts1 x Supermicro 2027TR Chassis3 x Supermicro X9DRT-HF System Boards16 Cores, 128 GB RAM - Horizon 6 Server Workload VMs

VDI & RDSH 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 E5 2690 2.9 GHz 8-core, 128 GB RAM)

20

Supermicro X90RT-HF system boards(2 x Intel E5 2658 2.1 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



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



Appendix B: View Planner 3.5The 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.

Storage

PhysicalServers

WebInterface

VMware vCenter View

Harness

Virtual Client VMs

RemoteDisplay

Protocol

ViewPlanner Appliance Manage

Desktop Management

Client Management

Storage

PhysicalServers

Virtual Desktops

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



GROUP A GROUP B GROUP C

AdobeReader: Minimize Firefox: Open

Excel_Sort: Close IE_ApacheDoc: Open

Excel_Sort: Compute IE_WebAlbum: Open

Excel_Sort: Entry PowerPoint: Open

Excel_Sort: Maximize Word: Open

Excel_Sort: Minimize Word: Save

Firefox: Close

IE_ApacheDoc: Browse

IE_ApacheDoc: Close

IE_WebAlbum: Browse

IE_WebAlbum: Close

PowerPoint: AppendSlides

PowerPoint: Close

PowerPoint: Maximize

PowerPoint: Minimize

PowerPoint: ModifySlides

PowerPoint: RunSlideShow

Word: Close

Word: Maximize

Word: Minimize

Word: Modify

Table 25: View Planner Operations



Run Phases

For this test, View Planner performed a total of five iterations:

•Ramp up (first iteration)

•Steady state (second, third, fourth iterations)

•Ramp down (fifth iteration)

During each iteration, View Planner reported the latency for each operation performed within each virtual machine.

Quality of Service

QoS, determined separately for Group A user operations and Group B user operations, is the 95th percentile latency of all the operations in a group. The default thresholds are 1.0 seconds for Group A, and 6.0 seconds for Group B.

VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.comCopyright © 2015 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed athttp://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. Item No: VMW-TWP-HORIZ6REFERENCEARCH-USLET-20150625-WEB


ReferencesVMware Product Page

View Documentation

View Technical Resources

VMware End-User Computing Solutions

VMware Desktop Virtualization Services

Horizon with View Optimization Guide for Windows 7 and Windows 8

Antivirus Best Practices for Horizon View 5.x

View Planner 3 Resources

View Storage Accelerator

VMware vCenter Database Performance Improvements and Best Practices for Large-Scale Environments

http://www.vmware.com/products

https://www.vmware.com/support/pubs/view_pubs.html

http://www.vmware.com/products/desktop_virtualization/view/technical-resources.html

http://www.vmware.com/solutions/desktop

http://www.vmware.com/consulting/

http://www.vmware.com/resources/techresources/10157


http://www.vmware.com/products/view-planner



VMware Horizon 6 Reference · PDF fileVMware Horizon 6 Reference Architecture ... using...

Documents

Transcript of VMware Horizon 6 Reference · PDF fileVMware Horizon 6 Reference Architecture ... using...