Unidesk Design Series: Microsoft RDS for 1000 Users

Transcription

1 TECHNICAL WHITE PAPER Unidesk Design Series: Microsoft RDS for 1000 Users This document provides a standard design for deploying VDI with Microsoft RDS and Unidesk in a single datacenter for 1000 users. November 2015

2 Table of Contents Introduction 6 Software Components 7 Unidesk 7 Microsoft 7 Service Levels/Functional Requirements 8 Highly Available Desktop Solution 8 Key Service Levels Defined 8 Availability 8 Desktop Disaster Recovery 8 Performance 8 Desktop Recovery Times 8 Facilitated Patch Management 8 Time to Provision 8 Periodic Downtime For Maintenance 9 Key Functional Requirements Met 9 Operating System 9 Bi-directional Audio 9 Web Portal 9 Printing 9 USB 9 Graphic Intensity 9 Processor Utilization Expectation 9 Client Drive Mappings 9 Multi-monitor Support 9 User Persona 9 Remote Access 9 Roaming Access 9 Page 2 of 37

3 Offline Access 9 Encrypted Communications Requirement 9 Access Logging 10 Administrative Access 10 User Installed Applications 10 Highly Configurable Desktop Solution 10 Key Service Levels Defined 10 Availability 10 Desktop Disaster Recovery 10 Performance 10 Desktop Recovery Times 10 Facilitated Patch Management 10 Time to Provision 10 Periodic Downtime For Maintenance 10 Key Functional Requirements Met 11 Operating System 11 Bi-directional Audio 11 Web Portal 11 Printing 11 USB 11 Graphic Intensity 11 Processor Utilization Expectation 11 Client Drive Mappings 11 Multi-monitor Support 11 User Persona 11 Remote Access 11 Roaming Access 11 Offline Access 11 Encrypted Communications Requirement 11 Page 3 of 37

4 Access Logging 12 Administrative Access 12 User Installed Applications 12 Architectural overview 13 Architecture 14 Hyper-V Hosts 14 Host Maintenance 15 RDS Components 16 Unidesk Components 19 Unidesk Management Appliance 19 Unidesk Master CachePoint 20 Unidesk Secondary CachePoints 20 Unidesk Integration With The Hypervisor 21 Integration with RDS 21 Unidesk Appliance Layout 22 Maintenance Schedules 23 IP Network 23 Storage 24 SQL Server 28 Client Access 28 Work 28 Remote Site 29 Home 29 Applications 30 Traditional Local Apps Installed on Virtual Desktops 30 Remote App 31 Printing 31 Backup 31 Page 4 of 37

5 CachePoint File System Backups 33 RDS Components 33 VDI Desktop VMs 34 Financial Summary 36 Conclusion 37 Page 5 of 37

6 Introduction With the introduction of Unidesk version 3.x, Unidesk has integrated our Application Layering platform with the Microsoft VDI and Remote Session Host platform based on the Microsoft Remote Desktop Services (RDS) role in Windows Server 2012 R2. This technical whitepaper is intended to give end user computing architects and IT administrators at Unidesk customers and prospects and solution architects at Unidesk solution partners a general understanding of the design options available for a joint Unidesk and Microsoft VDI solution. The combination of Unidesk software with the Microsoft VDI framework provides an extremely cost-effective, yet robust and manageable way to deliver virtual desktops to users. This document will communicate architecture and design principles for a Microsoft/Unidesk VDI solution to those who may not be familiar with either technology. The architecture is designed for 1000 desktops but can be scaled to many times that. A separate document will be delivered that adds site redundancy and higher levels of availability, but this architecture should be suitable for most customers. In this document we will first define the software components included in the design followed by the targeted service level requirements and functional requirements for the solution. The design will then describe the architecture components that have been engineered to meet the defined requirements, along with the reasons the decisions were made when engineering the solution. By developing the documentation in this manner, administrators should be able to use or modify the design to meet their unique needs. The document also includes a high-level cost breakdown of the solution components to provide a rough budget for deploying a solution based on Unidesk and Microsoft RDS. What is not included in the design is any performance or scale testing, though the design as described can be easily tested with a single host in a POC. Page 6 of 37

7 Software Components The architecture developed for this solution is comprised of datacenter hardware and software from Microsoft and Unidesk. Some components of the architecture that comprise the datacenter infrastructure can be substituted with like software / hardware solutions already in use within your organization. However, the software listed here should be considered required as part of the overall architecture and solution. Unidesk Unidesk Management Appliance Version 3.3 or later for Hyper-V. Unidesk CachePoint Appliance Version 3.3 or later for Hyper-V. Unidesk Hyper-V Agent Version 3.3 or later. Unidesk Broker Agent The Unidesk Broker Agent will be installed on your RDCB servers and will be version 3.3 or later. Microsoft Hyper-V The Hyper-V role must be installed on each virtualization host used for the VDI solution. Unidesk requires Hyper-V 3.0, which is only available on Windows Server 2012 R2. SQL Server The SQL server should be running at least SQL Server 2008 and should be Standard Edition or higher. VDI/RDSH Windows 7, Windows 8.1 Update 1, Windows 10, and Windows Server 2012 R2 are supported as VDI Guests. Windows Server 2012 R2 is supported as an RDSH Guest. RD Connection Broker Remote Desktop Connection Broker provided with Windows Server 2012 R2. RD Web Remote Desktop Web provided with Windows Server 2012 R2. RD Gateway Remote Desktop Gateway provided with Windows Server 2012 R2. RD Licensing Server Remote Desktop Licensing Server provided with Windows Server 2012 R2. Active Directory Active Directory 2008 R2 or higher. Microsoft AD Integrated DNS Server 2008 R2 or Higher. User Experience Virtualization (UEV) Version 2.x and higher of Microsoft UE-V Certificates A certificate issued by a trusted certificate authority (CA). Page 7 of 37

8 Service Levels/Functional Requirements The intent of this architecture is to create a design applicable to the largest number of use cases possible. The architecture will support both non-persistent highly available desktops and persistent highly configurable desktops backed up by non-persistent highly available desktops. This will allow line of business managers to choose a service level that matches their requirements and their budget. In this section the service levels provided by each offering will be defined along with the functional requirements the offerings are meant to satisfy. Highly Available Desktop Solution The highly available desktop must provide users with access to desktops with an extremely high degree of availability. This desktop will have a streamlined configuration, allowing it to easily and quickly be deployed anywhere in the datacenter. Key Service Levels Defined This architecture offers many service level benefits. Some of the most important are listed here. Availability Desktop Disaster Recovery Availability with this design is very high. Users can connect to any desktop in the overall desktop pool to which they belong. Therefore, if the host they are on fails, or their desktop fails for any reason, they can log back in and receive another desktop in the pool immediately. This solution can easily provide availability of 99.9% which equates to less than 9 hours down time a year. DR is not defined in this design. DR will be covered in a separate architecture that includes high availability between datacenters. Performance Desktop Recovery Times Facilitated Patch Management Time to Provision VDI gives organizations the ability to provide powerful performance for users when they need it without wasting excessive amounts of processing power on each desktop by sharing powerful new server hardware. If more performance is needed capacity can be added to the solution and users can be provided a larger percentage of that capacity. The expectation for this use case is that the performance required will be average for desktop users requiring approximately 900 MHz per system. This architecture provides very fast recovery to desktop problems. If an access device (Thin Client or repurposed desktop) fails it is replaced quickly from spare stock requiring no installation or configuration. If a Hyper-V host fails the user reboots and reconnects into a new desktop immediately. OS and Application patches must be performed on a monthly basis, and occasionally on-demand if a significant issue arises. Desktops must be provisioned within one business day under normal operations. Page 8 of 37

9 Periodic Downtime For Maintenance Periodic downtime for maintenance is not allowed. Key Functional Requirements Met This architecture supports the following functional requirements for highly available desktops: Operating System Supported Operating System for desktops will be Windows 10 Enterprise. Bi-directional Audio Web Portal Printing USB Graphic Intensity Processor Utilization Expectation Client Drive Mappings Multi-monitor Support User Personalization Remote Access Roaming Access Offline Access Encrypted Communications Requirement Bi-directional Audio via USB or integrated microphones is required Easy access to desktops and apps via web portal is required. Both network printing and client redirected printing are required. Many USB client devices must be supported including flash drives and locally attached scanners. The solution must perform adequately with regards to graphics but the application portfolio for these uses cases does not include graphically intensive applications. The expectation is that users will randomly watch moderate size videos streamed from the internet and file servers but no 3D modeling or intensive graphics applications will be supported. For the architecture sizing and cost we have modeled using an average of 900 MHz per desktop. This will likely be sufficient for all of the use cases defined here. Can be allowed or disallowed using an Active Directory GPO within RDP settings. Support for 2 monitors is required. Capturing and replaying user settings for some applications is required. Also an attempt must be made to ensure that user files are stored persistently. Remote Access is supported via the internet without need for the corporate VPN. Roaming Access across corporate sites is supported as long as end user stations are available in the remote sites. Offline access is not required by this solution Encryption from the end user device to the virtual desktop is required. Page 9 of 37

10 Access Logging Administrative Access User Installed Applications Internal connections and remote connections to the web portal or broker must be logged. Logs must be stored for 1 year. This solution is not expected to allow users to be local administrators on their virtual desktop. This solution does not provide the ability for users to install applications. Highly Configurable Desktop Solution The highly configurable desktop is designed to provide users with an experience that is as close to a physical PC as possible. This offering must provide users complete customization of the desktop settings, user installed applications, and user data. Key Service Levels Defined This architecture offers many service level benefits. Some of the most important are listed here. Availability Desktop Disaster Recovery Performance Desktop Recovery Times Facilitated Patch Management Time to Provision Periodic Downtime For Maintenance Availability with this design is expected to be higher than a physical desktop but otherwise normal. Desktops will be backed up and recovery time for the desktops will be as soon as possible. A highly available nonpersistent desktop will be always be available for the users of this offering as a backup to their personal desktop. DR is not defined in this design. DR will be covered in a separate architecture that includes high availability between datacenters. VDI allows and organization the ability to provide powerful performance for users when they need it without wasting excessive amounts of processing power on each desktop by sharing powerful new server hardware. If more performance is needed capacity can be added to the solution and users can be provided a larger percentage of that capacity. The expectation for this use case is that the performance required will be average equally approximately 900 MHz per system. This design provides recovery of personal desktops as soon as possible along with immediate access to a highly available non-persistent desktop. OS and Application patches must be performed on a monthly basis and may be required on-demand very quickly if a significant issue exists. Desktops must be provisioned within one business day under normal operations. Periodic downtime for maintenance is allowed. Page 10 of 37

11 Key Functional Requirements Met This architecture supports the following functional requirements for highly configurable desktops: Operating System Supported Operating System for desktops will be Windows 10 Enterprise. Bi-directional Audio Web Portal Printing USB Graphic Intensity Processor Utilization Expectation Client Drive Mappings Multi-monitor Support User Persona Remote Access Roaming Access Offline Access Encrypted Communications Requirement Bi-directional Audio via USB or integrated microphones is required Easy access to desktops and apps via web portal is required. Both network printing and client redirected printing are required. Users may install their own print drivers. Many USB client devices must be supported including flash drives and locally attached scanners. The solution must perform adequately with regards to graphics but the application portfolio for these uses cases does not include graphically intensive applications. The expectation is that users will randomly watch moderate size videos streamed from the internet and file servers but no 3D modeling or intensive graphics applications will be supported. For the architecture sizing and cost we have modeled using an average of 900 MHz per desktop. This will likely be sufficient for all of the use cases defined here. Can be allowed or disallowed using an Active Directory GPO within RDP settings. Support for 2 monitors is required. User persona will be stored locally on desktops and be full featured in conjunction with allowing user installed applications and users as Administrators. Remote Access is supported via the internet without need for the corporate VPN. Roaming Access across corporate sites is supported as long as end user stations are available in the remote sites. Offline access is not required by this solution Encryption from the end user device to the virtual desktop is required. Page 11 of 37

12 Access Logging Administrative Access User Installed Applications Internal connections and remote connections to the web portal or broker must be logged. Logs must be stored for 1 year. Users will be local Administrators with this offering. This solution does not provide the ability for users to install applications. Page 12 of 37

13 Architectural overview The architecture has been defined to provide redundancy for critical components using load balanced servers as well as redundancy of desktops by spreading desktop collections across hosts. The components of the hosts themselves are designed for redundancy only where it is cost effective to do so. By architecting the solution in this manner the service levels and functional requirements are met at the lowest possible cost. In the design each RDS component is load balanced for availability. This is because without these components users will not be able to access their desktops. The RD Connection broker is configured for High Availability utilizing a 2-node SQL Server AlwaysOn Cluster. Highly Availability for desktops is provided by simply spreading collections across hosts. If a host fails for any reason, desktops of that type will still be available on other hosts. Highly customizable desktops will not be highly available but they will be backed up. If a desktop of this type fails or a host fails the users will use a highly available desktop until the host or desktop is repaired or restored from backup. Page 13 of 37

14 The design forecasts that 80 desktops can run on each host and hosts are configured with local consumer grade SSD storage to keep costs low. A single Unidesk Secondary CachePoint will be deployed to each host and one of the hosts will also have the Unidesk Management Appliance and Master CachePoint installed. Note that using an all-flash hyperconverged system from vendors such as Unidesk partner Gridstore can significantly increase the number of desktops that can run on each host to as many as 150. Users will access their desktops using a Windows 10 Thin Client from the main campus or remote offices and remote access will be provided using Microsoft Remote Desktop Gateway Servers in the DMZ. For the high availability desktops the most used applications will be included by Unidesk directly on each desktop. Differentiation between application sets will be provided by creating different desktop collections. If a user logs into a desktop in the collection they will receive the applications deployed to that collection. For less used applications they will be deployed by Unidesk to RDSH hosts and users will be provided access to those applications from the RD Web interface using Microsoft RemoteApp functionality. For more details review the following sections of the document. Architecture The architecture is based on software only from Microsoft and Unidesk. Microsoft provides the foundation elements including Active Directory, DNS, DHCP, Windows 10, the connection broker, remote access gateways, and web interfaces. Unidesk provides the framework to manage the Operating System and application deployment and patching. Hyper-V Hosts Hyper-V hosts make up the core building blocks of the virtual desktop solution. As stated above the architecture primarily obtains redundancy not from having expensive redundant components in the hosts but from spreading the desktop collections across hosts. Modern hosts and their components fail infrequently so the design calls for provisioning some redundancy but only for prudent engineering choices that provide the redundancy at minimal cost. VDI density and performance generally benefit from more cores and faster memory rather than faster processors. However, as a general rule most organizations use dual physical processor servers based on price/performance and the risk of loss. If quad processor or greater hosts were utilized the number of desktop sessions per hosts would be very high and a failure of that host would impact a large number of users. So the design calls for modest hosts with excellent performance per dollar ratios. Networking is also a critical component of the hosts. Separate networks will be used for the host communications and the desktops. Host communications will include any communication by the Page 14 of 37

15 host to the rest of the infrastructure, any requirements for clustering and HyperV migrations. If IP storage is utilized that is outside the scope of this design and 10GB connections should be considered. See the storage section for more details. Since GB Network interfaces are very inexpensive each network will be created with two network adapters bonded for redundancy, or aggregation and redundancy. An example host design would include: 2 Physical Processors 20 Logical Processors 384 GB of RAM 4 Network interfaces A standard desktop in this architecture is expected to be Windows 10 with 3-4 GB of RAM. The RAM will be configured to leverage dynamic memory, with a 1GB minimum and a 3 GB maximum as standard for the Highly Available use case and 2GB minimum, 4 GB maximum for the Highly Customized use case. Each desktop will be configured with 2 logical cores. Using this desktop configuration the expected number of desktop per host should be around 80 but results may be more or less depending on desktop concurrency and application requirements. Along with the Virtual Desktops, there are several other systems that will consume resources on the host. First and foremost there is the hypervisor. It isn t possible to directly assign any resources to the hypervisor; however it is best to assume that it will require roughly 2 logical processors and 2 GB of memory to function properly. Each Unidesk appliance deployed will also take up 2 virtual processors and 4 GB of memory. Taking all this into account the number of hosts required for 1000 desktops is 14. This includes one extra host for to account for a host failure. Host Maintenance Hyper-V hosts require periodic maintenance. Patching of the Operating System is a requirement. For the four hosts that contain the persistent desktops and RDS components in the design, periodic maintenance will be scheduled regularly based on organizational requirements. The suggested frequency is once per month with maintenance being performed at the most opportune time for users. These system will require that all persistent desktops be shut down for patching. The shut down need not affect RDS as all RDS components are redundant. Hosts providing the highly available non-persistent desktops can be maintained at any low usage time due to the redundancy built into the design for this desktop type. Page 15 of 37

16 RDS Components Remote Desktop Connection Broker Remote Desktop Connection Broker (RDCB) facilitates the connection between the end user on their client device and the virtual machine in a virtual machine grouping known as a collection. Active Directory users and groups will be assigned to collections, allowing them access. Using the Active/Active RDCB design the number of connections that can be supported with just a 3 second connection time is over 5,000 well above the requirements for this design. To ensure redundancy the two different virtual machines will have the RDCB role installed and each one will be hosted on a different physical server (HyperV host). The RDCB VMs will also share a clustered SQL Database, if either of the two virtual machines fail to contact the SQL Database all connections will be redirected to the other one. See the certificate section for certificate requirements of this design. See this Microsoft Press article for more details on RDCB redundancy: Note: the RDCB and Licensing server both require redundancy. To simplify the environment both these roles will be installed on the same two servers. Remote Desktop Licensing Server The way the Remote Desktop Licensing Server works depends on the type of CAL used. For user based CALs the RD Licensing server is contacted by the RDCB and as long as the server is available the User is connected. The number of available CALs is not part of the communications. But if the Licensing Server is not available the user is not allowed to connect. For device based CALs the number of CALs is enforced. In either case it is a requirement to have redundant Licensing servers. According to Microsoft: The simplest way to configure high availability for the RD Licensing role service when using Per Device licensing is to put all RDS Device CALs on a single RD Licensing server. The second RD Licensing server has no CALs installed and issues only temporary licenses. In this configuration, failure of the RD Licensing server with CALs has no effect on devices with a permanent or temporary license, which typically are the majority of devices. Devices connecting for the first time are issued a temporary license from the remaining RD Licensing server without CALs. The only clients unable to connect are devices with an expired license, which should be a small number of devices. Again see this Microsoft Press article for more details on Licensing Server redundancy: Page 16 of 37

17 Since redundancy of the RD Licensing Sever is required the licensing server will be installed in conjunction (on the same Windows Server) with the RDCB. These servers will be configured with 4 cores and 8 GB of RAM per Microsoft scaling recommendations. See the certificate section for certificate requirements of this design. Remote Desktop Web Server Remote Desktop Web Server (RDWeb) works in conjunction with RDCB to enable users to connect with the desktops to which they have been assigned. Users will be able to login to the RD Web Server either from a webpage or another machine running Windows 7 or higher. Once a user logs in they are presented with a list of desktops that are assigned to them. Clicking on the desktop will open a remote connection. There will be two of these servers to provide redundancy. The RDWEB servers will be load balanced using Windows Network Load Balancing (NLB) which provides a simple and inexpensive mechanism to load balance servers up to 32 nodes. See the certificate section for certificate requirements of this design. Remote Desktop Gateway The Remote Desktop Gateway allows users to connect into desktops from the internet without the need for configuring a VPN. The server is placed in a DMZ outside of the firewall and provides different levels of configurable security to ensure that only approved users can connect in. Once a user has logged into the Gateway the connect is passed to the servers on the other side of the firewall. A single RD Gateway with 2 CPU and 4GB of RAM can support up to 250 concurrent connections. Two servers will be deployed here for load balancing and for redundancy The RD Gateway servers will be load balanced using Windows Network Load Balancing (NLB) which provides a simple and inexpensive mechanism to load balance servers up to 32 nodes. If more than 250 concurrent remote connections are needed, more servers can be configured and added to this group to provide additional connection bandwidth. See the certificate section for certificate requirements of this design. Certificates The design calls for web server certificates using Microsoft Domain Certificate Authority. They will need to be applied the following servers: RD Web Servers RD Connection Broker Servers Page 17 of 37

18 RD Gateway Servers The type of certificate defined will be a web server certificate using the virtual name of the NLB cluster. Page 18 of 37

19 Unidesk Components Unidesk deploys two types of virtual appliances. The first is the Unidesk Management appliance, which hosts the web management interface, a small configuration database and the Unidesk logic engine. The second type of appliance is called a CachePoint. While there is only one Management appliance in any given environment, there are typically many CachePoint appliances. The CachePoints (CP) are responsible for layer replication, virtual machine configurations and are deployed in a scale-out model at typically 1 CachePoint per managed virtual machines. The administrator interacts with the Management appliance, which directs activity in a Unidesk environment. The first CachePoint appliance deployed takes on the role of the Master CachePoint and maintains a master copy of all IT created layers. These layers are then replicated out to other CachePoints volumes in the environment. The scale out model Unidesk employs has several advantages. First, the updating of virtual machines is spread across a larger number of CPUs and virtual appliances. This allows for greater scalability and decreased overall time during VM updates than if all VMs were updated by a single server. The scale-out model also means that a single failure of a CP during updates impacts far fewer VMs than a failure of a central update server model. Unidesk Management Appliance The Management appliance is a virtual appliance that coordinates the communication between the Unidesk Management Console, the CachePoint appliances, and the virtual infrastructure. The Management Console is a Web-based application that administrators use to manage the following components: Virtual desktops Operating System Layers Application Layers Directory service integration points The Unidesk infrastructure The Management infrastructure run from the Management Appliance is the software that controls the workflow required to manage virtual machines. It includes a A Database that stores the following information: o Data about all of the Operating System and Application Layers that exist in the system. o All data from the Unidesk Management Console. o Schemas that implement back-end storage in the virtual infrastructure. Active MQ Technology o Provides task queues used to coordinate tasks between appliances Business Logic used to orchestrate changes between appliances and desktops Page 19 of 37

20 Unidesk Master CachePoint The first CachePoint appliance that is provisioned in the Unidesk environment becomes the Master CachePoint appliance. This virtual appliance maintains the master copy of all of the Operating System and Application Layers in the Unidesk environment. The Master CachePoint appliance stores the layers as virtual disks (VHDXs) in its storage volumes. The Master CachePoint appliance automatically replicates Operating System and Application Layers to secondary CachePoint appliances that manage desktops/session Hosts. Layer replication to secondary CachePoint appliances occurs only if one or more VMs associated with a specific CachePoint appliance requires the layers. The Master CachePoint appliance also manages the Installation Machines that you use to create and modify Operating System and Application Layers. An Installation Machine is a special type of VM that IT Admins use to create Application Layers or add versions to existing Operating System and Application Layers. The Master CachePoint appliance stores the VHDX files for Installation Machines in its datastore. Unidesk Secondary CachePoints The Secondary CachePoint appliances are responsible for: The initial deployment of desktops. Deployment of desktop configuration changes. These appliances maintain copies of the layers that are assigned to its managed VMs. The secondary CPs datastore also contains the personalization VMDK/VHDX files associated with the VMs deployed in the same datastore. All VMs associated with a specific CachePoint appliance are able to share the IT created (OS and App) layers. The CachePoint Folder Structure Each CachePoint appliance (including the Master CachePoint appliance) has a folder in its assigned volume. This folder contains the following files and subfolders: CachePoint Appliance Folder UnideskLayers folder OS APP USER Contains virtual disk files for the CachePoint appliance and the UnideskLayers folder. Contains the folders that store layer VHDX files for OS, Applications and Desktop personalization. Operating System Layer that the CachePoint appliance needs. Application Layers that the CachePoint appliance requires to support desktops. The writable portion of a Unidesk desktop Page 20 of 37

21 Unidesk Integration With The Hypervisor Unidesk communicates with the Hyper-V hypervisor in order to build, update, and repair virtual machines under Unidesk management. Unidesk supports Microsoft Hyper-V on Windows Server 2012 R2. A listener (agent) is installed on each Hyper-V host that Unidesk will have access to for creating and managing desktops and RDSH VMs. The Unidesk Hyper-V agent listens on TCP port 8014 for commands from both CachePoint appliances and the Management appliance. These commands are received by the agent and executed on the host as PowerShell commands. Unidesk does not require that you have SCCM/SCVMM installed in your environment for Hyper-V integration with the RDS broker and SCVMM is not defined in this architecture though it can be used if desired. Integration with RDS A Unidesk Virtual Desktop Connection Broker Agent will be installed on any Windows Servers with the Connection Broker role installed. This agent will listen for calls from the Unidesk management system to create collections, add desktops into collection and assign users to desktops (for personal desktop collections). No agent is required within the virtual desktops for the Microsoft RDS connection broker to function (as you would see in third party brokers). Instead all Unidesk requires is that the host integration services be installed in the OS Layer. In Unidesk a Unidesk Collection maps directly to a Microsoft RDS desktop Collection. Each Collection in Unidesk will be configured to specify the Operating System Layer to use for the desktops in the RDS collection. Once integrated with a broker, your Desktop Collections in Unidesk will mirror the groupings established in the broker. Page 21 of 37

22 Unidesk Appliance Layout In this architecture the layout of the appliances is very straight forward. The Management Appliance and Master CachePoint will be collocated on the same host and storage volume. This will facilitate backup of those appliances at the same time. The host used for these appliances will also be a host used for Highly Configurable Desktops as those will also require backup of the local storage volumes. There will be four hosts used for Highly Configurable Desktops and 8 hosts used for Highly Available Desktops. Each host except for the host with the MA and MCP will have a single Secondary CachePoint that will manage the desktop on that host. If shorter maintenance windows are required a second CachePoint can be added in order to decrease scheduled maintenance times by doubling the rate machines are redeployed at. Page 22 of 37

23 Each host will have both VDI desktops and RDSH Servers deployed to the host. This will provide the best CPU and Memory utilization for the resources on the hosts as the load will be varied by type. Maintenance Schedules Unidesk provides the ability to define when desktop changes are applied to desktops. By default the maintenance schedule is defined to be Monday through Friday from 9 PM to 5 AM and the user must be logged off for the maintenance to run. In this solution we will change the default maintenance schedule to be 24x7 and the user must be logged off for more than 10 minutes for the maintenance to run. This will even out any deployed changes to desktops to any time users are not using their desktops. Unidesk CachePoints perform the maintenance and they limit that to four desktops at a time per CP and in our case per host. On the highly configurable desktops, a script will be run every day between three and 5 PM to inform users if their desktop is awaiting maintenance. If changes have been applied to the desktop users will have three days to logoff and then they will be forcibly logged off at 11:30 PM. IP Network Host Networking For redundancy each host should be connected to two (or more) network switches. The design in this document calls for 4 network adapters per host, with 2 teamed for the OS and 2 teamed for desktop virtual machines. Each NIC team should have one NIC attached to each of the network switches to protect against link or switch failure. The desktop bond will likely be a Layer3 VLAN Tagged interface to allow desktops on different VLANs to be hosted by the same server. Datacenter Networking Depending on manufacturer and model of the switch the bonds will configured for Active/Passive or Switch Independent mode where all virtual adapters will be registered with one link and changed in the event of a link failure. This is the simplest to configure and will work with almost any switch, however all the virtual machine traffic only utilizing one link. With more advanced models of upstream switches that support stacking or Multi-chassis Link Aggregation (MLAG) you can utilize link aggregation on the virtual switch to so that both links of NIC team are active. While this will allow twice the aggregate bandwidth capacity it is important to note that no individual virtual machine connection will be faster than the single-link speed. To be able to fully operate during a switch or link failure, you should ensure that the required network throughput does not exceed the bandwidth that more than a single link can deliver or N- 1 links when more than 2 NICs are teamed together. With 80 desktops per host average, each desktop would be allowed 10 Mb/s average utilization when a single 1 Gb NIC is shared. If it is determined that aggregate desktop bandwidth will exceed 1 Gb/s consider using 10 Gb network Page 23 of 37

24 adapters and switches or teaming 3 or more 1 Gb links with virtual switch link aggregation to increase the aggregate bandwidth to desktops. Access (desktop closet) Networking The design of the access network depends greatly on service levels to particular end users. In the requirements of this architecture a high availability option was defined overall. However it is very expensive to provide high availability of the access switching infrastructure. This would require redundant closet switches and redundant network connections to the access devices (Thin Clients). A more practical approach is to provide an extra switch or switching module per floor that can quickly be deployed in the unlikely case of a switch failure in the access closet. Similarly, access switches can have redundant uplinks to the network core switches or an extra connection can be left in the floor closet to use when required. For environments with multiple core switches, it is important that each network switch has a link to each core switch to ensure access if a core switch is down. In a fully redundant architecture that would could mean 2 links per access switch to each core switch. Uplink failover detection between access switches and core network gear is typically handled by the Spanning Tree protocol. With Spanning Tree only one link is utilized and the others are set to standby. If multiple core switches are part of the same Spanning Tree you only need 1 link to each core switch per access switch to still have redundancy. This is important for capacity planning as each access switch will only have the uplink capacity of the speed of one link even if multiple are used because spanning tree will put the others as standby unless link aggregation or port-channel is used. The size of the uplinks from access to core depends greatly on the number of desktops connected to the access switch. If we assume each desktop will use on average less than 800 Kb/s then 1 Gb/s uplinks should be able to support approximately 1,000 users. For general computing 800 kb/s is more than enough bandwidth. If your organization expects to have user viewing large video streamed material, bandwidth can increase to upwards of Mb/s. That would allow for only about desktops per Gb/s uplink. Given the requirements defined for our use case 1 Gb/s uplinks will be used. Storage Storage design is always a critical factor in the success of any VDI solution. The ability for desktops to write data without queuing or high latency is one of the most significant factors leading to good perceived performance of the desktop. If writes are slow or performance is not consistent users will have a poor experience with their desktops. For this reason flash or hybrid storage are the most utilized storage technologies in successful VDI implementations. Page 24 of 37

25 The design detailed in this architecture uses host redundancy rather than redundancy of each component to provide high availability levels. This allows for lower costs while maintaining high service levels. In order to keep costs low commodity local SSD storage will be defined here. There are parts of the design that are not totally covered by the ability to just recreate a host. Those components can be stored on alternate storage or backed up. In this section of the architecture we will discuss the local storage recommendation as well as several alternates that can be considered. Local Storage As discussed earlier the overall design for availability within this solution is based on spreading non-persistent desktop collections across hosts and backing up persistent desktops. This allows for the use of inexpensive but very fast local storage based on consumer grade higher endurance SSDs. In this design availability of an individual desktop becomes less important as long as there are sufficient running and available desktops to meet the user demand and to handle a host failure. This design supports using simple and cost effective local storage attached to the Hyper-V host as there is no penalty for the loss of data if a drive fails. Thanks to the storage reduction from shared layers, the capacity per host required for desktops will easily fit onto a pair of solid state drive s eliminating the need for a complicated RAID setup and more expensive RAID controller hardware. Standard off the shelf consumer grade drives of approximately 1 Tb can be used to provide high IO storage. One drive will be used for Unidesk Boot Drive storage and one for layer storage. Optionally the two disks can be configured in a RAID-0 stripe set. This can provide faster IO performance if the storage controller supports RAID. For a higher availability solution RAID-0 can be used but this will require four disks rather than two. The operating system disk does not use enough space to provision a separate drive. The OS can be included on the same disks as the Unidesk Boot Images. Page 25 of 37

26 Capacity Calculation In order to define the size of storage to provision on each host Unidesk provides a storage capacity estimation worksheet. We used the following inputs to fill out the estimate: Highly Available Desktops configured as non-persistent with 4 GB of desktop personalization space Highly Customizable desktops configured with 15 GB of desktop personalization space 300 Highly Customizable Desktops 700 Highly Available Desktops 350 GB for layer storage space per CachePoint/Host The amount of storage required for this configuration is estimated to be approximately 1.3 TB per Host/CP. Page 26 of 37

27 Centralized Storage It of course is possible to use centralized storage for all of the desktops, just the persistent desktops or just the Unidesk Management Appliance and Unidesk Master CachePoint. Using centralized storage will provide higher availability for these components because the will become immediately available if a host crashes. However this will significantly increase the cost and complexity of the solution. Centralized storage in Hyper-V can be provided using iscsi, or Fibre Channel arrays using Clustered Shared Volumes as well as SMB/CIFS shares. For VDI the performance of the array and the storage network is very important and Hybrid or all flash arrays should be considered. If only the Unidesk MA and MCP as well as the RDS components will be provisioned using centralized storage then SAS performance will be adequate for those systems. Hybrid & All-Flash Arrays As stated earlier in this document write performance is critical to provide a good user experience for VDI users. The normal IO load for VDI of 1000 desktops will likely exceed the ability of traditional spinning disk storage arrays to keep up with the write IO load. Therefore, the most utilized type of centralized storage for VDI is based on hybrid or All Flash arrays. All-flash arrays provide always consistent high level performance but that performance does come at a higher price. Unidesk and the shared layer architecture works well by moving the most used blocks in the OS and Application layers onto the SSD drives. The writes on hybrid arrays will normally go directly to the SAS or SATA storage. If the hybrid array you use allows write-through SSD that would be a good option to set. Of course all Flash arrays will always write at high performance and therefore they will provide the best possible desktop performance for VDI. Hybrid-Arrays can provide excellent performance at a moderate price. Both all flash and hybrid arrays are used successfully by many Unidesk customers. Unidesk partner Gridstore is an option that should be considered for Microsoft VDI because it is an all-flash, hyperconverged solution designed solely for Hyper-V workloads, at a very attractive price point. Storage Connectivity If a centralized option for storage is used it is recommended that a separate storage network be created using separate IP switches and separate Network Interfaces on the hosts. If all desktops use centralized storage ensure that the storage network interfaces have sufficient bandwidth to handle the load. For 80 desktops per host it is likely that two 1 GB NICs will provide sufficient bandwidth and availability for storage traffic from the host to the storage array or NAS device. This allows for up to approximately 10 Mb/s traffic on average per desktop. Page 27 of 37

28 SQL Server SQL server is a critical component of the RD Connection Broker high availability architecture. To ensure that the RDCB is highly available the supporting SQL Server must be configured for high availability as well. If there is already an existing highly available production SQL server in environment, it can be used for this purpose as the load on this database is not high. Microsoft SQL 2014 Standard Edition or newer is recommended, including the Always On feature that will keep two independent SQL instances in-sync for instant failover. This is the only component in the architecture that will utilize Microsoft failover clustering. Both the primary and secondary SQL servers should be provisioned as virtual machines running Server 2012r2 with at least 8 Gb of RAM to allow 4 Gb to be dedicated for the SQL Server Process. Each virtual machine will be provisioned with its own sets of virtual disks for the OS and SQL data, for redundancy ensure that VM1 and VM2 are kept on different hosts and storage. If centralized storage is available, it should be utilized for these virtual machines to protect from data loss due to a single host failure, but they should still each be hosted on different LUNs / drives for redundancy. With SQL AlwaysOn, both servers will be kept in synchronous replication of each other, allowing failover from one to the other via a floating IP address to be nearly instantaneous. This can be initiated manually for scheduled server updates and restarts, or automatically in the event of a failure to the primary node. This makes for simple response to failures as no configuration on the connection broker servers needs to be changed when the secondary takes over. After the issue is resolved the failed server will automatically sync back up with the new primary server and will become the standby secondary. This independent VM design will yield highly available SQL server that is fully redundant within the single site and can be quickly recovered in the event of a host or storage level failures. With the use of centralized storage, loss of a host can be recovered from after a simple restart of the failed VM on a different host, which can be automated. As long as the independent VMs are on different hosts and different storage there should be zero loss of access to the RDCB database. Client Access End users will access a virtual desktop by connecting to the RDCB using some device running the Remote Desktop Client. The access method may be different based on where the user connects from. Work For new deployments, Windows Thin Clients are most often chosen by organizations as they have many advantages over providing a full desktop for access. Thin Client computers are designed to minimize what is run on the access point, they are also designed to make connection to the remote desktops seem as if it is a local connection on the Page 28 of 37

29 Thin Client. Most Thin Client vendors also provide an enterprise management framework that makes patching and updating the client easy for a large implementation. Lastly Thin Client are designed without moving parts so that MTBF is lower and they use less power than a full PC would. Existing hardware can be re-purposed into access clients keeping the cost low, however they consume more electricity and still must have their operating systems updated and patched costing more to operate. While on the local company network the remote desktop protocol will detect a low latency connection to the virtual desktop and will not attempt to throttle or heavily compress the connection. This will use significantly more bandwidth than when connecting remotely, however it will give the end user a better experience. Using thin clients or repurposed computers, ensure that they are running at least windows 8 or preferably windows 10 as each run newer versions of the remote desktop protocol which reduces the consumed bandwidth and provides better Direct X and Open GL support. Client access reliability and quality of service is heavily based on the network reliability and capacity. This is why it is important that the client access network switches have sufficient capacity, especially the uplinks ports as it is easy to have many users per network closet. This is addressed more in the networking section of this document, but is should be considered when deciding on access methods and user densities. Remote Site If users will be connecting from remote sites that have dedicated network or VPN links connecting back to the datacenter or main site, it is important that these links are reliable and of sufficient capacity. It is likely that VDI will put higher sustained load on them than with previous full desktops/laptops. And VDI users are more likely to notice when the link is saturated and latency increases than they were just when they were just using the link to access file services. A contingency plan should be in place for loss of primary link, whether it is a redundant link/path or simply having users work from home and connect via their internet provider. Network optimizers or WAN accelerators often work well to reduce capacity required for remote site connectivity, while not addressed in this design, they should be considered when it is not possible or cost feasible to get a link of enough capacity to a remote site. Home When users connect from home on personal computers not owned and managed by the company, they can install the Microsoft Remote Desktop Client. There are versions for both Mac and PC as well as the majority of mobile phones and tablets through their respective app-stores. This allows the user to connect with any device by installing the application and connecting to the external RD Gateways. Compared to connecting with a traditional VPN, VDI offers increased security as Page 29 of 37

30 their unmanaged home computer is not connected to the internal company network putting it at risk for infection or attacks. Applications Proper application management is critical to the success of any virtual environment. As the number of images grows, so does the amount of time it takes to manage and update applications across the various images. Unidesk streamlines the management of applications and the operating system by separating each element in its own virtual disk layer. Each layer only has to be updated once to be distributed out to every VM in the environment. Unidesk supports deployment of the operating system and applications to both VDI desktops and Microsoft Remote Desktop Session Host Servers. In this design, frequently-used applications that are provided to all users will be deployed directly to Unidesk managed virtual desktops. Applications that are only used by some users with highly configurable desktops can also be deployed directly to the desktop. Applications that are used only by some users of the Highly Available desktops will be deployed to RDSH servers and delivered via Microsoft RemoteApp. Delivering Layered Apps to Virtual Desktops When app layers are assigned to a Virtual Desktop, they will appear to be locally installed, and they will execute locally on those machines as well. Unidesk can be used to deploy any type of Page 30 of 37

31 application from the simplest web browser, to the most complex applications with kernel mode drivers, so you don t have to worry about distributing applications based on type or complexity. Since applications deployed in this method will be available to all users on a particular collection, applications that will be used by everyone should be deployed in this manner. Delivering Layered Apps to RemoteApp Servers Unidesk layered apps can also be assigned to RemoteApp session hosts. These apps will then be published by RemoteApp from the Windows server on which they are hosted. Users can be entitled to a specific application using Active Directory groups that will then be accessed via the RD Web interface. Unidesk delivers the app layers to the Windows RemoteApp servers, and then the RemoteApp servers publish the apps to the entitled users from their remote device. RemoteApp and Non-Persistent Desktops can be a powerful combination. By entitling apps on a per-user basis, applications can be specifically targeted at the user rather than being layered onto a specific machine. For example, a kiosk can be setup with a non-persistent virtual desktop, and each user who logs in will see different app layers published through RemoteApp based on their entitlements. Printing Most RDS environments today will have a mix of networked and local printers. The highly available desktops will access network printers assigned by GPO s based on AD user groups. The highly configurable desktops may have local printers attached to their thin clients and network printers can be added by GPO or manually. For remote access the built-in Microsoft Easy Print drivers will provide client redirected printing to home printers. This technology uses the printer driver on the home PC rather than that in the virtual desktop. The advantage of this method is that the users home printers can be used without installing a printer driver on their VDI desktop. Backup To have the ability to recover from a host or storage failure anywhere in the architecture, backups are a crucial component of the design. There are several key components of the environment that cannot just be recreated and will need to be periodically backed up to a secure destination. These include the file servers for profile data, Unidesk appliances, RDS component servers, and the SQL database for RDCB. The File servers used to store the profile data should have both scheduled full and periodic incremental backups of the data drives. This allows easy recovery of one use profile from corruption using a recent incremental version, as well as to recover from all data from a storage failure using the full copy. If there already is an agent based backup solution in use elsewhere in the environment this can be used, otherwise Windows Backup built into the operating system is Page 31 of 37

32 sufficient. Daily or weekly full backups and hourly or daily incremental backups are good suggested frequencies. Backups will only be required for the four hosts providing Highly Configurable Desktops, the Unidesk MA and MCP and the RDS components. The following virtual machines will be backed up as virtual machines: Unidesk MA RDCB Servers RD Gateway Servers RD Web Servers SQL Servers The following will be backed up at a file level The Master CachePoint Appliance VM files The Master CachePoint UnideskLayers folder structure and files The Master CachePoint Boot folder structure and files For each of the four Highly Configurable Desktop Hosts (4) o The CachePoint Appliance VM files o The CachePoint UnideskLayers folder structure and files o The CachePoint Boot folder structure and files The following will not be backed up Anything on Highly Available Desktop hosts This design will allow for all the components to be recovered in the environment. Page 32 of 37

33 CachePoint File System Backups For each host with persistent desktops deployed the file system for boot disks and Unidesk Layers will be backed up at a file system level. This will include the CP virtual machine files, desktop boot files and layer files. On the host with the MCP include the MCP in this manner as well. Secondary CachePoint appliances for the hosts providing Highly Available Desktops will not be backed up. If one of these hosts fails for any reason the desktops will be deleted from within Unidesk and recreated once the host is repaired or recreated. RDS Components The RDS component servers should be backed up periodically to avoid having to recreate them, but since all of the broker configuration will be stored in the SQL database, weekly or monthly backups of the virtual machines is sufficient. Again this is only to allow timely recovery from inguest corruption or storage failures, as the virtual servers could be recreated by hand since they store no configuration data. If there is an existing VM level backup solution in use elsewhere in the company, it should be utilized for these machines, each being self-contained. The crucial component that needs to be backed up and protected is the RDCB SQL database. Periodic SQL Transaction logs are required for databases using AlwaysOn as discussed in the SQL section and should be scheduled 1-4 hours within the SQL server management interface to keep Page 33 of 37