with VMware vsphere 5.1 (ESXi)

Transcription

1 Scaling XenDeskto 7 to 5,000 users with VMware vshere 5.1 (ESXi) Citrix Solutions Lab Validated Solutions Design Guide

2 2 Table of contents Contents Citrix XenDeskto 7 6 Executive Summary 7 Project overview 7 Project goals 7 Conclusions 8 Abbreviations and naming conventions 9 Hardware and software used 10 Software 10 Hardware 10 Solutions architecture 11 Users and locations 11 Main office (4,020 users) 11 Large branch office (600 users) 11 Small branch office (120 users) 11 Remote access (840 users) 11 User slit 12 Deskto slit 12 Storage infrastructure 12 Storage architecture design 13 Storage deloyment 13 Network infrastructure 14 Network design 14 Datacenter and remote office LAN network architecture overview 15 WAN network architecture overview 15 Common infrastructure 16 Active Directory 16 Client infrastructure 17 VDI infrastructure modular design 17 Infrastructure deloyment methodology 17 Modular block overview 17 Modular block sizing 18 Modular block infrastructure 19 Click on the section names above to navigate to that ortion of the book and the arrow icon to return to the table of contents from any age.

3 3 Virtual deskto infrastructure virtualization 19 vcenter for VDI infrastructure and deskto hyervisor hosts 20 vcenter SQL 20 VDI infrastructure hyervisors 21 VDI Infrastructure VMs 21 Citrix XenDeskto Site structure 21 Citrix Infrastructure SQL 23 Web Portal StoreFront 24 Profile management 24 Deskto virtualization 24 VDI desktos 25 PVS for VDI desktos 26 Hosted shared desktos 26 PVS for hosted shared desktos 26 Notes 26 VAMT for desktos 26 Test methodology 27 Test overview 27 Success criteria 27 Test tools 27 Test orchestration and workload generation 27 Performance data cature 28 In-session workload simulation 28 Conclusions 29 Notes and lessons learned 30 Aendix A: System inventory 32 Physical systems 32 Network aliances 33 Datacenter 33 Large branch office 33 Small branch office 33 Virtualized systems 34 XenDeskto infrastructure 34 Virtual desktos 35 Other infrastructure 36

4 4 Aendix B: Performance results 37 Storage erformance 37 ESXi Server CPU erformance 38 XenDeskto infrastructure VM erformance 40 Boot storms 40 Memory 42 Networking 42 Steady state test 42 Logon hase 42 Steady state test 44 Memory 46 Networking 46 Summary 47

5 5 More and more enterrises are turning to deskto virtualization as a solution to rising IT costs, security concerns, and the user demands of BYOD and work from anywhere, at any time, from any device. But can a deskto virtualization solution suort thousands of users, both local and remote? How well does a virtual deskto solution scale? This document discusses the environment created in the Citrix Solutions Lab to successfully deloy and suort 5000 virtual deskto users in a multibranch environment. The Solutions Lab was formed to design, architect, and test deloyments of large scale Citrix virtualization solutions from end-oint device to the datacenter, including multi-branch remote locations. This document rovides information about: The Design How Citrix roducts and valued Citrix artner hardware were architected and configured to build a 5000 user, multi-branch solution The Conclusions Based on test results, the conclusions the Solutions Lab team were able to draw and the lessons they learned This document describes virtualization technology design and concets. It covers the overall methodology for configuring and testing a real-world deskto virtualization environment to suort a large number of users. This document does not rovide ste by ste or detailed configuration instructions, but will define the architecture used in testing. This document is intended for the IT rofessional with relevant exerience in virtualization technologies, and rovides guidance when designing large scale virtual deskto environments. In addition, IT and other business executives will gain a better understanding of what s needed to deliver virtual desktos and alications to their users.

6 6 Citrix XenDeskto 7 XenDeskto delivers Windows as and desktos as secure mobile services from a cloud-ready latform while simlifying management, reducing costs and enhancing security. XenDeskto 7 is a simle way to enable emloyees to work from any device. Delivering the best mobile exerience, XenDeskto gives eole the freedom to shift work to a more otimal lace on whatever device they choose, accessing both as and desktos whenever and wherever, over any network connection. When IT can react more quickly to the changing needs of the business and deliver both virtual as and desktos from a single latform, it becomes a valuable asset to the business rather than just a cost. With XenDeskto 7, the business can: Key benefits Mobilize Windows as and desktos for any device Reduce costs of deskto management Secure remote access to businesscritical data Unified architecture simlifies deloyment Deliver secure access to mission-critical business as and data from mobile devices Emower emloyees by roviding 24x7 self-service access to the alications they need from a simle enterrise a storefront Quickly add new emloyees, oen new offices, and start offshore oerations by roviding a full function cororate deskto to new users in a matter of minutes Easily suort teleworking mandates and green initiatives while reducing facility and travel exenses Manage alications, desktos and data centrally, making it easier to rotect sensitive resources and adhere to regulatory comliance standards Recruit to talent from anywhere by offering flexibility and work-life balance by suorting anywhere comuting on a variety of devices Seamlessly ensure high availability and enhance erformance through integrated networking and branch otimization solutions Control the ever-increasing costs of annual PC refresh cycles by centrally managing and delivering virtual as and desktos to any device, including lowcost thin clients XenDeskto 7 is at the center of a remarkable transformation giving IT the ower to mobilize the workforce while realizing lower costs, greater business agility, and virtual as and desktos for any tye of user. Citrix solutions combine virtualization, networking, and cloud comuting technologies to deliver a full ortfolio of offerings that enable virtual workstyles for users and virtual datacenters for IT while utting IT at the center of this transformation.

7 7 Executive Summary This document details the design, deloyment, and validation of the new Citrix Deskto Virtualization architecture available in XenDeskto 7. Project overview XenDeskto 7 integrates Citrix XenA and VDI technologies into a unified architecture, roviding oerational and management efficiencies in regards to the design and deloyment of deskto virtualization. This roject consisted of designing, building, and testing a XenDeskto environment to show how 5000 users can access services across multile geograhic locations, utilizing HP BL460c Gen8 blade servers, an EMC VNX7500 storage array, and VMware vshere 5.1 with Citrix XenDeskto 7, NetScaler, and Branch Reeater technologies. Project goals This Deskto Virtualization test environment was built with the following goals in mind: Validate XenDeskto 7 within a 5000 user environment by leveraging the caabilities of XenDeskto 7 to deloy desktos and alications to three tyes of users; local, remote office, and remote access Create a modular design allowing for linear scalability and growth maintaining a balance of deskto tyes; in the test environment, 64% hosted shared desktos, 18% random VDI desktos, and 18% static VDI desktos with Personal vdisk (PvD) to allow for user customization Design the environment to be highly available and resilient to failure, where ossible, while maintaining business continuity Validate that XenDeskto 7 can suort different tyes of users in different geograhic locations, such as branch office workers and remote access users, with a single ane of glass, centrally managed from the datacenter from deloyment to daily oerations Validate that the test environment would stay within the following defined guidelines, while not encountering the maximum caacity of any individual comonent within that environment No server CPU utilization average to be over 85% while under load Storage to erform within EMC guidelines of resonse times under 10 milliseconds er request 5000 users connect, comlete a test run, and logoff cleanly LoginVSI 3.7 was used as the load generation tool for all users to verify the solution For more information about Login VSI, see the Login VSI website

8 8 Conclusions Testing validated that XenDeskto 7 delivered a resilient solution on VMware vshere 5.1 suorting 5,000+ concurrent users deloyed over a multi-branch solutions environment. StoreFront 2.0 successfully scales using an N+1 model. Provisioning Services (PVS) 7.0 successfully suorted the multile Flexcast models rovided with XenDeskto 7. All infrastructure servers in the environment were successfully virtualized. The new consolidated XenDeskto 7 interface greatly simlified the deloyment and management of different Flexcast models. Utilizing a modular design rovides easy management and scalability. This white aer rovides design considerations and guidelines for a mixed FlexCast model deloyment. The diagram below rovides a high level view of the environment tested. REMOTE SITES DATACENTER Remote Site 1 BR 8800 Module VDI + PvD Users Branch Reeater 8800 Branch Reeater SDX 128 HSD VMs Users HEADQUARTERS SITE Remote Site 2 BR VPX 120 HSD Users Branch Reeater BPX On Citrix XenServer WAN XenDeskto Delivery Controllers 500 VDI VMs 500 VDI + PvD VMs 3020 HSD Users Module VDI Users Remote Site 3 AGEE StoreFront Cluster 128 HSD VMs Users NetScaler AGEE 440 HSD Users 400 VDI + PvD Users 500 VDI VMs 500 VDI + PvD VMs Figure 1: Overview of a XenDeskto 7 multi-site enterrise environment with 5K+ users

9 9 Abbreviations and naming conventions The following abbreviations and naming conventions are used in this document. AG AGEE BR CIFS DHCP DNS HA HDX HSD IOPS iscsi ISL NFS NS NTP PvD PVS RAID TCO VDA VDI vdisk VLAN VM VPX WAN WSFC Access Gateway Access Gateway Enterrise Edition Branch Reeater Common Internet File System Dynamic Host Configuration Protocol Domain Name System High Availability High Definition exerience Hosted Shared Deskto Inut/Outut Oerations Per Second Internet Small Comuter System Interface Inter-Switch Link Network File System NetScaler Network Time Protocol Personal vdisk Provisioning Services Redundant Array of Indeendent Disks Total Cost of Ownershi Virtual Delivery Agent Virtual Deskto Infrastructure Virtual Disk (Provisioning Services Streamed VM Image) Virtual Local Area Network Virtual Machine Virtual Aliance Wide Area Network Windows Server Failover Cluster

10 10 Hardware and software used The following hardware and software was used in the test environment: Software Comonent Version Virtual Deskto Broker Citrix XenDeskto 7 VDI Deskto Provisioning Citrix Provisioning Services 7.0 Endoint Client Citrix Receiver for Windows 4.0 User Profile Management Citrix User Profile Manager 5.0 VDI Personalization Citrix Personal vdisk 7.0 Web Portal Citrix StoreFront 2.0 Licensing Citrix License Server Workload Generator Login VSI 3.7 Office Virtual Deskto OS (VDI Desktos) Virtual Deskto OS (Hosted Shared Desktos) Microsoft Office 2010 SP1 Microsoft Windows 7 x64 SP1 Microsoft Windows Server 2012 Database Server Microsoft SQL Server 2012 VDI Hyervisor Management vcenter Server 5.1 VDI Hyervisor Hardware VMware vshere 5.1 Enterrise Plus Comonent Blade Servers Infrastructure Virtual Deskto Hyervisors Network Aliances WAN Otimization Remote Access Network Devices Backbone Switch Version HP ProLiant BL460c Gen8 HP ProLiant BL460c Gen8 Citrix Branch Reeater 8800, SDX, and VPX Citrix NetScaler/Access Gateway Enterrise Edition Cisco Nexus 7010K 8x32/10G Multi-layer Switches HP H3C 5820, 580 Storage Systems EMC VNX 7500 Additional detail can be found in the Aendix.

11 11 Solutions architecture The diagram below illustrates the architecture of the Citrix XenDeskto test environment. Each comonent deloyed in the test environment is discussed in detail in this section. Large Branch Office Branch Reeater Branch Users Active Directory Branch Reeater SDX Active Directory Small Branch Office Branch Reeater VPX on Citrix XenServer HP H3C 58xx 120 Branch Users Active Directory NetScaler AGEE ESXi Provisioning Server 7.0 XenDeskto 7 Headquarters Datacenter ESXi Deskto OS VDAs Deskto OS VDAs (Random VDI Desktos) (Static VDI Desktos with PvD) Remote Access Office 4020 Headquarters Users 840 Remote Access Users Server OS VDAs (Hosted Shared Desktos) Figure 2: XenDeskto 7 multi-site enterrise environment with 5K+ users Users and locations Main office (4,020 users) The main office location required virtual deskto services with centralized system and deskto image management. Users within the main office comrised rimarily task workers, rovided with a mix of 3020 hosted shared desktos and 1000 random VDI desktos. Large branch office (600 users) Users in the large branch office location needed secure and accelerated remote access to the datacenter-based virtual desktos. These users comrised rimarily engineering staff, rovided with static VDI desktos (with PvD). Small branch office (120 users) Users in the small branch office location also needed secure and accelerated remote access to datacenter-based virtual desktos. These users comrised rimarily sales and administration staff, rovided with hosted shared desktos. Remote access (840 users) Access Gateway was chosen to rovide secure, remote access to remote users. These users comrised a mix of staff, rovided with a mix of 400 hosted shared desktos and 440 static VDI desktos (with PvD).

12 12 User slit Site Number of users Percentage of users Main office % Remote % Deskto slit Model Number of desktos Percentage of desktos Hosted shared deskto % Random VDI deskto % Static VDI deskto (with PvD) % The deskto tye slit was designed based on customer inut. A large majority of customers deloy a significant amount of hosted shared desktos to users, because their needs are relatively simle. More comlex task workers get a random VDI deskto instead of a hosted shared deskto. High-level workers who require the ability to ersonalize their desktos are rovided with static VDI desktos (with PvD) to allow for that ersonalization. Rather than working with dedicated desktos, the static VDI deskto (with PvD) construct solves the ersonalization requirement whilst still roviding a lower TCO. Storage infrastructure The EMC VNX family delivers industry leading innovation and enterrise caabilities for file, block, and object storage in a scalable, easy-to-use solution. This next-generation storage latform combines owerful and flexible hardware with advanced efficiency, management, and rotection software to meet the demanding needs of today s enterrises. All of this is available in a choice of systems ranging from affordable entry-level solutions to high erformance, etabyte-caacity configurations servicing the most demanding alication requirements. The VNX family includes the VNXe series, urose-built for the IT generalist in smaller environments, and the VNX series, designed to meet the high-erformance, high scalability, requirements of midsize and large enterrises. The EMC VNX 7500 unified storage latform is at the to of the line of the VNX series. It is owered by Intel quad-core Xeon 5600 series rocessors and delivers five 9 s of availability. It is designed to deliver maximum erformance and scalability for enterrises, enabling them to dramatically grow, share, and cost-effectively manage multi-rotocol file and block systems. It suorts u to 1000 drives and eight X-Blades (also known as Data Movers) for file rotocol suort. A single EMC VNX 7500 aliance was utilized to rovide storage for the test environment. The solution was validated using NFS for data storage of virtual desktos, SQL databases, and infrastructure virtual machines such as delivery

13 13 controllers, vcenter Servers, and other suorting services. CIFS was configured for rofile management and for PVS vdisks. Storage architecture design In a large scale PVS deloyment, the otion tyically chosen for the PVS write cache destination is Cache on device hard drive to achieve higher scalability and allow ease of manageability and agility. In a virtualized environment, this cache area resides in the virtual hard disks attached to the virtual machines, and is IO intensive because, while the PVS servers absorb most of the read IOPS for the virtual desktos, all writes are redirected to the write cache area. As the write cache area is write intensive by nature, Citrix recommends designating RAID 10 storage ools on the VNX for PVS write cache to minimize the RAID enalty incurred by RAID 5 or other similar RAID tyes. Because EMC VNX arrays suort RAID 10 ools with multiles of eight drives, Citrix recommends using that drive count unit as the building block while the number of deloyed desktos continues to scale. In the test environment, the storage ools used to store PVS write cache for both hosted shared desktos and VDI desktos were made u of 64 and 24 SAS 15K drives resectively. Storage deloyment Four data movers (storage filer heads) in a single EMC VNX 7500 were utilized, with two assigned to suort virtual desktos, one assigned to infrastructure, and one configured for failover. The following table defines the number of drives associated with each storage ool, the rotocol used in accessing the ool, the RAID configuration, and whether or not EMC VNX 7500 FAST Cache was used in accessing the ool. EMC FAST Cache is a storage erformance otimization feature that rovides immediate access to frequently accessed data. For more information see the EMC website. Drive count Drive tye Protocol RAID FAST Cache Infrastructure VMs 10 SAS NFS 5 N SQL database/quorum 5 SAS NFS 5 N HSD/VDI deskto vdisk 5 SAS CIFS 5 Y HSD Write Cache 64 SAS NFS 10 Y Random VDI deskto Write Cache Static VDI deskto Write Cache 24 SAS NFS 10 Y 24 SAS NFS 10 Y

14 14 Drive count Drive tye Protocol RAID FAST Cache PvD 20 SAS NFS 5 Y User Profiles 15 SAS CIFS 5 N VNX system drives 4 SAS N/A 5 N/A FAST Cache drives 10 SSD N/A 1 N/A Hot sares 6 SAS N/A N/A N/A Hot sare 1 SSD N/A N/A N/A SAS used 171 The FAST Cache SSD drives were 200GB in size. Using EMC best ractices, a maximum of 250 VMs was used for each NFS datastore in VShere. Network infrastructure The next consideration for this environment was the network architecture and design. The network architecture for the test environment included, but was not limited to, the creation of IP address requirements, VLAN configurations, required IP services, and server network configurations. Considerations regarding IP allocation, IP block assignment, and WAN Routing were extremely imortant in ensuring that the design maintained its modularity. Large Branch Office Branch Reeater Branch Users Branch Reeater SDX Small Branch Office Headquarters Datacenter 120 Branch Users Branch Reeater VPX on Citrix XenServer HP H3C 58xx 4020 Headquarters Users NetScaler AGEE Remote Access Office 840 Remote Access Users Figure 3: Network diagram for XenDeskto 7 multi-site enterrise environment with 5K+ users Network design When lanning the network environment, it was imortant to determine how many nodes would be needed at the beginning of the roject and how many would need to be added throughout the lifetime of the roject. Once known, lanning of the IP address blocks could begin.

15 15 It is desirable to emloy a modular aroach to network VLAN design. Traffic searation is efficient for VDI IP considerations and alleviating bandwidth traffic concerns. If ossible, create a searate VLAN for certain tyes of traffic. For examle, a Storage VLAN for storage traffic (that is iscsi, NFS, or CIFS), DMZ s for certain external incoming traffic tyes, a server management VLAN (which may include Lights-Out caabilities and log gathering mechanisms), and Guest VLANs for virtual desktos. This tye of design aroach kees layer 2 broadcasts to a minimum while not over-utilizing the CPU and memory resources of network devices. Design considerations As a design consideration, the chunks of deskto growth have an imact on how a network is designed. A /24 network allows for growth in chunks of 200 VDI desktos, while a /23 network allows for growth in chunks of 500 desktos. By lanning the network design with growth and a buffer considered, blocks can be aggregated in chunks of /24 s, /23 s, and /22 s (1024 hosts) as needed. Datacenter and remote office LAN network architecture overview The Cisco Systems Nexus 7010K Core Switch with eight cards and 32 10GbE orts rovided the datacenter multilayer switching and routing services. This switch also rovided all routing, switching, and security services for the rest of the environment. H3C/HP GbE switches served other 10GbE service orts. Also, 1GbE orts were served by H3C/HP GbE switches with 10GbE ulinks. For branch office sites, workgrou switching and routing were required. The 1GbE orts required were rovided by H3C/HP GbE switches, which incororated 10GbE ulinks to the core infrastructure. No latencies were introduced to the LAN configuration. WAN network architecture overview The lanning for the multisite WAN test environment included lanning for VLAN and other network-based services, suorting both virtualized and hysical systems, and roviding for WAN, DMZ, and firewall connectivity. Planning also included lacing network service aliances, such as Branch Reeater and NetScaler systems, in correct, logical network locations. The test environment WAN routing at the datacenter was rovided by a single Cisco core switch, as mentioned above. To meet the requirement for roviding aliance-to-aliance ICA otimization for the XenDeskto virtual desktos access in the environment, BR-SDX aliances were deloyed in a HA configuration at the datacenter. Standalone BR aliances (8800-series and virtual aliances) were deloyed at each of the branch office locations. Branch site Layer-3 routing and edge services were rovided by H3C 58XX Series multi-layer switch router devices. A Branch Reeater 8800-series aliance was selected for the large branch office (600 users) and a Branch Reeater virtual aliance (VPX) for the small branch office (120 users). A Branch Reeater SDX aliance Model was used to allow for a single connection oint for remote Branch Reeater connections at the datacenter.

16 16 For remote access users, ICA Proxy and VPN services were required. To meet this requirement, a NetScaler aliance with an Access Gateway Enterrise Edition license was deloyed in the datacenter. LACP 802.3AD was used for all ISL s between all devices. Design considerations Each network aliance is limited by the number of connections that they can suort; most network aliances list the maximum number of TCP connections that they suort. In the Citrix VDI environment, the ICA connection caacity of the Remote Access and WAN Acceleration devices needs to be considered. It is necessary to match this caacity with the site user requirements, while including a buffer for future site growth. To otimize storage communications in the environment, Citrix recommends using a dedicated VLAN for server to storage connections. Consider searating heavy network traffic in a dedicated VLAN so that it does not interfere with other traffic. Ulinks between all network switches at Layer 2 should emloy 802.3ad LACP Ethernet aggregation for increased throughut and resiliency. To determine the overall bandwidth needed, it is necessary to know the bandwidth required er session. The number of ossible remote site sessions is directly roortional to the bandwidth. Common infrastructure The common infrastructure comonents, those normally already in lace in a datacenter environment (including, but not limited to Active Directory, DNS, DHCP, and NTP), were hosted on VMs outside of the XenDeskto environment deloyed for this test. Active Directory A Windows 2008 R2 four-site Active Directory with a Single Forest, Single Domain structure was deloyed. Two Domain Controllers were deloyed in each site for redundancy and each site hosted its own AD-integrated DNS and DHCP.

17 17 Active Directory Domain Controller Large Branch Office BR1 AD Site Branch Reeater 8800 Active Directory Domain Controller Active Directory Domain Controller Branch Reeater SDX Active Directory Domain Controller Small Branch Office BR2 AD Site Branch Reeater VPX on Citrix XenServer HP H3C 58xx Headquarters Datacenter DC AD Site Active Directory Domain Controller NetScaler AGEE Active Directory Domain Controller Active Directory Domain Controller Remote Access Office AGEE AD Site Active Directory Domain Controller Figure 4: Active Directory multi-site structure Client infrastructure A significant LoginVSI client environment was required for the test environments large-scale deloyment. Almost 300 VSI client launchers were deloyed for over 5000 indeendent ICA sessions. All client launcher systems were virtualized in a comletely searate XenServer environment. VDI infrastructure modular design With the common infrastructure in lace, the next ste was to design, create, and configure the infrastructure that would suort the first modular block. After that first block of users was built and tested an additional modular block was deloyed. This section outlines the modular VDI infrastructure that was used along with the modular block sizing and configuration of the VShere environment, vcenter, PVS, and SQL Server. Infrastructure deloyment methodology Similar to the common infrastructure deloyment methodology, the modular infrastructure utilized HP Insight Control for the deloyment of the oerating system. The VDI infrastructure was hosted on HP BL460c Gen8 blade servers. Modular block overview One modular block (c-block) contained one cluster for each deskto tye (random VDI, static VDI (with PvD), and hosted shared) and the suorting infrastructure for them.

18 18 Common Network Infrastructure (AD, DNS, NTP, DHCP) Shared XenDeskto Infrastructure (Delivery Controller, Infrastructure Hyervisor Cluster) Modular Block 2790 Users 500 Random VDI Deskto VMs 500 Static VDI Deskto (with PvD) VMs 128 Hosted Shared Deskto VMs Modular Block 2790 Users 500 Random VDI Deskto VMs 500 Static VDI Deskto (with PvD) VMs 128 Hosted Shared Deskto VMs Shared Remote Access Technologies (BR-SDX, AGEE) Figure 5: Modular block diagram Modular block sizing When scaling u a VDI environment from a single server to a modular block, it is imortant to understand the hardware along with its caacity and erformance caabilities and limitations. This is imortant not only for each comonent, but also for the entire system working together. Finding the otimal design involves multile cycles of testing, troubleshooting, and resolution of issues. This leads to a design where every comonent within the system has the ability to handle the exected load easily. In the test environment, the first ste in this rocess was to determine single-server VM density. Based on this information, density numbers for a single cluster of users was calculated. Because there were three different FlexCast models in the test environment, three cluster sizes were defined as follows: For random VDI desktos, a single cluster consisted of six servers For static VDI desktos (with PvD), a single cluster also consisted of six servers, but the density was reduced slightly in order to rovide a level of resiliency for the PvD infrastructure For hosted shared desktos, a single cluster consisted of 16 servers

19 19 Following on from those calculations, the three different clusters were combined to build a modular block (or c-block) of users. In the test environment, each block was built to suort 2790 users. Two of these blocks were combined to build the entire environment. With static VDI desktos (with PvD), there is sometimes a concern over availability. In other environments, if a server running a deskto with PvD fails, the rocess of connecting an existing PvD to a new deskto can be time-consuming, unless there is some level of resiliency allowing that deskto to boot on a different server. To alleviate that concern in the test environment, the static VDI deskto (with PvD) clusters were configured for high availability. In the six-node clusters, only five Hosts were deloyed, leaving one Host for failover. Load balancing across the cluster, however, resulted in all six Hosts running at aroximately 60-70% of maximum caacity to accommodate a Host failure. This resulted in the servers running at aroximately 85% of maximum caacity after a single Host failure (maintaining erformance at the desired level) and at aroximately 100% of caacity after a double Host failure. Each cluster was hardware secific and each module included one cluster er deskto tye, as follows: 16-blade cluster for Windows 2012 hosted shared desktos 6-blade cluster for Windows 7 random VDI desktos 6-blade resilient cluster for Windows 7 static VDI desktos (with PvD) Modular block infrastructure The environment was built with two modular blocks, resulting in aroximately 5500 net users. Virtual deskto infrastructure virtualization VDI virtualization management

20 20 6 Host Random VDI Deskto ESXi Cluster 6 Host Static VDI Deskto (with PvD) ESXi Cluster 6 Host Random VDI Deskto ESXi Cluster 6 Host Static VDI Deskto (with PvD) ESXi Cluster MODULAR BLOCK 1 16 Host Hosted Shared Deskto ESXi Cluster MODULAR BLOCK 2 16 Host Hosted Shared Deskto ESXi Cluster VC HB vcenter Server 1 vcenter Failover Server 2 VDI Infrastructure ESXi Cluster Figure 6: vcenter Server and ESXi Clusters management structure vcenter for VDI infrastructure and deskto hyervisor hosts The ESXi 5.1 hyervisor hosts in the test environment were managed by vcenter Server 5.1, configured as follows: vcenter Server was configured with High Availability rotection rovided by vcenter Server Heartbeat 6.5. The rimary and secondary vcenter Servers were virtualized on searate ESXi hosts. vcenter SQL A SQL backend database was required for vcenter. A set of virtual SQL servers was utilized in the test environment, configured as follows: SQL servers ran on Windows 2008 R2 ESXi VMs. SQL Server 2008 R2 Database Mirroring was configured using three servers: Princial, mirror, and witness EMC VNX 7500 NFS VMDK s were used for database storage: 100GB attached to both rincial and mirror SQL server VMs The witness server was a searate Windows 2008 R2 VM

21 21 Note: To use Windows Server Failover Clustering with SQL Server would have required Block storage (Fibre Channel or iscsi). In the test environment, only NFS storage was available and clustering was not utilized. VDI infrastructure hyervisors Infrastructure comonents, including Delivery Controllers and Provisioning Servers, were deloyed on HP BL460c Gen8 blade servers running ESXi 5.1 in an 8-node ESXi cluster, configured as follows: VMWare Standard Virtual Switch (vswitch) Managed by the rimary vcenter Server Shared Storage for infrastructure VMs hosted as an NFS datastore on EMC VNX 7500 VDI Infrastructure VMs The VDI Infrastructure VMs were configured as follows: Windows 2008 R2 SP1 was installed Given a static IP address and static DNS entry in the AD-integrated DNS RDS Licenses for Windows 2008 R2 (Infrastructure VMs) and Windows Server 2012 (hosted shared deskto VMs) were rovided by a standalone Windows Server 2012 VM configured with the RD Licensing role. This VM was set u exressly to rovide RDS licenses. Citrix XenDeskto Site structure The XenDeskto Site in the test environment was configured as a single XenDeskto 7 Site containing the following comonents: Three Delivery Controller VMs running on ESXi for HA (2 +1) The XenDeskto Site Database running as a SQL Server 2012 AlwaysOn High Availability Grou Citrix Licensing Server running as a stand-alone VM

22 22 License Server Delivery Controller 1 (Broker) SQL Server 2012 AlwaysOn HA Grou vcenter Server 6x ESXi Clusters 12x NFS Datastores (2 er cluster) Delivery Controller 2 (Host Management) 1 x Host Connection 12 x Provisioning Server - 4 Hosted Shared Desktos - 4 Static VDI Deskto (with PvD) - 4 Random VDI Desktos 12 x Machine Catalog - 4 Hosted Shared Desktos - 4 Static VDI Deskto (with PvD) - 4 Random VDI Desktos 3 x Delivery Grou - 1 Hosted Shared Deskto) - 1 Static VDI Deskto (with PvD) - 1 Random VDI Deskto XenDeskto Site Database Delivery Controller 3 (HA) Figure 7: XenDeskto Site structure Citrix XenDeskto structure To facilitate management and troubleshooting for the large, multi-connection, multi-cluster environment, XenDeskto was configured as follows: A single Machine Catalog er cluster/datastore: 2 Clusters for hosted shared desktos/2 NFS datastores each 4 Machine Catalogs 2 Clusters for random VDI desktos/2 NFS datastores each 4 Machine Catalogs 2 Clusters for static VDI desktos (with PvD)/2 NFS datastores each 4 Machine Catalogs One Delivery Grou er deskto tye The connection between XenDeskto and vcenter Server was configured with custom advanced settings, as shown in the following table: Setting Value Max active actions: 96 Max new actions er minute: 80 Max ower actions as ercentage of desktos: 4% Max Personal vdisk ower actions as ercentage: 10% The default settings were adjusted rimarily to accommodate the number of hosts vcenter was managing and to control the load on hyervisor hosts and Provisioning Servers for otimal erformance during the boot storm. In this configuration the boot storm for all deskto VMs comleted within aroximately 30 minutes.

23 23 Citrix Infrastructure SQL Three Windows 2008 R2 ESXi VMs were configured as a Windows Server Failover Cluster for the XenDeskto SQL server. SQL Server 2012 was configured as an AlwaysOn Availability Grou. Storage for these VMs was rovided by a dedicated NFS datastore er server to ensure high erformance. A dedicated CIFS share was rovided for data synchronization and backu uroses with an additional CIFS share used for the WSFC witness. EMC VNX 7500 SQL Server 2012 DB Storage NFS Volume SQL Server 2012 DB Storage NFS Volume SQL Server 2012 AlwaysOn Seed CIFS FileShare SQL Server 2012 DB Storage NFS Volume Windows Cluster Quorum CIFS FileShare XenDeskto Site Database Backu NFS Database On ESXi NFS Datastore On ESXi NFS Datastore On ESXi SQL Server VM 2nd Drive VMDK SQL Server VM 2nd Drive VMDK SQL Server VM 2nd Drive VMDK SQL Server 2012 AlwaysOn Grou ESXi Cluster XenDeskto Site Database XenDeskto Site Database Relica NFS XenDeskto Site Database Relica SQL Server 2012 Server 1 ESXi VM SQL Server 2012 Server 2 ESXi VM SQL Server 2012 Server 3 ESXi VM AlwaysOn Listener IP Citrix XenDeksto Figure 8: SQL Server 2012 structure

24 24 Web Portal StoreFront Web Portal services were delivered by three StoreFront 2.0 VMs deloyed in the Infrastructure cluster. A dedicated active-assive air of NetScaler VPX virtual aliances (with a single Virtual IP) was used to load-balance the StoreFront VMs. An additional stand-alone StoreFront VM was configured to allow for AGEE integration due to the limitations of the test harness. NetScaler VIP for StoreFront Load Balancing NetScaler VPX NetScaler VPX StoreFront Server StoreFront Server StoreFront Server StoreFront Server For AGEE Figure 9: StoreFront deloyment Profile management Profile management was rovided by Citrix Profile Management 5.0. Three Profile management olicies were created, one er deskto tye, with the following settings: Policy Delete locally cached rofiles on logoff Static VDI desktos with PvD Random VDI desktos Hosted shared desktos Disabled Enabled Enabled Profile streaming Enabled Enabled Enabled Always cache Disabled Disabled Disabled Active write back Enabled Enabled Enabled Process logons of local administrators Deskto virtualization Deskto hyervisors Enabled Enabled Disabled All virtual desktos were hosted on HP BL460c Gen8 blade servers running ESXi 5.1, configured with the following system settings:

25 25 PXE NIC #1 as the first boot device in Boot Order HP Power Regulator P-state set to Pmax Jumbo Frames for storage connection to EMC Four networks configured: Management Storage vmotion Guest Note: The Guest network was configured to rovide one VLAN for each deskto cluster, as detailed below. Deskto hyervisor clusters The networking for the hyervisor clusters utilized a VMware Distributed Switch (VDS), configured as follows: Management VLAN Storage VLAN vmotion VLAN Guest 1 VLAN (hosted shared desktos) Guest 2 VLAN (hosted shared desktos) Guest 3 VLAN (VDI desktos) Note: Guest VLAN for VDI desktos is the same across all clusters. Deskto deloyment VDI desktos VDI desktos were configured with 1000 in total, 500 er cluster for both random VDI desktos and static VDI desktos (with PvD). Each deskto was configured as follows: Windows 7 x64 OS 1.5GB / 1 vcpu VMXNet3 NIC 40GB HDD (Master/vDisk) 3GB Windows Page File 4GB Write Cache Cache on Device HDD 10GB Personal vdisk (Static VDI desktos only)

26 26 PVS for VDI desktos PVS 7.0 was virtualized in the VDI infrastructure cluster as a single PVS farm, containing: 4 servers 1 site 1 vdisk store 2 vdisks (One each for static VDI desktos (with PvD) and random VDI desktos) A single server thread er streamed virtual deskto VM Hosted shared desktos Hosted shared desktos were configured with 256 in total, 128 er cluster, allowing for 1790 sessions er chassis, 3580 sessions total. Each Host was configured as follows: Windows Server GB / 4 vcpu VMXNet3 NIC 60GB HDD (Master/vDisk) 18GB Windows Page File 25GB Write Cache Cache on Device HDD PVS for hosted shared desktos PVS 7.0 was virtualized in the VDI infrastructure cluster as a single PVS farm, containing: 4 servers 2 x 2 sites (PVS site er VLAN = ESXi hosted shared deskto chassis) 2 vdisk stores (One er cluster) 1 vdisk er store Notes For hosted shared desktos, the Windows Page file was based on 1.5x RAM; for VDI desktos it was based on 2x RAM. For both hosted shared and VDI desktos, Write Cache was based on 2x RAM + 1. Memory Ballooning was disabled for all deskto VMs as er best ractices. VAMT for desktos Microsoft VAMT 3.0 was deloyed to allow for both Windows and Microsoft Office activation verification.

27 27 Test methodology All validation testing was erformed on-site at the Citrix Solutions Lab. The focus of testing was on caturing boot-u, user logon, user logoff, and steady state metrics during the entire rocess of the virtual deskto lifecycle. Test metrics were gathered for all comonents under test such as the hyervisor, virtual deskto, and storage and from the workload generation system, Login VSI, to determine the overall success of a test run. Each test run would need to be within the threshold of the success criteria as defined below to consider it a assing run. A test rocedure is followed to rovide consistency between runs. Test overview The following test rocedure was used for each test run to ensure consistent results: Before each test, all deskto VMs and clients were cleanly started. All deskto VMs and client launchers were Idled for an hour for consistent results. Boot Phase All deskto VMs needed to ower on and register within one hour. Logon Phase All user sessions were launched and active in Login VSI within one hour. Test Phase At least two Login VSI loos were executed in each active session. Logoff All users logged off after VSI comletion. Test run reorts and data were generated. All deskto VMs and clients were shut down. Success criteria Performance metrics were used to ensure the systems were not overloaded during the different tests. The main success criteria for the 5000 user, multi-branch test was to have 5000 active deskto sessions, to have a successful in-session workload execution from start to finish, and to ensure no single comonent in the deloyment became overloaded. Test tools Test orchestration and workload generation The rimary test tool used in the environment was Login VSI 3.7, consisting of the VSI Client Launcher, VSI Workload, VSI Console, and VSI Analyzer alications. Login VSI 3.7 was used as the test orchestration and workload generation system to create the load of multile users accessing the XenDeskto 7 environment and executing a tyical user workflow within a session. After all users had logged on, the test was configured to simulate each user executing two Login VSI loos before logging off, with each loo minutes long.

28 28 Login VSI Console and Analyzer were used to orchestrate the test launch and analyze test results for all executed test runs. Performance data cature Windows Performance Monitor was used to collect data for all major systems during each test run. This rovided close to real-time erformance monitoring during the test and in-deth historical data analysis after test comletion. All desired data including systems metrics was collected and stored. Citrix Command Center was used to collect data for Branch Reeater and NetScaler aliances. In-session workload simulation Login VSI is a ublicly available tool from Login VSI B.V. that rovides an in session workload reresentative of a tyical user. A redefined medium workload that simulates knowledge user working was used for this test. Flash redirection was not enabled. The redefined workload was used to simulate user activities during the test and to find the maximum number of active sessions that the environment was able to handle. The workload scrit was running on the server-side deskto and the generated traffic stream was almost urely downstream. For more information about Login VSI, see the Login VSI website.

29 29 Conclusions The rimary objective of testing was to show that XenDeskto 7 could suort 5000 users in a multi-branch configuration, using multile FlexCast models and a modular hardware aroach for scaling. As stated earlier, hosted shared desktos, random VDI desktos, and static VDI desktos (with PvD) were deloyed in the datacenter and combinations of the three were deloyed in the remote site locations. The defined success criteria were: No server CPU utilization average to be over 85% while under load Storage to erform within EMC guidelines 5000 users connect, comlete a test run, and disconnect cleanly The testing was executed as lanned, the success criteria were met, and it was shown that XenDeskto 7 did meet the initial objective. Detailed erformance data for storage and ESXi Hosts is available in Aendix B.

30 30 Notes and lessons learned All infrastructure servers in the test environment were virtualized, reducing the number of hysical servers required. Eight hysical servers were used to suort the required infrastructure VMs, including Delivery Controllers, PVS servers, and SQL Servers. 27 Infrastructure VMs were created to suort testing: XenDeskto 3 Delivery Controller VMs 3 SQL Server VMs with AlwaysOn features configured PVS (Virtual) 4 VMs in a VDI deskto farm 4 VMs in a hosted shared deskto farm Storefront 3 VMs in a cluster for both the datacenter and two remote sites 1 VM for AGEE vcenter 2 vcenter VMs 2 vcenter SQL Server VMs 1 Command Center VM 1 SQL Server VM for Command Center NetScaler 2 NS VPX VMs License Server VM All XenDeskto 7 server comonents and the infrastructure required to suort those comonents were virtualized. The environment was oversized to revent limitations in trying to achieve the 5000 user goal. The aendices rovide erformance data and guidelines as to where the test environment could have been sized more aroriately. Virtualizing SQL Server 2012, including the AlwaysOn features, removed the SQL Server quorum requirement in some instances. XenDeskto 7 includes a new environment test service. This service checks and validates certain asects of an environment, such as network and server access,

31 31 during the installation rocess. This offers customers increased confidence that XenDeskto will deloy successfully. During deloyment of the test environment, all checks were assed and all comonents were deloyed successfully. By default, XenDeskto 7 rovides users with an otimized grahic exerience. During testing, all desktos were configured to rovide default otimized grahics exerience with Deskto Comosition enabled. No flash remoting was utilized. The test environment was designed using a modular architecture. Each module suorted 2500 users. This modular aroach allowed testing to begin at a small scale, using only a single module, before adding another module, configured in the same way, to obtain the desired 5000 user count. Following this rocess would have allowed the environment to scale ast 5000 users easily. Citrix recommends designing a deloyment using a modular architecture to enable customers to simlify scaling and management. During testing, over 5500 sessions connected and executed successfully. Less than 1% of sessions failed to connect out of 5580 sessions started. The connection failures analyzed were commonly due to either networking or test tool timing issues. Changes to workflow and version caabilities in Provisioning Services 7.0 imroved both vdisk image management and VM deloyment. vdisk versioning allows image files to be udated simly and quickly. Changes to the PVS Target Device Service enable the creation and formatting of the write cache drive automatically during VM deloyment. Previous versions required the administrator to create the write cache drive manually as art of a temlate. The default write cache vdisk model rovisioned for ESXi in the XenDeskto Setu wizard is a thin rovisioned vdisk. For information about overriding the default tyes of write cache disks created by rovisioning deloyments on ESXi and the defaults for other hyervisors, see the Provisioning Services 7.0 content in edocs. Three StoreFront servers were configured in a cluster for the datacenter and remote branch sites. When evaluating the erformance of the Storefront cluster it was concluded that two servers in a cluster would have been sufficient for the entire workload, allowing for both High Availability and a single StoreFront server failure. A searate StoreFront server was created for Access Gateway users, because of the requirements of the test tool to use Python for certain user access. To revent conflicts between Python and SFConnect, traffic was filtered through searate StoreFront servers. From a hardware ersective, each Host was configured with 192GB of memory and each virtual deskto VM with 1.5GB of memory. This limited the maximum number of sessions er Host to 128, not allowing any memory for the Host itself. A conservative 10GB of memory was allowed for ESXi, ensuring 120 VMs could comfortably fit into the remaining memory. Hosts were configured in this way to avoid aging and swaing at either VM or Host level.

32 32 Aendix A: System inventory Physical systems HP BL 460c Gen8 with ESXi 5.1 x for Hosted Shared Desktos (2 x 16) 24 for XenDeskto Virtual Desktos (2 x 2 x 6) 8 for Infrastructure Function Citrix Infrastructure Virtualization Static VDI Desktos (with PvD) Random VDI Desktos Hosted Shared Desktos Hardware Model Member Host Count Number of Network Cards VLAN Configuration HP BL460c Gen8 HP BL460c Gen8 HP BL460c Gen in total; 4 utilized Management Storage 8 in total; 4 utilized Management Storage 8 in total; 4 utilized Management Storage HP BL460c Gen8 8 in total; 4 utilized Management Storage Guest Guest Guest Guest Shared Storage Protocol Shared Storage Tye Oerating System HA/Resiliency Configuration vmotion vmotion vmotion vmotion NFS v3 NFS v3 NFS v3 NFS v3 EMC VNX 7500 EMC VNX 7500 EMC VNX 7500 EMC VNX 7500 VMWare ESXi 5.1 No HA VMWare ESXi 5.1 High Availability enabled VMWare ESXi 5.1 No HA VMWare ESXi 5.1 No HA

33 33 Network aliances Datacenter Branch Reeater SDX (x2) Device Model Role Version Branch Reeater SDX SDX Datacenter Branch Reeater NetScaler AGEE (x2) NetScaler 9.3, Build Branch Reeater VPX 6.2.0, Build Device Model Role Version NetScaler MPX Datacenter Access Gateway NetScaler VPX XenServer NetScaler 9.3, Build 60.3 Device Model Role Version NetScaler VPX for ESXi StoreFront Load Balancing Large branch office Physical Branch Reeater 8800 NetScaler 10, Build 74.4 Device Model Role Version Branch Reeater Small branch office Virtual Branch Reeater Reeater 8820 SM88 Series 3 Remote Site Branch Reeater Branch Reeater VPX 6.2.0, Build Device Model Role Version Branch Reeater VPX on XenServer 5.6 Remote Site Virtual Branch Reeater Branch Reeater VPX 6.2.0, Build

34 34 Virtualized systems XenDeskto infrastructure Function Hardware Model Number of vcpus Number of Cores Citrix XenDeskto Delivery Controller Citrix Provisioning Server Citrix License Server Citrix StoreFront Server (Main and Branch Office connections through Branch Reeater) Citrix StoreFront Server (Remote connections through AGEE) ESXi VM ESXi VM ESXi VM ESXi VM ESXi VM Memory 8GB 16GB 4GB 2GB 8GB Network Configuration 1 Network Card 2 Network Cards: 1 Management 1 Streaming Network 2 Network Cards: 1 Management 1 Streaming Network 1 Network Card 1 Network Card Hard Drive 60GB 60GB 60GB 60GB 60GB Oerating System Software Windows 2008 R2 Citrix XenDeskto 7 Windows 2008 R2 Citrix Provisioning Server 7.0 Windows 2008 R2 Citrix Licensing Server Windows 2008 R2 Citrix StoreFront 2.0 Windows 2008 R2 Citrix StoreFront 2.0

35 35 Virtual desktos Function Streamed Static Personalized Deskto (with PvD) Streamed Random Personalized Deskto Hardware Model ESXi VM ESXi VM ESXi VM Number of vcpus Number of Cores Memory 1.5GB 1.5GB 12GB Network Configuration Hard Drive Streamed Hosted Shared Deskto 1 Network Card 1 Network Card 1 Network Card 40GB Master 40GB Master 60GB Master Oerating System Software 4GB Write Cache 4GB Write Cache 25GB Write Cache Windows 7 x64 Windows 7 x64 Windows Server 2012 Citrix Virtual Delivery Agent 7.0 Citrix Provisioning Services 7.0 Target Device Software Login VSI 3.7 Microsoft Office 2010 Citrix Virtual Delivery Agent 7.0 Citrix Provisioning Services 7.0 Target Device Software Login VSI 3.7 Microsoft Office 2010 Citrix Virtual Delivery Agent 7.0 Citrix Provisioning Services 7.0 Target Device Software Login VSI 3.7 Microsoft Office 2010

36 36 Other infrastructure Function SQL 2012 Server Hardware Model Number of vcpus Number of Cores VMWare vcenter 5.1 SQL 2008 R2 for vcenter Citrix Command Center SQL 2008 R2 for Command Center ESXi VM ESXi VM ESXi VM ESXi VM ESXi VM Memory 16GB 16GB 32GB 16GB 16GB Network Configuration 1 Network Card 2 Network Cards: 1 Management 1 Network Card 1 Network Card 2 Network Cards: 1 Management Hard Drive 60GB for OS and Alications 1 Streaming Network 60GB 60GB for OS and Alications 60GB 1 Streaming Network 60GB Oerating System Software 120GB for Database Storage Windows 2008 R2 Microsoft SQL 2012 Windows 2008 R2 VMWare vcenter GB for vcenter Database Windows 2008 R2 Microsoft SQL 2008 R2 x64, Cluster Node Windows 2008 R2 Citrix Command Center 5.1 Windows 2008 R2 Microsoft SQL 2008 R2 x64 VMware Heart Beat 6.5 Server 7.0

37 37 Aendix B: Performance results Storage erformance The EMC VNX 7500 rovided the storage for the test environment. The VNX 7500 consisted of three Data Movers, labeled SRV_2, SRV_3, and SRV_4, suorting NFS volumes and CIFS shares. The FAST Cache caability of the VNX 7500 was leveraged to imrove IOPS erformance. SRV_2 and SRV_3 suorted hosted shared desktos, VDI desktos, and the XenDeskto 7 infrastructure. SRV_4 suorted the common infrastructure and clients. EMC Server Boot NFS total Boot NFS read Boot NFS write Boot CIFS total Boot CIFS read Boot CIFS write SRV_ SRV_ SRV_ Total Figure 11: Table showing boot storm IOPs eak load values during testing EMC Server Test NFS total Test NFS read Test NFS write Test CIFS total Test CIFS read Test CIFS write SRV_ SRV_ SRV_ Total Figure 12: Table showing max eak load during the 5,580 user test run EMC Server Average NFS read resonse time (ms) Login VSI test Average NFS write resonse time (ms) Average NFS read resonse time (ms) Boot storm test Average NFS write resonse time (ms) SRV_ SRV_ Figure 13: Table showing NFS read and write resonse time in milliseconds When looking at read and write times for NFS, single digit resonse times are otimal. In the above table both read and write averages are in the single digit range, even during the boot rocess. Peaks during the boot and test runs did exceed the single digit recommendation, but overall erformance was within accetable boundaries.

38 38 EMC recommends keeing the number of VMs er data mover under 2000 VMs. The XenDeskto environment had around 2250 VMs total. Taking into account this information, SRV_ 4 workload could have been suorted by SRV_2 and SRV_3, eliminating the need for one of the data movers. For more information about EMC FAST Cache and VNX 7500, visit ESXi Server CPU erformance One of the success criteria for the test was to kee the CPU utilization across the hysical servers under an 85% average utilization. The hysical servers were broken out into roles, with clusters of ESXi servers assigned to each set of roles. For the hosted shared deskto, random VDI deskto, and static VDI deskto (with PvD) roles two clusters of servers were created. A single cluster was created for the VDI Infrastructure hysical servers. The following table shows the hysical servers defined by roles, clusters, Average CPU Utilization across the clusters, and the CPU Utilization of each hysical server within the role. Generic role Random VDI Deskto Clusters Test hase rocessor % (average) VDINPVDCLS1 (ESXi) VDINPVDCLS2 (ESXi) Random VDI Deskto Per Server Averages Static VDI Deskto (with PvD) VDIPVDCLS1 (ESXi) VDIPVDCLS2 (ESXi) Static VDI Deskto (with PvD) Per Server Averages

39 39 Generic role Hosted Shared Deskto Clusters (SHDR2E04C1 (ESXi) SHDR2E04C2 (ESXi) Hosted Shared Deskto Per Server Averages Test hase rocessor % (average) VDI Infrastructure 5C1P2 (ESXi) 4.73 VDI Infrastructure Per Server Averages Figure 14: ESXi host erformance data When looking at each role individually, the random VDI deskto servers were well below the 85% average and the individual hysical servers showed room for growth. Although further testing would be required to verify, the data shows that either the number of hysical servers could have been reduced by as many as two or each server could have suorted additional users. For the static VDI deskto (with PvD) servers, CPU utilization was higher due to PvD (as exected), but still under the desired guidelines. As with the random VDI deskto servers, more testing would be required but the data shows that either one hysical server, at least, could be removed or the number of users er hysical server could be increased. It should be noted that Microsoft now recommends 2 GB of memory for Windows 7 64-Bit VMs. The test environment used 1.5GB. The hysical servers had 192GB of memory, so going to 2 GB as recommended by Microsoft would limit the VDI servers to 96 VDI sessions as a maximum. A better number would be to allow for oerating system memory and revent memory overcommit.

40 40 For the hosted shared deskto servers, CPU Utilization was within the desired guidelines. Eight hysical servers were allocated as VDI Infrastructure servers, to revent the infrastructure from becoming a bottleneck. Evaluating the CPU data here and the VM erformance data later in the aendix and with more testing to verify, the number of hysical servers could have been reduced by as much as half. XenDeskto infrastructure VM erformance As stated reviously, the XenDeskto infrastructure (StoreFront, PVS, Delivery Controllers, and vcenter Server) VMs were oversized to eliminate ossible bottlenecks in erformance while trying to achieve the 5000-user workload. The multile VMS were load-balanced within each grou. The following charts show the erformance of individual VMs from each grou; erformance across other VMs in the grous was almost identical to those listed below. Testing focused on two main areas, the boot storm, and the actual stress test run. During each test run CPU, memory, and networking erformance were monitored. Boot storms Boot storms ut a high stress level on the VMs involved. Through ower management and lanning most boot storms were avoided. In normal day-today oerations boot time would be sread over several hours to revent system overload. The StoreFront VM was not utilized during the boot storm. CPU, memory, and network utilization was close to zero for the StoreFront VM during the test. CPU utilization The following grahs show CPU utilization for XenDeskto infrastructure VMs during the boot storm. Figure 15: CPU utilization for PVS VM (Hosted Shared Desktos) during boot storm