IBMSmartCloudDesktopInfrastructure
withCitrixXenDesktop
Reference architecture
07 February 2013
© Copyright IBM Corporatio...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
Table of contents
Introduction ..........
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
Introduction
This document describes t...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
Support
ServicesSmartCloud Desktop Inf...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
 Desktop delivery
controller
The desk...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
 VDA Each VM needs a Citrix Virtual D...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
As soon as the virtual disk (vDisk) ma...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
There are three types of Image Assignm...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
per server with 256 GB of memory is a ...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
be accommodated per server, thus the n...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
Table 2: Characteristics of management...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
License server (1) 1
PVS servers for s...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
Experimentation with VDI infrastructur...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
Stateless storage 600 users 1500 users...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
Operational model component summary
Ta...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
Deployment diagram
Figure 6 shows the ...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
Resources
 IBM SmartCloud Desktop Inf...
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop
Reference architecture
16
Trademarks and special notices
© Co...
Upcoming SlideShare
Loading in …5
×

IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop

782 views

Published on

Learn about IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop. This document describes the reference architecture for using Citrix XenDesktop 5.6 on VMware ESXi 5 hypervisor. This document gives an architecture overview and component model of the Citrix XenDesktop and then describes the Deployment model of Citrix XenDesktop using different number of users. For more information on IBM Systems, visit http://ibm.co/RKEeMO.

Visit http://on.fb.me/LT4gdu to 'Like' the official Facebook page of IBM India Smarter Computing.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
782
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
44
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop

  1. 1. IBMSmartCloudDesktopInfrastructure withCitrixXenDesktop Reference architecture 07 February 2013 © Copyright IBM Corporation, 2013
  2. 2. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture Table of contents Introduction .................................................................................................................................1 Architectural overview................................................................................................................1 Component model.......................................................................................................................1 Citrix XenDesktop provisioning................................................................................................................4 Storage model..........................................................................................................................................6 Operational model.......................................................................................................................6 Compute servers......................................................................................................................................6 Systems management ...........................................................................................................................10 Networking.............................................................................................................................................10 Shared storage ......................................................................................................................................10 Operational model component summary...............................................................................................13 Deployment diagram..............................................................................................................................14 Resources..................................................................................................................................15 Trademarks and special notices..............................................................................................16
  3. 3. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture Introduction This document describes the reference architecture for using Citrix XenDesktop 5.6 on VMware ESXi 5 hypervisor. It should be read in conjunction with the IBM SmartCloud Desktop Infrastructure reference architecture available at ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure. The business problem, business value, and requirements are described in the IBM SmartCloud Desktop Infrastructure reference architecture and not repeated here for brevity. This document gives an architecture overview and component model of the Citrix XenDesktop and then describes the Deployment model of Citrix XenDesktop using different number of users. Architectural overview Figure 1 shows all of the main features of the IBM SmartCloud Desktop (SDI) reference architecture with Citrix XenDesktop. Virtual application deployment using Citrix XenApp is not included in this reference architecture. XenDesktop Pools Stateless Desktops ESXi Hypervisor Shared Storage FIREWALL FIREWALL Citrix Netscaler or 3rd party VPN Internet Clients Web Servers Connection Broker (DDC) Internal Clients Active Directory, DNS SQL Database Server Provisioning Server (PVS) Dedicated Desktops ESXi Hypervisor License Server Machine Creation Services Figure 1: SDI reference architecture with Citrix XenDesktop 5.6 This reference architecture also does not address the issues of remote access and authorization, data traffic reduction, traffic monitoring, and general issues of multi-site deployment and network management. This document limits the discussion to the components inside the customer’s intranet. Component model Figure 2 is a layered view of the IBM SmartCloud Desktop (SDI) infrastructure mapped to the Citrix XenDesktop virtualization infrastructure and using the VMware ESXi hypervisor. 1
  4. 4. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture Support ServicesSmartCloud Desktop Infrastructure - Citrix XenDesktop 5.6 Management Services Web Server vCenter Server PVS or MCS Desktop Delivery Controller Directory OS Licensing DHCP DNS ESXi VM VDA VM VDA VM VDA ESXi Dedicated VMs Stateless VMs Client Devices Client Receiver Shared Storage VM Repository Difference and Identity Disks User Data Files User Profiles NFS and CIFS ManagementProtocols SupportServiceProtocols XenDesktop SQL Server HTTP/HTTPS ICA XenDesktop Data Store Administrator GUIs for Support Services License Server VM VDA VM VDA VM VDA VM VDA VM VDA Local SSDs Desktop Studio Client Receiver Client Receiver vCenter SQL Server Figure 2: Component model for Citrix XenDesktop The main components for Citrix XenDesktop using VMware ESXi hypervisor are described as follows. The IBM SmartCloud Desktop Infrastructure reference architecture document available at ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure can be used as a guide.  Desktop Studio Desktop Studio is the main administrator GUI for Citrix XenDesktop. It is used to configure and manage all of the main entities including servers, desktop pools and provisioning, policy, and licensing.  Web Interface The Web Interface provides the user interface to the XenDesktop environment. The Web Interface brokers user authentication, enumerates the available desktops and, upon launch, delivers an .ica file to the Citrix Receiver on the user‘s local device to initiate a connection. The Independent Computing Architecture (ICA) file contains configuration information for the Citrix receiver to communicate with the virtual desktop. Because the Web Interface is a critical component, redundant servers must be available to provide fault tolerance. 2
  5. 5. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture  Desktop delivery controller The desktop delivery controllers (DDC) are responsible for maintaining the proper level of idle desktops to allow for instantaneous connections, monitoring the state of online and connected desktops, and shutting down desktops as needed. A XenDesktop farm is a larger grouping of virtual machine servers. The primary DDC is configured as the XenDesktop farm master server. The master focuses on farm management while an additional DDC acts as a dedicated XML server. The XML server is responsible for brokering user authentication, resource enumeration, and desktop launching. Because a failure in the XML service results in users being unable to start their desktops, it is recommended that you configure multiple controllers per farm.  PVS or MCS Provisioning Services (PVS) is used to provision stateless VMs and Machine Creation Services (MCS) is used to provision dedicated VMs. See “Citrix XenDesktop provisioning” on page 4 for more details.  vCenter Server vCenter Server is the managing for VMware ESXi hypervisor. Using a single console, it provides centralized management of the virtual machines. Redundancy for vCenter Server is achieved through VMware HA. The vCenter server also contains a licensing server for VMware ESXi,  vCenter SQL Server vCenter requires a SQL database. The vCenter SQL server could be Microsoft® Data Engine (MSDE), Oracle, or SQL Server. Because the vCenter SQL server is a critical component, redundant servers must be available to provide fault tolerance. Existing customer SQL databases (including respective redundancy) can be used.  License Server The Citrix License Server is responsible for managing the licenses for all XenDesktop components. XenDesktop has a 30-day grace period that allows the system to function normally for 30 days if the license server becomes unavailable. This grace period offsets the complexity of otherwise building redundancy into the license server.  XenDesktop SQL Server Each Citrix XenDesktop farm requires a SQL Server database called the data store that is used to centralize farm configuration information and transaction logs. The data store maintains all static information about the XenDesktop environment. Because the XenDeskop SQL server is a critical component, redundant servers must be available to provide fault tolerance.  Client devices XenDesktop supports a broad set of devices, including PCs, Macs, tablets, smartphones, and thin clients, along with all major device operating platforms, including Apple iOS, Google Android, and Google ChromeOS. XenDesktop enables a rich, native experience on each device, including support for gestures and multi-touch features, customizing the experience based on the type of device. Each client device has a Citrix Receiver, which acts as the agent to communicate with the virtual desktop using the ICA/HDX protocol. 3
  6. 6. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture  VDA Each VM needs a Citrix Virtual Desktop Agent (VDA) to capture VM data and send it to the Receiver in the client device. The VDA also emulates keyboard and gestures sent from the Receiver. Note that the VDA is different for HDX 3D Pro because it has to capture data from a GPU rendering a 3D scene. ICA is the Citrix display protocol for both 2D and 3D VDI.  ESXi XenDesktop has an open architecture that supports the use of a number of different hypervisors, such as: XenServer, Microsoft Hyper- V, and VMware ESXi (vSphere) hypervisors. VMware ESXi is the specific hypervisor used in this reference architecture.  Shared storage Shared storage is used to store user profiles and user data files. Depending on the provisioning model used, different data is stored for VM images. Shared storage also holds the redirected vSwap files. See Storage model on page 6 for more details. Citrix XenDesktop provisioning Citrix XenDesktop has two primary provisioning models:  Provisioning Services (PVS)  Machine Creation Services (MCS) In summary, the ideal combination of provisioning services for XenDesktop is to use PVS for the stateless model and MCS for the dedicated model. Provisioning Services (PVS) Hosted VDI desktops can be deployed with or without Citrix PVS. The advantage of using PVS is that you can stream a single desktop image to create multiple virtual desktops on one or more servers in a data center. Figure 3 outlines the sequence of operations run by XenDesktop to deliver a hosted VDI virtual desktop. vDisk Write Cache SnapshotMaster Image Provisioning Services Server Virtual Desktop Request for vDisk Streaming vDisk Figure 3: Using PVS for a stateless model 4
  7. 7. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture As soon as the virtual disk (vDisk) master image is available from the network, the virtual machine (VM) on a target device no longer needs its local hard drive to operate; it boots directly from the network and behaves as if it were running from a local drive on the target device. This is why PVS is recommended for stateless virtual desktops. PVS is not generally used for dedicated virtual desktops because the write cache is not stored on shared storage. The size of the write cache for each VM depends on several factors, including the types of applications, user workloads, and reboot frequency. A general estimate is 300 MB to 500 MB. Two local solid state drives (SSDs) are configured in as RAID-0 to store the write cache. Due to the stateless nature of the architecture, there is little added value in configuring reliable SSD drives in more redundant RAID configurations. Redundancy is not achieved on a per host level, but achieved inherently, through the ability of a user to connect to virtual desktops hosted on any of the remaining compute servers, in the event of an individual server failure. PVS is also used with Microsoft Roaming Profiles (MSRPs) so that the user’s profile information can be separated out and reused. Profile data is available from shared storage. It is a best practice to use snapshots for changes to the master VM images and also keep copies as a backup. Machine Creation Services (MCS) Unlike PVS, MCS does not require additional servers. Instead, it uses integrated functionality built into the hypervisor (VMware ESXi, Citrix XenServer, or Microsoft Hyper-V) and communicates through the respective APIs. Each desktop has one difference disk and one identity disk (see Figure 4).The difference disk is used to capture any changes made to the master image. The identity disk is used to store information such as device name and password. Figure 4: MCS image and difference/identity disk storage model 5
  8. 8. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture There are three types of Image Assignment Models for MCS:  Pooled-random. Desktops are assigned randomly. When they log off, the desktop is free for another user. When rebooted, any changes made are destroyed.  Pooled-static. Desktops are permanently assigned to a single user. When a user logs off, only that user can use the desktop, regardless if the desktop is rebooted. During reboots, any changes made are destroyed.  Dedicated. Desktops are permanently assigned to a single user. When a user logs off, only that user can use the desktop, regardless if the desktop is rebooted. During reboots, any changes made will persist across subsequent restarts. MCS thin provisions each desktop from a master image, using built-in technology to provide each desktop with a unique identity. Only changes made to the desktop consume additional disk space. For this reason, MCS dedicated desktops are used for dedicated VMs. Storage model This section describes the different types of shared data stored for stateless and dedicated VMs. Dedicated VMs do not use local storage and require the following shared storage items:  Difference disks are used to store user’s changes to the base VM image using Network File System (NFS). The difference disks are per user and could become quite large.  Identity disks are used store the machine name and password using NFS. Identity disks are very small. Both stateless and dedicated VMs have these common shared storage items:  The master VM image and snapshots are stored using NFS  The paging file (or vSwap) is transient data that can be redirected to NFS shared storage.  User profiles (from MSRP) are stored using CIFS.  User data files are stored using CIFS. Note that Citrix XenDesktop does not use block I/O, unless thin provisioning is turned off. Not using thin provisioning is very wasteful in regards to disk space, and is therefore not recommended. Operational model Two separate main operational models are considered here, to cover both stateless and dedicated image models. In some customer environments, both stateless and dedicated image models may be required, thus a mixed operational model is required. In order to illustrate the operational model for different sized customer environments, four different models are provided for supporting 600, 1500, 4500, and 10000 users. Note that the operational model for 10000 users is essentially 7 times larger than the model for 1500 users and therefore users between 1500 and 10000 can be extrapolated, by using different multiples of the 1500 user model. Compute servers Compute servers are servers that run the VMware ESXi hypervisor and host Citrix XenDesktop user VMs. This reference architecture assumes a VM memory size of 1.5 GB. IBM testing has shown that 125 users 6
  9. 9. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture per server with 256 GB of memory is a good baseline and has on average 75% utilization of the processors in the server. If a server goes down, then users on that server need to be transferred to the remaining servers. For this degraded failover case, IBM testing showed that 150 user per server will have on average 90% utilization. It is important to keep this 25% headroom on servers to cope with possible failover scenarios. Other than the limit imposed by the processor power, the number of compute servers required for a given number of users is in direct proportion to the memory size required for the VM and the number of users. Figure 5 shows the number of users that can be supported given the VM size (on the horizontal axis) and the amount of memory in the server given a limit of 150 users per compute server. In this reference architecture and in most cases, IBM recommends that the compute server has 256 GB of main memory. If the average VM size is less than 1.25 GB of memory, then 192 GB of memory is sufficient, as additional memory would be unused. Servers requiring only 128 GB are unlikely because the cut-off point for eliminating wasted memory is <0.75 GB per VM. 60 80 100 120 140 160 0.5 1 1.5 2 2.5 3 3.5 4 NumberofVMs VM Size (GB) 256 192 128Memory Available on Server (GB): Figure 5: Number of users supported by main memory and VM size The compute servers can be either IBM x240 Flex Nodes or IBM System x3550 rack servers. The detailed specification is as follows:  Processor: 2 x E5-2680 8C 2.7 GHz 20 MB Cache 1600 MHz 130 W  Memory: 256 GB as 16 x 16 GB DIMMs (2Rx4, 1.5 V PC3-12800 CL11 ECC DDR3 LP RDIMM)  Network card: Integrated 10 GbE adapter for x240 Flex System nodes or Emulex Dual Port 10GbE SFP+ Embedded Virtual Fabric Adapter for x3350 rack servers  USB key for VMware ESXi hypervisor For servers with stateless VM images, the following components also need to be added:  IBM ServeRAID M5115 SAS/SATA Controller  2 x IBM 200GB SATA eMLC SSD (1.8 in. for x240 Flex node or 2.5 in. for x3550 rack server) Power users require larger VMs but also need more processor power and therefore it is not usually worth considering servers with more memory than 256 GB. If the VMs are larger than 1.5 GB, fewer users can 7
  10. 10. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture be accommodated per server, thus the number of servers needs to be increased appropriately, and memory should be sufficient again on a per-server basis. If the VMs are smaller than 1.5 GB, then compute servers with less memory can be used because too many users would overwhelm the CPU power of the servers. Table 1 shows the number of compute servers needed for each user size (assuming a VM size of 1.5 GB): VM size ≤ 1.5 GB 600 users 1500 users 4500 users 10000 users Compute servers @125 users 5 12 36 80 Compute servers @150 users (failover) 4 10 30 70 Failover ratio 4:1 5:1 5:1 7:1 vCenter clusters (8 servers/cluster) 1 2 6 14 Table 1: Compute servers needed Management servers Management servers have the same hardware specification as compute servers so they could be used interchangeably in a worst-case scenario. The management servers also use ESXi as the hypervisor but have management VMs instead of user VMs. Table 2 summarizes the VM requirements and performance characteristics of each management service. Management service VM Virtual processors Memory Storage Windows OS HA needed Performance characteristic vCenter server 4 4 GB 15 GB 2008 R2 No Up to 2000 VMs vCenter SQL server 4 4 GB 15 GB 2008 R2 Yes Double the virtual processors and memory for more than 2500 users DDC 4 4 GB 15 GB 2008 R2 Yes 5000 user connections Web server 4 4 GB 15 GB 2008 R2 Yes 30,000 connections per hour Licensing server 2 4 GB 15 GB 2008 R2 No 170 licenses per second XenDesktop SQL server 2 4 GB 15 GB 2008 R2 Yes Double the virtual processor and memory for more than 2500 users PVS servers 4 32 GB 40 GB 2008 R2 Yes Up to 1000 VMs, memory should be a minimum of 2 GB plus 1.5 GB per image served 8
  11. 11. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture Table 2: Characteristics of management services Table 3 lists the number of management VMs for each size of users following the high-availability and performance characteristics listed. Note that the number of vCenter servers is half of the number of vCenter clusters shown in Table 1. This is because each vCenter server can handle two clusters of up to 1000 VMs, and each cluster exists on two vCenter servers. Management service VM 600 users 1500 users 4500 users 10000 users vCenter servers 1 1 3 7 vCenter SQL servers 2 (1+1) 2 (1+1) 2 (1+1) 2 (1+1) Desktop Delivery Controllers  Includes Citrix Licensing server  Includes Web Server 2 (1+1) Y Y 2 (1+1) N N 2 (1+1) N N 2(3+1) N N Web servers N/A 2 (1+1) 2 (1+1) 2 (1+1) Licensing servers N/A 1 1 1 XenDesktop SQL servers 2 (1+1) 2 (1+1) 2 (1+1) 2 (1+1) PVS servers for stateless case only 2 (1+1) 4 (2+2) 8 (6+2) 14 (10+4) Table 3: Management VMs needed Note that it is assumed that common services such as Microsoft Active Directory, DHCP, DNS, and Microsoft licensing servers already exist in the customer environment. Based on the number and type of VMs, Table 4 lists the recommended number of management servers. In all cases, there is redundancy in both the management servers and the management VMs. Management servers 600 users 1500 users 4500 users 10000 users Stateless VM model 2 2 4 7 Dedicated VM model 2 2 2 4 Table 4: Management servers needed As documented earlier, each management VM requires a certain amount of virtual processors, memory and disk. Note that there is plenty of capacity in the management servers for all of these VMs. Table 5 has an example mapping of the management VMs to the 4 physical management servers for 4500 users. Management service for 4500 stateless users Management server 1 Management server 2 Management server 3 Management server 4 vCenter servers (3) 1 1 1 vCenter database (2) 1 1 XenDesktop database (2) 1 1 DDC (2) 1 1 Web server (2) 1 1 9
  12. 12. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture License server (1) 1 PVS servers for stateless case only (8) 2 2 2 2 Table 5: Management server VM mapping (4500 users) Systems management Assuming the use of IBM Flex System compute servers, it is recommended to have one or more IBM Flex System Manager nodes, especially in case of the larger configurations, to provide additional systems management capability. Networking As described in the IBM SmartCloud Infrastructure reference architecture available at ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure there are 3 virtual LANs (VLANs) that each share part of the bandwidth in a 10 GbE network. All of the compute servers, management servers, and shared storage are connected to the 10 GbE network using a 10 GbE switch. The IBM RackSwitch G8124E and G8264R switches are recommended as they support VLANs using IBM Virtual Fabric. Note that although the IBM PureFlex™ chassis supports internal 10 GbE switches, these are not used because a separate switch is needed for the external shared storage. The IBM Flex System Fabric EN4091 Pass- thru Module is used to pass the 10 GbE connections to the external switch. For fewer than 4500 users the IBM G8124E 24-port switch can be used. Above 4500 users, multiple IBM G8264R 48-port switches should be used instead as these switches provide more ports. For redundancy an additional or spare switch should be available. Table 6 summarizes the number of 10 GbE switches for each user size: 10 GbE network switch 600 users 1500 users 4500 users 10000 users G8124E – 24-port switch 2 (1+1) 2 (1+1) 3 (2+1) 0 G8264R – 48-port switch 0 0 0 3 (2+1) Table 6: 10 GbE network switches needed Separate 1 GbE switches are used for the IT administration network. Again, it is recommended that a spare switch be available in case of failure. Table 7 summarizes the number of 1 GbE switches for each user size: 1 GbE network switch 600 users 1500 users 4500 users 10000 users G8052 – 48 port switch 2 (1+1) 2 (1+1) 2 (1+1) 3 (2+1) Table 7: 1 GbE network switches needed For smaller configurations and Flex-based systems, consider consolidating the 1GbE network into the 10GbE switch using SFP RJ45 transceivers Shared storage VDI workloads such as virtual desktop provisioning, VM loading across the network, and access to user profiles and data files place huge demands on network shared storage. This reference architecture first describes the performance requirements of both stateless and dedicated virtual desktops and then shows the storage configuration that meets those requirements. 10
  13. 13. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture Experimentation with VDI infrastructures shows that the input/output operation (IOP) performance takes precedence over storage capacity. This means that more of the slower speed drives are needed to get the required performance than higher speed drives. Even with the fastest drives available today (15k RPM), there is still can be an excess capacity in the storage system. The large rate of IOPs and therefore large number of drives needed for dedicated virtual desktops can be ameliorated to some extent by caching read data in flash memory (flash cache feature of some N series controllers). However there is a limit to how much flash memory is useful because of the relatively low percentage of read operations. In terms of the IBM N series range of storage systems, the largest 15k RPM SAS drive is 600 GB. These disks require a larger expansion cabinet with 24 disks in a 4U enclosure. The same number of slower- speed 10K SAS drives in a small form factor (SFF) 2.5 in. can be put in a 2U enclosure. In this case superior performance wins over the cost of rack density and the storage configurations all use 600 GB 15k RPM SAS drives. The storage configurations are based on the peak performance requirement, which usually occurs during a so-called “logon storm”. This is when all workers at a company arrive at the same time in the morning and try to start their virtual desktops, all at the same time. The storage configurations also have conservative assumptions about the VM size, changes to the VM, and user data sizes to ensure that the configurations can cope with the most demanding user scenarios. As mentioned above the storage configurations tend to have more storage that is strictly required in order to meet the performance objectives for IOPs. In our experience this “extra” storage is more than sufficient for the other types of data needed for VDI such as SQL databases and transaction logs. Note that the storage configurations do not include facilities for data replication, data compression, or data deduplication. These are all value-added features that may or may not be required. These features may also have an effect on the storage configuration. The storage configurations, where possible, do include flash memory as a means to cache frequently used data. Stateless virtual desktops Stateless virtual desktops using Citrix XenDesktop are provisioned from shared storage using PVS. The PVS write cache is maintained on a local SSD. Table 8 summarizes the peak IOPs and disk space requirements for stateless virtual desktops on a per-user basis. Citrix stateless virtual desktops Protocol Size IOPs Write % User data files CIFS/NFS 5 GB 1 75% User profile (through MSRP) CIFS 100 MB 0.8 75% Table 8: Stateless shared storage performance requirements Table 9 summarizes the storage configuration needed for each user size. In this case, the flash cache does not help at all, so a lower end controller with failover is used. It is also assumed that 100% of the users at peak load times require concurrent access to user data files and profiles. 11
  14. 14. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture Stateless storage 600 users 1500 users 4500 users 10000 users Controller and model number N3220 A22 N3220 A22 N3220 A22 N3220 A22 10 GbE mezzanine cards 2 2 2 2 Flash cache N/A N/A N/A N/A 600 GB 15K rpm drives 12 20 70 164 Spare drives 2 2 2 4 EXN3000 expansion unit 1 1 3 7 Table 9: Stateless shared storage configuration Dedicated virtual desktops Table 10 summarizes the peak IOPs and disk space requirements for dedicated virtual desktops on a per- user basis. The last two rows are the same as used for stateless desktops. Citrix dedicated virtual desktops Protocol Size IOPs Write % Master image NFS 30 GB Difference disks User “AppData” folder NFS 10 GB 18 85% User files CIFS/NFS 5 GB 1 75% User profile (through MSRP) CIFS 100 MB 0.8 75% Table 10: Dedicated shared storage performance requirements Table 11 summarizes the storage configuration needed for each user size. A mid-range controller with 512 MB of flash cache is used for fewer than 2000 users as it supports up to only 600 drives. A high-end controller is used for more than 2000 users because it has a larger flash cache capability, more 10 GbE ports, and can support up to 1440 drives. It is also assumed that 100% of the users at peak load times require concurrent access to user data files and profiles. Dedicated storage 600 users 1500 users 4500 users 10000 users Controller and model number N6240 E21 N6240 E21 N7950T E22 N7950T E22 10 GbE cards 2 2 2 2 Flash cache 512 MB 512 MB 1 GB 1 GB 600 GB 15K rpm drives 42 100 296 630 Spare drives 6 8 24 42 EXN3000 expansion units 2 6 16 28 Table 11: Dedicated shared storage configuration 12
  15. 15. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture Operational model component summary Table 12 summarizes the items needed for stateless virtual desktops for each user size: Stateless virtual desktop 600 users 1500 users 4500 users 10000 users Compute servers 5 12 36 80 Management servers 2 2 4 7 10 GbE network switches 2 x G8124E 2 x G8124E 3 x G8124E 3 x G8264R 1 GbE network switches 2 x G8052 2 x G8052 2 x G8052 3 x G8052 PureFlex Flex System Manager nodes (optional, only for Flex) 1 1 2 2 Flex chassis with EN4091 pass-thru module (only for Flex) 1 1 3 7 Storage servers N3220 A22 N3220 A22 N3220 A22 N3220 A22 Storage extensions EXN3000 x 1 EXN3000 x 1 EXN3000 x 3 EXN3000 x 7 Total height (Flex System servers) 20U 20U 49U 109U Total height (x3550 rack servers) 17U 24U 59U 127U Number of racks 1 1 2 3 or 4 Table 12: Operational model summary for stateless virtual desktops Table 13 summarizes the items needed for dedicated virtual desktops for each user size: Dedicated virtual desktop 600 users 1500 users 4500 users 10000 users Compute servers 5 12 36 80 Management servers 2 2 4 8 10 GbE network switches 2 x G8124E 2 x G8124E 3 x G8124E 3 x G8264R 1 GbE network switches 2 x G8052 2 x G8052 2 x G8052 3 x G8052 PureFlex Flex System Manager nodes (optional, only for Flex) 1 1 2 2 Flex chassis with EN4091 pass-thru module (only for Flex) 1 1 3 7 Storage servers N6240 E21 N6240 E21 N7950T E22 N7950T E22 Storage extensions EXN3000 x 2 EXN3000 x 6 EXN3000 x 16 EXN3000 x 28 Total height (Flex System servers) 28U 44U 111U 203U Total height (x3550 rack servers) 25U 48U 121U 221U Number of racks 1 1 3 6 Table 13: Operational model summary for dedicated virtual desktops 13
  16. 16. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture Deployment diagram Figure 6 shows the deployment diagram for an IBM Flex System-based system that supports 4500 stateless users. The first rack contains the compute and management servers and the second rack contains the storage servers and disks. EN4091Pass-thruEN4091Pass-thruEN4091Pass-thru M1 C11 C12 C9 C10 C7 C8 C5 C6 C3 C4 C1 C2 1 GbE Switch 1 GbE Switch 10 GbE Switch 10 GbE Switch FSM M2 C23 C24 C21 C22 C19 C20 C17 C18 C15 C16 C13 C14 FSM M3 C35 C36 C33 C34 C31 C32 C29 C30 C27 C28 C25 C26 M4 Rack 2 10 GbE Switch DS4243 Extension (24 x 600GB 15k RPM) DS4243 Extension (24 x 600GB 15k RPM) M1 VMs vCenter Server vCenter SQL Server DDC PVS Servers (2) M4 VMs Desktop SQL Server DDC Web Server PVS Servers (2) M2 VMs vCenter Server vCenter SQL Server License Server PVS Servers (2) M3 VMs vCenter Server Desktop SQL Server Web Server PVS Servers (2) Cxx Each compute server has 125 user VMs Rack 1 FlexChassis1FlexChassis3FlexChassis2 IBM N3220 A22 DS4243 Extension (24 x 600GB 15k RPM) Figure 6: Deployment diagram for 4500 stateless users 14
  17. 17. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture Resources  IBM SmartCloud Desktop Infrastructure reference architecture ibm.com/partnerworld/page/stg_ast_eis_sdi_infrastructure  Citrix XenDesktop citrix.com/products/xendesktop  VMware vSphere vmware.com/products/datacenter-virtualization/vsphere 15
  18. 18. IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop Reference architecture 16 Trademarks and special notices © Copyright IBM Corporation 2013. References in this document to IBM products or services do not imply that IBM intends to make them available in every country. IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. Information is provided "AS IS" without warranty of any kind. All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Information concerning non-IBM products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-IBM products. Questions on the capability of non-IBM products should be addressed to the supplier of those products. All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction. Some information addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here. Photographs shown are of engineering prototypes. Changes may be incorporated in production models. Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk.

×