IBM SoftLayer with VMware Horizon VDI D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H

IBM SoftLayer with VMware Horizon VDI D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H

Table of Contents 1. EUC ARCHITECTURE OVERVIEW... 5 2. VMWARE HORIZON 7 ARCHITECTURE... 7 2.1 VMWARE HORIZON 7 ARCHITECTURAL OVERVIEW... 8 2.2 VMWARE HORIZON 7 MANAGEMENT BLOCK... 9 2.3 MULTIPLE SITE AND POD DESIGN... 10 2.3.1 Cloud Pod Architecture Overview... 10 2.4 VMWARE HORIZON 7 POOL OVERVIEW... 11 2.4.1 Virtual Desktop Pool Types... 11 2.4.2 RDSH Pools... 11 2.5 VIRTUAL DESKTOP BLOCK DESIGN... 11 2.5.1 Desktop Pool Settings... 12 2.6 RDS HOSTED DESKTOPS AND APPLICATIONS BLOCK DESIGN... 13 2.7 CLOUD POD ARCHITECTURE DESIGN... 13 3. ACCESS LAYER ARCHITECTURE... 15 3.1 ACCESS OPTIONS... 15 3.2 INTERNAL CONNECTIONS... 15 3.3 CONNECTIONS FROM UNTRUSTED NETWORKS... 15 3.4 VMWARE HORIZON 7 AGENT DIRECT CONNECTIONS OVERVIEW... 16 3.4.1 Design... 17 4. INTEGRATION OF SUPPORTING INFRASTRUCTURE... 18 4.1 FILE SHARES... 18 4.2 ACTIVE DIRECTORY... 18 4.2.1 Active Directory Standards... 18 4.3 DATABASES... 19 5. VSPHERE INTEGRATION... 20 5.1 MANAGEMENT BLOCK INTEGRATION... 20 5.2 DESKTOP BLOCK INTEGRATION... 20 5.3 RDS BLOCK INTEGRATION... 21 6. STORAGE... 22 6.1 OVERVIEW... 22 6.2 VMWARE HORIZON 7 DISK TYPES... 22 6.3 RDSH APPLICATION FARM LINKED-CLONE SPACE REQUIREMENTS... 23 7. NETWORKING... 25 7.1 OVERVIEW... 25 7.2 DNS, DHCP, AND SUBNET CONFIGURATION... 25 7.3 BANDWIDTH AND LATENCY CONSIDERATIONS... 25 7.4 NETWORK CIRCUIT REQUIREMENTS... 26 7.5 OPTIMAL CONFIGURATION OF WANS FOR REMOTE PROTOCOLS... 26 7.6 LOAD BALANCING AND TRAFFIC MANAGEMENT... 27 7.7 VMWARE HORIZON 7 NETWORK PORTS AND PROTOCOLS... 28 8. OPERATING SYSTEM SECURITY... 29 8.1 OVERVIEW... 29 8.2 ANTIVIRUS AND ANTI-MALWARE... 29 8.2.1 Guest Agent Based Antivirus... 29 8.2.2 View Connection Server Antivirus Considerations... 29 8.3 VMWARE NSX WITH VSHIELD ENDPOINT... 30 9. MANAGEMENT OF USER ENVIRONMENT... 31 D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 1

9.1 OVERVIEW... 31 9.2 SMART POLICIES... 31 10. GRAPHICS ACCELERATION... 32 10.1 OVERVIEW... 32 11. MULTIMEDIA ENHANCEMENTS... 34 11.1 OVERVIEW... 34 11.2 REAL-TIME AUDIO-VIDEO... 34 12. AVAILABILITY, BUSINESS CONTINUITY, AND RECOVERY... 34 12.1 OVERVIEW... 34 12.2 DISASTER RECOVERY... 34 APPENDIX A: RESOURCES... 36 Tables TABLE 1. VMWARE HORIZON 7 DISK TYPES... 22 TABLE 2. STORAGE SIZING FORMULA FOR LINKED CLONE DISKS ON SELECTED DATASTORE... 23 TABLE 3. STORAGE SIZING FORMULA FOR LINKED-CLONE WHEN THE POOL IS EDITED OR REPLICA IS STORED ON DIFFERENT DATASTORE... 24 TABLE 4. LOAD BALANCER REQUIREMENTS... 27 TABLE 5. EXTERNAL HORIZON SMART POLICIES... 31 TABLE 6. INTERNAL HORIZON SMART POLICIES... 31 TABLE 7. 3D GRAPHICS OPTIONS... 32 TABLE 8. 3D RENDERING OPTIONS... 32 TABLE 9. DISASTER RECOVERY DESIGN DECISIONS... 34 Figures FIGURE 1. EUC HIGH-LEVEL ARCHITECTURAL COMPONENTS...5 FIGURE 2. VMWARE HORIZON 7 CONCEPTUAL ARCHITECTURE...7 FIGURE 3. VIEW POD AND BLOCK OVERVIEW...8 FIGURE 4. VMWARE HORIZON 7 MANAGEMENT BLOCK...9 FIGURE 5. VMWARE HORIZON 7 POD LOGICAL DESIGN... 10 FIGURE 6. VMWARE HORIZON 7 DESKTOP BLOCK LOGICAL INFRASTRUCTURE... 12 FIGURE 7. VMWARE HORIZON 7 RDS HOST BLOCK LOGICAL INFRASTRUCTURE DESIGN... 13 FIGURE 8. CLOUD POD ARCHICTURE CONCEPTUAL DIAGRAM... 14 FIGURE 8. INTERNAL CONNECTIONS... 15 FIGURE 9. VMWARE HORIZON 7 ARCHITECTURE EXTERNAL/REMOTE UNTRUSTED CONNECTIONS... 15 FIGURE 11. VMWARE VIEW ARCHITECTURE DIRECT-CONNECTION ACCESS BRANCH OFFICE... 17 FIGURE 12. VIRTUAL DESKTOP DOMAIN STRUCTURE... 18 FIGURE 13. DESKTOP BLOCK CLUSTER DESIGN... 20 FIGURE 14. RDS BLOCK CLUSTER DESIGN... 21 FIGURE 15. RDSH APPLICATION FARM LINKED-CLONE STORAGE DIAGRAM... 23 FIGURE 16. VMWARE HORIZON 7 NETWORK PORTS AND PROTOCOLS... 28 FIGURE 17. VMWARE NSX DATA SECURITY INTEGRATION... 30 D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 2

Introduction This deployment guide is intended as a guide to facilitate VMware Horizon Virtual Desktop Infrastructure workloads on IBM SoftLayer hosted bare metal servers running VMware vsphere. It intends to cover the use case, toolset required and technology elements to deliver this solution at a high level. Low level design and detailed configuration options will still be required for deployment. About the authors Andrew Haschka is a Regional Technical Alliance Manager across Asia Pacific and Japan in the VMware Centre of Excellence. He has a long history of working with customers and partners as a lead architect developing technical solutions to business requirements. Prashant Pandey is EUC Solution Architect across Asia Pacific and Japan in the VMware Centre of Excellence. He has lead multiple engagement with customer and partners on EUC and Data Centre architecture solutions over the period of his professional tenure. Version Control Date Version Author Comment Reviewers 02/09/2016 0.1 Andrew Haschka Draft Prashant Pandey 03/10/2016 0.2 Prashant Pandey Draft updates Andrew Haschka 12/10/2016 0.3 Andrew Haschka Pre-release review and minor updates 14/10/2016 0.4 Andrew Haschka Review for inconsistencies Prashant Pandey 20/10/2016 0.5 Prashant Pandey Review for inconsistencies Andrew Haschka 21/10/2016 0.6 Andrew Haschka Final review Prashant Pandey 26/10/2016 1.0 Andrew Haschka Version 1.0 release D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 3

Audience This document is intended to assist enterprise architects, solution architects, sales engineers, field consultants, advanced services specialists, and customers responsible for infrastructure services. This can be used as a guide to build a capability to deploy VMware Virtual Desktop workloads on a hosted IBM SoftLayer environment running VMware vsphere. This document assumes the implementer has prior knowledge of VMware vsphere, VMware Horizon and IBM SoftLayer/VMware on IBM Cloud. Architecture details for the baseline VMware and IBM SoftLayer platform hosting this solution are documented here; https://developer.ibm.com/architecture/virtualization https://developer.ibm.com/architecture/pdfs/vmware_on_ibm_cloud-standard.pdf D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 4

1. EUC Architecture Overview This section describes the high-level components that form the EUC target architecture necessary to meet business objectives as defined by the customer. Figure 1. EUC High-Level Architectural Components The components of this EUC architecture, as shown in the figure, and latest available features are summarized below: VMware vsphere with VMware vcenter Hypervisor and management framework that will provide foundational virtual machine infrastructure. VMware Horizon 7 Virtual desktop and application provisioning and management infrastructure that will deliver virtualized desktops and applications to users using robust communications protocols for an optimized, superior end-user experience to any device on any network. Just-in-Time Desktops: The pioneering instant clone technology couple with AppVolumes accelerates the delivery of user-customized and fully personalized desktop. Along with enhanced security benefit, the benefits of this features are: Reap the economic benefits of stateless, non-persistent virtual desktops served upto to date on each login. Deliver pristine, high-performance personalized desktop to end users every time they login. Improve security by destroying desktops everytime users log out. VMware App Volumes Provides real-time application delivery and management without the need to package or sequence applications. Quickly provision applications at scale Dynamically attach applications to users,groups or devices, even when the users are logged in to their desktops. Provision, deliver, update and applications in real time. Provide a user-writable volume allowing users to install applications that follows them across. VMware User Environment Manager Offers personalization and dynamic policy configuration across any virtual, physical and cloud-based environment. Provides end users with quick access to windows workspace and applications, with personalized and consistent experience across devices and locations. Simplify end-user profile management by providing organisation with single and scalable solution that leverages existing infrastructure. Speed up login process by applying configuration and environment settings in asynchronous fashion. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 5

Provide dynamic configuration environment configuration, such as drive, printer mappings when user launches an application. VMware Identity Manager Streamline the end-user experience and reduce costs with a single workspace for centralized application access, delivered securely on any device. VMware vrealize Operations Manager for Horizon Monitor and optimize the health, performance, and efficiency of the entire EUC stack. Blast Extreme - Purpose-built additional display technology is built on industry-standard H.264, delivering a high-performance graphics experience accessible on billions of devices including ultra-low-cost PCs. Multi-codec Blast Extreme supports the JPG/PNG and H.264 codecs. Multi-protocol - Supports both TCP and UDP transport protocols. This document describes the VMware Horizon 7 components of this solution. Other components of the solution, such as App Volumes, are described in detail in separate documentation. Shared infrastructure, management, automation, vsphere, underlying hardware, client access devices, and so on are referenced throughout this design document in order to understand how this design integrates with the infrastructure. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 6

2. VMware Horizon 7 Architecture The following diagram provides a high-level overview of the proposed architecture for VMware Horizon 7. This architecture is designed to address the use cases described in the Solution Requirements document and can serve as a design blueprint for extending capacity in the future. Figure 2. VMware Horizon 7 Conceptual Architecture The design is based upon both new components and existing infrastructure. The key technology used in this design and its primary purpose is summarized below View Connection Server instances provide the core management capabilities, such as brokering access to user resources, pool creation, user entitlements, authentication, runtime management, and policy configuration. Cloud Pod Architecture will be used to scale the design blueprint to multiple VMware Horizon View instances. View security servers or Access Point servers will proxy external client connections. Microsoft Windows 10 or Windows 2012 will be used as the centrally hosted client operating system accessed through VMware Horizon 7. Windows 10 provides single user/vm sessions. Windows 2012 RDS hosts provide access for multiple users. Integration with the View Connection Server instances and user access is provided through the VMware View Agent that is installed within each VM. Virtual desktops will be provisioned using either VMware View Composer or Instant Clone, depending on the use case that a pool is serving to address. This architecture provides the flexibility to deliver applications to users in the most flexible way depending on the use case. Application deployment can be a combination of the customer s existing SCCM for golden images with App Volumes and ThinApp for dynamic application deployment. A combination of dedicated vsphere instances and VMware ESXi clusters will be used for the purpose of workload separation of client operating system instances and management infrastructure. Internal connections will be made directly from the client access device to the centrally hosted resources. Blast Extreme will be the preferred communication protocol used for desktop and application access. RDP can be used for virtual or RDS hosted desktop access if necessary. PCoIP protocol will also be available through a compatible browser for clientless endpoints. User settings will be managed using standard Microsoft Windows user profiles. VMware Identity Manager shall be used to provide a common portal for user access to VMware Horizon 7 resources. Single sign-on for VMware Identity Manager can be implemented through True SSO with enrollment servers. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 7

2.1 VMware Horizon 7 Architectural Overview Figure 3. View Pod and Block Overview The VMware Horizon 7 architecture is designed, built, managed, and scaled using logical constructs known as pods (item 1 in Figure 3). A VMware Horizon pod is demarcated by View Connection Server instances that manage up to 10,000 active sessions. VMware Horizon pods can contain multiple instances of VMware vcenter Server, RDS hosts delivering shared virtual desktops and seamless applications, View Connection Server instances and security servers, and shared storage that can span multiple clusters. The pod is comprised of the following components: VMware Horizon 7 View Connection Server instances A minimum of two and a maximum of seven View Connection Server instances are present in a single View pod. All View Connection Server instances replicate inventory and configuration data among their partners. View Connection Server instances operate in an active configuration and should be placed behind a load balancer. Any View Connection Server instances can provide administrative responsibilities and connection brokering. VMware Horizon 7 security servers or Access Point servers These servers can be used for remote access connections by proxying connections to desktops. A minimum of two are required for redundancy. Additional servers can be added for capacity. VMware Horizon 7 blocks This design will contain multiple blocks. Details about the logical design of each block are provided in the following section. The VMware Horizon 7 block (items 2 and 3 in Figure 3) is a logical component of a pod. VMware Horizon 7 blocks are demarcated by vsphere instances. A VMware Horizon 7 block is comprised of the following components: View Connection Server In this design, there are at least two View Connection Server instances per VMware Horizon 7 block. ESXi hosts A VMware Horizon 7 block always has at least one ESXi host to run the user operating systems. vsphere clusters vsphere clusters that contain the ESXi hosts. A pool cannot extend beyond the boundary of a vsphere cluster. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 8

Pools Every VMware Horizon 7 block contains at least one pool of user operating system instances, either desktops or RDSH servers. Shared and local storage Shared datastore(s) accessible to all ESXi hosts in the block. A VMware Horizon 7 management block (item 4 in Figure 3) is demarcated by the vsphere cluster that hosts only the management server components for the pod, such as View Connection Server instances, View security servers, and vcenter Server instances supporting desktop/rdsh blocks. User workloads do not sit within the management block. 2.2 VMware Horizon 7 Management Block Figure 4. VMware Horizon 7 Management Block The Horizon 7 management block hosts the View desktop block vcenter Server instances, View Connection Server instances, View security servers, appvolume/uem servers, vrops for Horizon and access point servers. The VMware Horizon 7 Architectural Overview provides a description of the purpose and function of the management block. The View management hosts must be in the same data center as the View desktop hosts. The Java Message Service (JMS) used by the View Connection Server instances is not tolerant of network latency between View Connection Server instances. Furthermore, spanning View instances across Wide Area Networks (WANs) or Metropolitan Area Networks (MANs) is not supported, and will result in the failure of View Active Directory Lightweight Directory Service (ADLDS) database replication. The vcenter that manages the management block is placed on the customer s existing infrastructure. This design has the following components in the management block: ESXi hosts and clusters A dedicated cluster of ESXi hosts to run the VMware Horizon 7 server components. vcenter Server instances for managing desktop blocks, together with associated VMware Update Manager servers. View Connection Server instances Multiple View Connection Server instances are required for the design. A load balancer should be utilized to balance user connections between the View Connection Server instances. A maximum of seven View Connection Server instances can be implemented in a VMware Horizon 7 pod. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 9

View security servers/access point Multiple View security servers are required for the design. A load balancer should be utilized to balance user connections between the security servers/access point. 2.3 Multiple Site and Pod Design Figure 5. VMware Horizon 7 Pod Logical Design This architecture will have multiple View pods across different sites. For the implementation to be transparent to users, the scalable and manageable Cloud Pod Architecture (CPA), together with the customer s network load-balancing solution, can be used. CPA greatly enhances the scaling and manageability of the customer s VMware Horizon 7 solution, but it does not provide full multi-site resiliency by itself. 2.3.1 Cloud Pod Architecture Overview For the reasons stated in the previous section, this architecture will use CPA to link pods across WANs or between other non-lan connected sites. For ease of management, CPA will also be used to link pods in the same data center. In such an environment, an end user can connect to a View Connection Server in one pod and receive a desktop or hosted application from another pod. 2.3.1.1. Cloud Pod Architecture Components The components and concepts used with Cloud Pod Architecture are as follows: Sites In a CPA environment, a site is a collection of well-connected pods in the same physical location. These are treated equally by CPA. CPA assumes that pods within the same site are on the same LAN, and that pods in different sites are on different LANs. To reduce the impact of network performance, CPA gives preference to resources that are in the local pod or site when it allocates desktops to users. Global entitlements In a CPA environment, global entitlements are created to entitle users or groups to multiple desktops/applications across multiple pods in the pod federation. Global entitlements obviate the need to configure and manage local entitlements, simplifying administration. VMware Horizon 7 stores global entitlements in the global data layer, which is available on all pods. Scope On creation of global entitlements, the scope policy must be specified. The scope policy determines the scope of the search when View enumerates requests from users contained within global entitlements. Valid options are: o All sites VMware Horizon 7 looks for desktops on any pod in the pod federation. o Within site VMware Horizon 7 looks for desktops only on pods in the same site as the pod to which the user is connected. o Within pod VMware Horizon 7 looks for desktops only in the pod to which the user is connected. o Home site With home sites, View begins searching for desktops and applications from a specific site rather than searching for desktops and applications based on the user's current location. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 10

If the home site is unavailable or does not have resources to satisfy the user's request, View continues searching other sites according to the scope policy set for the global entitlement. For global desktop entitlements that contain dedicated pools, the home site affects where View looks for desktops the first time a user requests a dedicated desktop. After View allocates a dedicated desktop, it returns the user directly to the same desktop. There are two types of home site assignments: Global home site A home site assigned to a user or group. A user s group takes precedence. Per-global-entitlement home site A home site associated with a global entitlement. This overrides global home sites. The customer should be aware that CPA currently has a limit of 50 sessions, 25 pods, 5 data centers and 50 View Connection Server instances. 2.4 VMware Horizon 7 Pool Overview VMware Horizon 7 makes use of pools to simplify the management of resources that users can access by providing a single way of managing like resources, such as those that might have a common set of applications. 2.4.1 Virtual Desktop Pool Types There are two types of desktops pools as follows: Manual Virtual desktops available through View Connection Server. The VMware Horizon 7 administrator can control the power state of these virtual desktops. Manual desktop pools can be made up of VMs managed by vcenter, VMs hosted on non-vsphere platforms, or physical machines. Automated An automatic desktop pool consists of desktop sources that are managed by the VMware Horizon 7 administrator. They can be made up of the following sources: o Linked-clone virtual machines created automatically in vcenter using VMware View Composer. o Full-clone virtual machines created automatically in vcenter using a virtual machine template. o Instant-clone Virtual machines created automatically in vcenter using VMfork technology (No VMware View Composer required). Pool assignments can be either dedicated (automatic or manual assignment) or floating. Dedicated assignment Dedicated virtual desktops are assigned to their user on first use, so the user returns to the same virtual desktop on each login. This type of pool should be used when users want to customize their desktops by installing additional applications and storing local data. Floating assignment A pool of virtual desktops where virtual desktops are not permanently assigned to users. When a session is finished, the virtual desktop is returned to the pool and made available for other users. By optionally refreshing or deleting the virtual desktop after each use, this type of pool can verify that each user receives a newly provisioned virtual desktop on each login. This type of pool should be used when a clean machine is needed for each user session or in highly controlled environments where there is no requirement for customization to be stored on the virtual desktop. 2.4.2 RDSH Pools RDSH farms are collections of RDS enabled Windows Server operating systems. They can be either physical or virtual machines. RDS pools use RDS farms to deliver hosted desktops and applications to multiple instances of supported access devices and/or users. RDS farms can be used to silo applications for effective application performance and load management. The RDS hosts in the farm provide desktop and application sessions to users. RDS farms can be one of two types, manual or automated. RDS hosts in manual farms are made up of existing machines, physical or virtual. Automated farms are linked clones created by VMware View Composer. There are two types of RDS desktop pools RDSH desktop pool An RDS desktop pool is associated with an RDS farm. Each RDS host is a Windows Server that can host multiple RDS desktops supporting PCoIP or RDP. An RDS desktop is based on a session running on an RDS host. Application pool Application pools can be used to entitle users to applications that run on servers in a data center instead of on their personal computers or devices. Applications are delivered seamlessly to the client and appear as if they are running locally. Application pools offer several important benefits such as accessibility, device independence, access control, accelerated application deployment, ease of managing applications, security and compliance, and reduced costs. 2.5 Virtual Desktop Block Design Sizing the VMware Horizon 7 block architecture will vary depending on customer requirements. Cloud pod architecture with Horizon 7 scales to 5 sites, with 25 Pods and 50,000 connections. Although vcenter can D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 11

support up to 10,000 sessions, VMware recommends having each instance support approximately 2,000 sessions. This number was chosen because it provides a more manageable number for virtual machine maintenance and better scalability. This number can be increased with careful consideration. Some things to consider when sizing the VMware Horizon 7 block include, but are not limited to, the following: Risk of single point of failure Increasing the number of virtual desktops managed by a single vcenter Server in a large VMware Horizon 7 environment can create a single point of failure. Keeping the number of desktops lower can lessen the impact on the architecture as a whole in the event of a vcenter failure. Scalability Most customers will experience growth in their VMware Horizon 7 environment on a smaller scale, and expansion of the VMware Horizon 7 environment can be more cost effective when building out the environment in smaller, customer-defined building blocks than for 10,000 PCoIP sessions. Ease of management: The suggested number of 2000 makes is easy to do operation, maintenance and accounting on the set of users/desktops which are entitled for that pool. Figure 6. VMware Horizon 7 Desktop Block Logical Infrastructure Each View block consists of clusters for housing desktops. Each cluster will support approximately 2,000 virtual desktops using the provided virtual machine configuration. A dedicated vcenter instance will manage the clusters for each desktop block. If additional virtual machine configurations are established, VMware recommends grouping only similarly configured virtual machines within the same cluster. 2.5.1 Desktop Pool Settings This architecture will use two types of pools. For most user groups, the floating/automated desktop pool with linked clones or instant clone will be used. Images will be deployed from a parent image, updates will be made to the parent image when needed, and linked clones will be recomposed through predetermined maintenance windows, or on-demand, as needed. Instant clone will use the master and the parent VM s availability on each host and datastore to spawn desktops when the user logs in. The other pool type is a dedicated desktop pool with full/traditional virtual machines. This pool type will be used for those users who require custom desktops or require local application installations. The View manager will deploy these desktops, and the desktops are maintained individually as if they were physical desktops (using SCCM). D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 12

The detailed configuration of all desktop pools is described in the accompanying Configuration Workbook. 2.6 RDS Hosted Desktops and Applications Block Design The goal of this sizing is to consolidate as many sessions as possible on a particular infrastructure without sacrificing the quality. The fundamental of VDI design pool equally applies to RDSH block design.this VMware Horizon 7 architecture design has multiple VMware Horizon 7 RDS host blocks. Each block will be configured to support either RDS Hosted Applications or RDS hosted desktops. This represents a modular implementation based on recommended hardware configurations provided by VMware. This implementation will require at least one View Connection Server for every 2,000 active RDS sessions. Figure 7. VMware Horizon 7 RDS Host Block Logical Infrastructure Design 2.7 Cloud Pod Architecture Design For this archtiecture two VMware Horizon 7 pods will be deployed, one in each data center. Each data center will represent a CPA site. Through global entitlements, the customer will assign pools that span RDS desktops and virtual desktops between both data centers. Users will not be assigned a home site. Entitlements will be through Active Directory groups assigned to the global entitlement. The design configuration for Cloud Pod Architecture shall be done to cater of the one of the specific options of the below: Global roaming desktop This is a use case where the end user needs access to a desktop only to access their Windows-based applications. An end user can be located either in Location 1 or the Location 2 with an entitlement to a nonpersistent desktop pool. The end user gets a desktop in their connected pod (that is, close to their client location If they connect from Location 1, they get a desktop in Location 1). Global home desktop This is the typical case where the end user wants to get the same persistent desktop every time they request access, irrespective of their location. To accomplish this, persistent desktop pools in all pods need to be set up. The FromHome policy can be used to direct the user back to their home site. The end user gets the same desktop machine irrespective of which pod they are connected to. Local scale desktop In this use case, each site has multiple pods, each offering a standard nonpersistent desktop pool. A global entitlement layer provided by Cloud Pod Architecture joins all these pools together. Using the site s Scope policy, one can control and limit access to a desktop that is available within the site. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 13

The following diagram provides an overview of the Cloud Pod Architecture Figure 8. Cloud Pod Archicture Conceptual Diagram D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 14

3. Access Layer Architecture 3.1 Access Options The different types of components that the architecture will use to access the VMware Horizon 7 infrastructure are described in the following table in terms of access device, protocol, location, use case, authentication, and client. PCoIP, RDP, Blast Extreme, and Blast HTML access are the remote/display protocols that can be used by clients for accessing VMware Horizon 7 resources. This architecture plans to use the native Windows client on their existing Windows 7 devices, the mobile Android and ios clients, and on employee-owned devices, the HTML 5 Web client will be used. This architecture will use the following combinations of protocols, access devices, and locations to address the access requirements of all their use cases. 3.2 Internal Connections Internally, users will connect using the VMware Horizon Client installed on their existing desktops, using HTTPS to connect to the load-balanced View Connection Server pool. Next, users will select their entitled desktop or applications and launch a PCoIP or Blast Extreme connection to it. Figure 9. Internal Connections 3.3 Connections from Untrusted Networks Users connecting to the network from an untrusted location, such as a guest network or Internet, connect to their VMware Horizon 7 resources using the Horizon Client. Initial connections are made over HTTPS through a load balancer to the View security server. PCoIP or Blast Extreme connections are then made to the desktop or RDS server through the security server gateway. In this scenario, when connecting through a browser using the Web client, the client connects to the security server initially on port 443, and then the HTML Blast connection is established on port 8443, both using HTTPS. Connections are not made directly to the desktop or RDS server in this external scenario. They are proxied through the security server. Figure 10. VMware Horizon 7 Architecture External/Remote Untrusted Connections D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 15

3.4 VMware Horizon 7 Agent Direct Connections Overview To support the direct-connection capability without a View Connection Server, a VMware Horizon 7 software component called View Agent Direct-Connection (VADC) Plug-In can be installed on each VMware Horizon 7 desktop, alongside VMware Horizon 7 Agent. This component provides a subset of View Connection Server functionality, including PCoIP, RDP, USB redirection, sound, 3D, RTAV, Unity Touch, single sign-on, session management, and so on. All configuration settings for VMware Horizon 7 Agent Direct-Connection Plug-In are stored in the local registry on each VMware Horizon 7 desktop. The configuration settings can be managed through Group Policy. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 16

3.4.1 Design To achieve good user experience, this architecture will place a two-node ESXi cluster in each of the three branch offices, and configure the virtual desktops to use VMware Horizon 7 Agent Direct-Connection Plug-In. Users in these branch offices will be configured to connect directly to these local virtual desktops. The virtual desktops in the branch offices will be centrally provisioned and managed by View Connection Server instances in the data center. Figure 11. VMware View Architecture Direct-Connection Access Branch Office D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 17

4. Integration of Supporting Infrastructure This section explains the integration points with existing and shared infrastructure that is required for this solution. 4.1 File Shares SMB shares are used for shared drives, home drives, and roaming profiles. The design and implementation of these shares is out of scope for this design however available for extensibility. 4.2 Active Directory Many components of this design will be required to integrate with Active Directory for establishing user entitlements, authentication/authorization, and to make use of centrally managed Group Policy settings. View Connection Server includes administrative templates for managing VMware Horizon 7 virtual machines. Administrators can import these templates and apply policy settings to the respective Organizational Units (OUs) using a Group Policy Object (GPO). This provides a straightforward and consistent way to manage policies specific to VMware Horizon 7 virtual machines and users. 4.2.1 Active Directory Standards The following diagram outlines the domain structure that will be used for this virtual desktop deployment. In this design, user accounts are managed through the customer s domain. This domain will serve as the authentication domain for virtual desktop users and house virtual desktop computer accounts. Virtual desktops delivered through VMware Horizon 7 will be added to the appropriate OUs. GPOs will be applied at the virtual desktop OU level. Additional OUs and GPOs will be developed if needed (on an exception basis). Figure 12. Virtual Desktop Domain Structure D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 18

4.3 Databases The following databases are required for the VMware Horizon 7 components of this design: Database server A dedicated database server is utilized for this design. One database server is required for the management block, and one database server is required for each desktop block. The database server should be highly available. o o Database A database is required for the following VMware Horizon 7 components: One database per pod for the View events logging. One database for each desktop block's VMware View Composer server. The specification of databases that are not accessed directly by VMware Horizon 7 components, such as vcenter and VMware vsphere Update Manager, are not described because their design is out of scope. The availability, backup, and restore of these databases is handled by the customer s DBA team in a similar way to their other business critical highly available databases. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 19

5. vsphere Integration This section describes the vsphere integration for each VMware Horizon 7 block within this design. Underlying vsphere elements, such as vsphere Update Manager, SAN Fabric, physical networking, power, and cooling, are not specific to this VMware Horizon 7 design and are not included in this document. 5.1 Management Block Integration The management block will be hosted in the existing the customer s production vsphere environment. It is assumed that there are adequate spare resources in the existing vsphere environment to host the management block Server VMs. The customer will ensure that current capacity exists, or will expand the existing vsphere environment to support the server virtual machines required for this design. 5.2 Desktop Block Integration The desktop block will be hosted in a dedicated vsphere environment. The vsphere design settings for the desktop block are outlined in this section. Assessment tools utilized during the engagement calculated the host count and resource requirements for each use case. Figure 13. Desktop Block Cluster Design D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 20

5.3 RDS Block Integration The RDS block will be hosted in a dedicated vsphere environment. The vsphere design settings for the RDS block are outlined in this section. Assessment tools utilized during the engagement calculated the host count and resource requirements for each RDS use-case. Figure 14. RDS Block Cluster Design D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 21

6. Storage 6.1 Overview The following section outlines the storage configurations for the VMware Horizon 7 environment. Ancillary storage, such as ThinApp repositories, user home drive shares, and third-party user environment management systems, is not included in this section. The storage design requirements presented in this section remain the same regardless of the underlying storage technology. The configuration of the storage platform is out of scope for the VMware Horizon 7 design. 6.2 VMware Horizon 7 Disk Types The shared storage will provide a number of separate datastores for each specific VMware Horizon 7 requirement, such as virtual machine OS disk, user data, and template VMs. The different disks and possible datastores are shown in the following table. Table 1. VMware Horizon 7 Disk Types Disk Type Full Clone VM Disk (.vmdk) Linked-Clone OS Disk (.vmdk) Linked-Clone Replica Disk (replica-guid.vmdk) Linked-Clone Swap File (.vswp) Linked-Clone Persistent Data Disk (.vmdk) Locations and limitations Typically hosted on a shared datastore Up to 128 for traditional VMFS5-based datastores Up to 256 for traditional NFS-based datastores One per full-clone desktop Typically hosted on a shared datastore Up to 128 for traditional VMFS5-based datastores Up to 256 for traditional NFS-based datastores One per linked-clone desktop Typically hosted on a shared SSD datastore Up to 128 for traditional VMFS5-based datastores Up to 256 for traditional NFS-based datastores One per pool if replica is placed on separate shared datastore as that of the linked-clone OS disk One per datastore if replica is placed on same datastore as that of the linked-clone OS disk Same datastore as linked-clone OS disk Can be configured to use local datastore ESX VM memory swap file Same size as virtual memory, minus reservation Datastore selected during configuration Virtual disk for user profile; Attaches to linked-clone OS disk at logon for dedicated assignment pools only D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 22

Disk Type Linked-Clone Disposable Data Disk (vdm-disposable-guid.vmdk) vcenter Gold Master Template (.vmdk) Pool Parent (.vmdk) Instant-Clone Template Disk (cp-template- GUID.vmdk) Instant-Clone Replica Disk (cp-replica- GUID.vmdk) Instant-Clone Parent Disk (cp-parent-guid.vmdk) Instant-Clone Swap File (cp-parent- GUID.vswp) Locations and limitations Datastore selected during configuration Virtual disk deleted when the desktop is powered off Typically hosted on a shared (low-tier) datastore Used by administrator as a common provisioning source for any pool parent Typically hosted on a shared (low-tier) datastore Used by administrator as provisioning source for a desktop pool Typically hosted on a shared datastore One copy per pool Typically hosted on a shared datastore One copy on each datastore accessible by a particular pool Typically hosted on a shared datastore One copy for every host present on each datastore Same datastore as instant-clone OS disk ESX VM memory swap file Same size as virtual memory less reservation 6.3 RDSH Application Farm Linked-Clone Space Requirements Figure 15. RDSH Application Farm Linked-Clone Storage Diagram The following table provides the main parameters for sizing the RDSH application farm datastores for VMware Horizon 7. The below guideline is for the formula that calculate the estimated sizes of linked-clone disks when you create a pool and as the linked-clone machines grow over time. These formulas include the space for replica disks that are stored with the clones on the data store. Table 2. Storage Sizing Formula for linked clone disks on Selected Datastore D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 23

Data Type Selected Free Space (GB) Min Recommended (GB) 50% Utilization (GB) Max Recommended (GB) OS disks Free Space on the selected datastores Number of VMs * (2 * memory of VM) + (2 * replica disk) Number of VMs * (50% of replica disk + memory of VM) + (2 * replica disk) Number of VMs * (100% of replica disk + memory of VM) + (2 * replica disk) Persistent disks Free Space on the selected datastores Number of VMs * 20% of persistent disk Number of VMs * 50% of persistent disk Number of VMs * 100% of persistent disk However, if you edit the existing pool or store replica on separate datastore, View Composer creates new clones on the selected datastores. The new clones are anchored to the existing snapshot and use the existing replica disk. No new replicas are created. View estimates the sizing requirements of new clones that are added to the desktop pool. View does not include the existing clones in the calculation. If you store replicas on a separate datastore, the other selected datastores are dedicated to linked-clone disks. In these cases, View does not include space for replicas when it calculates storage recommendations for linked-clone disks. Below is the guidance for sizing of the storage: Table 3. Storage Sizing Formula for linked-clone when the pool is edited or replica is stored on different datastore Data Type Selected Free Space (GB) Min Recommended (GB) 50% Utilization (GB) Max Recommended (GB) OS disks Free Space on the selected datastores Number of new VMs * (2 * memory of VM) Number of new VMs * (50% of replica disk + memory of VM) Number of new VMs * (100% of replica disk + memory of VM) Persistent disks Free Space on the selected datastores Number of new VMs * 20% of persistent disk Number of new VMs * 50% of persistent disk Number of new VMs * 100% of persistent disk D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 24

7. Networking 7.1 Overview This section provides an overview of the network services and configuration required to implement this VMware Horizon 7 design. Items such as DNS, DHCP, load balancing, firewall configuration, network links and so on, are described in this section. 7.2 DNS, DHCP, and Subnet Configuration VMware Horizon 7 desktops require DHCP services. The customer will use existing DHCP services available on their client VLANs. The lease time of these client scopes will be reduced to a level so that sufficient addresses are available during recompose and instant clone operations. RDS servers will use static addresses for manual pools. DNS should be fully functional for resolution of forward and reverse queries. The View Connection Server infrastructure requires a DNS alias to enable load balancing of VMware Horizon 7 desktop connections across View Connection Server instances. Dynamic DNS is required for virtual desktops. 7.3 Bandwidth and Latency Considerations To deliver a productive user experience, it is essential that latency, bandwidth, and jitter are within acceptable limits for the specific use cases. There are a number of variables that must be considered to accurately estimate bandwidth between remote sites and the central VMware Horizon 7 resources. These include: The number of idle sessions File transfers through client drive mappings and remote USB connections URL and Flash redirection 3D use Video and audio consumption In addition, each of these factors would need to be considered in terms of concurrent use and frequency across the end-user population. When you consider your network bandwidth, plan with the following estimates: 100 to 150Kbps average bandwidth for a basic office productivity desktop: typical office applications with no video, no 3D graphics, and the default Windows and VMware View settings 50 to 100Kbps average bandwidth for an optimized office productivity desktop: typical office applications with no video, no 3D graphics, with Windows desktop settings optimized and VMware View optimized 400 to 600Kbps average bandwidth for virtual desktops utilizing multiple monitors, 3D, Aero, and Office 2010 500Kbps to 1Mbps minimum peak bandwidth to provide headroom for bursts of display changes. In general, size your network using the average bandwidth, but consider peak bandwidth to accommodate bursts of imaging traffic associated with large screen changes. The percentage of users who will use 3D graphics. You might balance users who will use 3D with other users who will not use 3D graphics. Those using 3D will have higher bandwidth utilization. 2Mbps per simultaneous user running 480p video, depending upon the configured frame rate limit and the video type Less than 80% network utilization Note: 50 to 150Kbps per typical user is based on the assumption that all users are operating continuously and performing similar tasks over an 8- to 10- hour day. The 50Kbps bandwidth usage figure is from View Planner testing on a LAN with the Build-to-Lossless feature disabled. Situations may vary in that some users may be fairly inactive and consuming almost no bandwidth, allowing more users per link. Therefore, these guidelines are intended to provide a starting point for more detailed bandwidth planning and testing. After you know the real bandwidth requirements of your typical users, substitute in those values. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 25

For guidance on example of network bandwidth calculation, please refer to the Network Optimization (Page 20). To get the best performance with Blast Extreme in low-bandwidth, high-latency situations, VMware recommends the following configuration settings: Use the H.264 codec whenever possible. The H.264 codec provides the best performance and experience. If end users connect with a device that does not support H.264, or if users have multiple monitors, the JPG/PNG codec is used automatically. Use TCP rather than UDP for the transport protocol. You can use a GPO setting or Horizon Client to disable UDP. The only situation in which UDP performs slightly better than TCP is when there is packet loss. The H.264 codec, when used with TCP, can handle up to 20 percent packet loss, whereas H.264 when used with UDP can handle up to 25 percent packet loss. (PCoIP can handle up to 15 percent packet loss.) Classify Blast Extreme network traffic as interactive real-time traffic, just below VoIP, but above all other TCP-based traffic. That is, prioritize Blast Extreme in the same way that you prioritized PCoIP if you previously used PCoIP. If your end users do not require client drive redirection (CDR), do not enable this feature. Windows-specific optimizations include the following: Use the VMware OS Optimization Tool Fling default template to disable a number of items. Use the OS Optimization Tool to also disable the following Windows features: Dynamic Windows Preview, Taskbar Animation, and Windows Peek. Use Group Policy to prohibit Desktop Wallpaper VMware recommends monitoring bandwidth usage, especially during the early weeks of the deployment so that these figures can be adjusted if necessary. 7.4 Network Circuit Requirements The following factors should be considered during the planning and implementation of the links between sites: Because these links are not dedicated to the VMware Horizon 7 infrastructure, the customer will need to make sure there is sufficient bandwidth available and that latency is kept at an acceptable level. User OS network requirements for non-remote protocol traffic, for example, applications, OS agents, file transfers, and so on, are not accounted for here, but assumptions around LAN-based traffic are addressed in Section 5, vsphere Integration. o o Any discussion around the type of circuit, the SLA, or existing utilization is out of scope for this design. Latency is assumed to be: Less than 150 ms from all sites to DC A and DC B Less than 25 ms from Site A and Site B to either data center Quality of Service (QoS) is implemented on the WAN. Voice over IP (VoIP) services receive the highest priority, and all other services and protocols are prioritized equally. Protocols do not receive any guaranteed bandwidth. The following table provides information on current networking capabilities and current usage and latency levels across the customer network. It is assumed all circuits are synchronous. 7.5 Optimal Configuration of WANs for Remote Protocols It is important that the customer s WAN is optimally configured to carry the VMware Horizon 7 remote protocols (PCoIP, Blast Extreme, and HTML Blast). The main considerations are as follows: The customer will not implement any WAN optimizations for PCoIP due to the UDP nature of PCoIP, and the fact that PCoIP is already compressed. Neither HTML Blast nor Blast Extreme will be compressed using WAN optimizers because they are already make use of compression. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 26

The customer s existing VPNs will not be used because they do not support UDP traffic. The customer will tag and classify PCoIP as interactive real-time traffic just below VoIP, but above all other TCP-based traffic. While this recommendation is likely to have a far larger impact in a WAN scenario, consider it a best practice for LAN environments. These considerations should be discussed during the knowledge transfer sessions with the customer s networking team, but for full details of other essential PCoIP optimizations consult the VMware View 5 with PCoIP Network Optimization Guide (http://www.vmware.com/files/pdf/view/vmware-view-5-pcoip-network- Optimization-Guide.pdf). 7.6 Load Balancing and Traffic Management This design will require network load balancers. They will be used by various components of the design and will help achieve the required levels of usability, performance, availability, and scalability. See Section 3, Access Layer Architecture, for a view of where the load balancers will be positioned as part of the client access layer. The design and implementation of third-party load balancers are out of scope of this design. However, any load-balancing infrastructure should support the features shown in the following table to fully meet the requirements of this design. Table 4. Load Balancer Requirements Feature Specification Justification/Comments Support Virtual IP/DNS for VMware Identity Manager Support Session Affinity Session Affinity Method Load-Balancing Basis Yes Yes Cookie JESSIONID. Some load balancers do not support session affinity based on JSESSIONID Fewest connections The VIP represents the group of load balanced servers, for example, View connection servers, App Volumes managers, and so on. Ports Monitoring Configurable port monitoring, for example, 443 (HTTPS) and 80 (HTTP). Health Monitoring Connections per Endpoint Configurable Timeout Connection Routing Yes Must support 2 connections per endpoint Yes X-forwarding for settings to determine source IP. Mirage specific requirement. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 27

7.7 VMware Horizon 7 Network Ports and Protocols Figure 16. VMware Horizon 7 Network Ports and Protocols D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 28

8. Operating System Security 8.1 Overview The security requirements for this VMware Horizon 7 platform were discussed during the design workshop and captured in the Solution Requirements document. The goal of meeting these security requirements is addressed throughout this design, for example, firewalls and authentication mechanisms. This section describes design elements that enhance the security of the VMware Horizon 7 platform that are not addressed elsewhere in the design. This section does not describe existing policies that are already applied to the customer s operating system through organization-wide Group Policies, application settings, User Environment Manager smart policies, and so on. 8.2 Antivirus and Anti-malware 8.2.1 Guest Agent Based Antivirus A key challenge in virtual desktop infrastructure deployments is the deployment of antivirus updates, scheduling of scans, and on-access agent configuration. In a physical deployment, PCs do not share compute or storage resources and they can run updates and scans at the same time without issues. In a shared infrastructure, such as a virtual desktop infrastructure, resources are shared, so care needs to be taken with how antivirus is implemented. The following provides general recommendations for antivirus configurations if traditional antivirus/endpoint protection is required, although antivirus vendor specific documentation should be reviewed. For the virtual guests: Scan on write/inbound activity only Exclude print spool directory o Exclude %systemroot%\softwaredistribution\datastore, %allusersprofile%\ntuser.pol, %allusersprofile%\ntuser.pol, *.pst files (if used), and any local databases that might be used o o o App Volumes exclusions: C:\Program Files (x86)\cloudvolumes C:\SnapVolumesTemp C:\SVROOT Scan local drives only Consider disabling heuristics, as this is resource intensive Exclude the page file Limit the installation to only the antivirus scanner (no firewall, spyware, and so on) if possible Set your nightly scheduled scanning processes to be random or scattered, if possible. This will prevent the hosts from scanning all at one time Scheduled scans should be conducted on the primary/master replica image before it is sealed VMware recommends that large updates for antivirus (engine updates) be applied to the parent virtual machine only. Scanning on updates should be avoided Scanning of View logs should be avoided 8.2.2 View Connection Server Antivirus Considerations For the View Connection Server and security server configurations, it is important to verify that the Java Message Bus directory is excluded from real-time scanning. View components actively log to the D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 29

corresponding operating system. It is recommended that antivirus software be configured to avoid scanning View logs. 8.3 VMware NSX with vshield Endpoint This reference architecture has determined that the best approach for desktop and application performance, as well as security and scalability is to leverage a VMware NSX Data Security (VMware vshield Endpoint ) based solution that can provide endpoint protection at the hypervisor level. Various vshield Endpoint partner solutions are being evaluated as the preferred antivirus solution for the virtual desktop environment. The following diagram provides an overview of the architecture required for antivirus vendor and VMware NSX Data Security (vshield Endpoint). vcenter instances will be associated with a VMware NSX Manager, which will provide the installation and management capabilities for VMware NSX Data Security (vshield Endpoint drivers are installed on each host in the cluster). Figure 17. VMware NSX Data Security Integration In addition, there is a Security Virtual Appliance (SVA) on each host that receives requests from the VMware NSX Data Security API (and the virtual machines) and provides the scanning and protection for the VMs. All scanning policies are managed through the antivirus vendor s management consoles, and communicate with the SVA (and not the actual VMs themselves) for enforcement. Scanning is done at the hypervisor level. Therefore, there is no requirement to have traditional antivirus agents inside of the virtual machine, unless other products are used within the virtual desktop. VMware best practices for scanning and protecting virtual desktops should also be implemented. D E P L O Y M E N T A R C H I T E C T U R E A P P R O A C H / 30