This chapter presents the following topics:
Overview ... 34 Reference workload... 34 VSPEX Private Cloud requirements ... 35 VSPEX XtremIO array configurations ... 35 VNX array configurations ... 37 Choosing the appropriate reference architecture ... 38
Overview
This chapter describes how to design a VSPEX End-User Computing for Citrix
XenDesktop solution and how to size it to fit the customer’s needs. It introduces the concepts of a reference workload, building blocks, and validated end-user-computing maximums, and describes how to use these to design your solution. Table 4 outlines the high-level steps you need to complete when sizing the solution.
Table 4. VSPEX end-user computing: Design process Step Action
1 Use the Customer Sizing Worksheet in Appendix A to collect the customer requirements for the end-user computing environment.
2 Use the EMC VSPEX Sizing Tool to determine the recommended VSPEX reference architecture for your end-user-computing solution, based on the customer requirements collected in Step 1.
Note: If the Sizing Tool is not available, you can manually size the end-user-computing solution using the guidelines in this chapter.
Reference workload
VSPEX defines a reference workload to represent a unit of measure for quantifying the resources in the solution reference architectures. By comparing the customer’s actual usage to this reference workload, you can determine which reference architecture to choose as the basis for the customer’s VSPEX deployment.
For VSPEX end-user-computing solutions, the reference workload is defined as a single virtual desktop—the reference virtual desktop—with the workload
characteristics listed in Table 5.
To determine the equivalent number of reference virtual desktops for a particular resource requirement, use the VSPEX Customer Sizing Worksheet to convert the total actual resources required for all desktops into the reference virtual desktop format.
Table 5. Reference virtual desktop characteristics
Characteristic Value
Virtual desktop OS Microsoft Windows 8.1 Enterprise Edition (32-bit)
Virtual processors per virtual desktop 1
RAM per virtual desktop 2 GB
Average storage available for each MCS linked clone virtual desktop
6 GB (VMDK and VSWP)
Average storage available for each PVS streamed virtual desktop
20 GB (PVS write cache and personal vDisk VMDK and VSWP)
Average IOPS per virtual desktop at steady
state 10
35 EMC VSPEX End-User Computing Citrix XenDesktop 7.5 and Microsoft Hyper-V with EMC XtremIO Design Guide This desktop definition is based on user data that resides on shared storage. The I/O profile is defined by using a test framework that runs all desktops concurrently with a steady load generated by the constant use of office-based applications such as browsers and office productivity software.
VSPEX Private Cloud requirements
This VSPEX End User Computing Proven Infrastructure requires multiple application servers. Unless otherwise specified, all servers use Microsoft Windows Server 2012 R2 as the base OS. Table 6 lists the minimum requirements of each infrastructure server required.
Table 6. Infrastructure server minimum requirements
Server CPU RAM (GB) IOPS Storage
VSPEX for Citrix XenDesktop with ShareFile StorageZones solution on page 62 provides the requirements for the optional Citrix ShareFile component.
This solution requires a 1.5 TB volume to host the infrastructure virtual machines, which can include the Microsoft SCVMM server, Citrix XenDesktop Controllers, Citrix PVS servers, optional Citrix ShareFile servers, Microsoft Active Directory Server, and Microsoft SQL Server.
VSPEX/XtremIO array configurations
We validated the VSPEX/XtremIO end-user-computing configurations on the Starter X-Brick and X-X-Brick platforms, which vary according to the number of SSDs they include and their total available capacity. For each array, EMC recommends a maximum VSPEX end-user-computing configuration as outlined in this section.
The following XtremIO validated disk layouts provide support for a specified number of virtual desktops at a defined performance level. This VSPEX solution supports two XtremIO configurations, which are selected based on the number of desktops being deployed:
Private cloud storage layout
Validated XtremIO configurations
XtremIO Starter X-Brick—Includes 13 SSD drives, and is validated to support up to 1,750 MCS linked-clone or PVS-streamed virtual desktops
XtremIO X-Brick—Includes 25 SSD drives, and is validated to support up to 3,500 MCS linked-clone or PVS-streamed virtual desktops
The XtremIO storage configuration required for this solution is in addition to the storage required by the VSPEX private cloud that supports the solution’s
infrastructure services. For more information about the VSPEX private cloud storage pool, refer to the VSPEX Proven Infrastructure Guide in Essential reading.
Table 7 shows the number and size of the XtremIO volumes that will be presented to the Hyper-V servers to host the virtual desktops. Two datastore configurations are listed for each desktop type: one that includes the space required to use the Citrix Personal vDisk (PvD) feature, and one that does not for solutions that will not use that component of Citrix XenDesktop. Please note that when deploying Citrix desktops using PVS, the following values are configured by default:
PVS write cache disk = 6 GB
Citrix Personal vDisk (PvD) = 10 GB
If either of these values is changed from the default, the datastore sizes must also be changed as a result.
Table 7. XtremIO storage layout XtremIO
desktop Volume size (GB)
Starter X-Brick 1,750
7
PVS streamed 2,500 PVS with PvD
PVS streamed 2,500 PVS with PvD
37 EMC VSPEX End-User Computing Citrix XenDesktop 7.5 and Microsoft Hyper-V with EMC XtremIO Design Guide The EMC VSPEX End User Computing solution supports a flexible implementation model where it is easy to expand your environment as the needs of the business change.
To support future expansion, the XtremIO Starter X-Brick can be non-disruptively upgraded to an X-Brick by installing the XtremIO expansion kit, which adds an additional twelve 400 GB SSD drives. The resulting X-Brick supports up to 3,500 desktops.
VNX array configurations
The following optional VNX validated disk layouts provide support for user data storage. You can modify a validated storage layout by adding drives for greater capacity and performance and adding features such as FAST Cache and FAST VP for improved user data performance. However, decreasing the number of recommended drives or stepping down an array type can result in lower IOPS per desktop and a less satisfactory user experience due to higher response times.
Our building block for optional user data storage is verified on an EMC VNX5400™
and provides a flexible solution for VNX sizing.
The user data storage building block shown in Figure 6 can support up to 1,750 desktops, using a VNX5400 with 32 NL-SAS drives in a FAST Cache-enabled storage pool. FAST Cache should be configured with two flash drives.
Figure 6. Optional user data storage building block for 1,750 virtual desktops To support 3,500 users, you need to add a second identical user data storage building block and a second Data Mover. This configuration then includes a total of 64 NL-SAS drives, 4 flash drives for FAST Cache, and 2 Data Movers.
Expanding existing VSPEX end-user computing environments
User data storage VNX building block
If multiple drive types have been implemented, FAST VP can be enabled to automatically tier data to balance differences in performance and capacity.
Note: FAST VP can provide performance improvements when implemented for user data and roaming profiles. Do not use FAST VP for virtual desktop datastores.
The virtual desktops use four shared file systems—two for the Citrix XenDesktop Profile Management repositories and two to redirect user storage that resides in home directories. In general, redirecting users’ data out of the base image to VNX for File enables centralized administration and data protection and makes the desktops more stateless. Each file system is exported to the environment through a CIFS share.
Each Persona Management repository share and home directory share serves an equal number of users.
Choosing the appropriate reference architecture
To choose the appropriate reference architecture for a customer environment, you must determine the resource requirements of the environment and then translate these requirements to an equivalent number of reference virtual desktops that have the characteristics defined in Table 8. This section describes how to use the
Customer Sizing Worksheet to simplify the sizing calculations as well as additional factors you should take into consideration when deciding which architecture to deploy.
The Customer Sizing Worksheet helps you to assess the customer environment and calculate the sizing requirements of the environment.
Table 8 shows a completed worksheet for a sample customer environment. Appendix A provides a blank Customer Sizing Worksheet that you can print out and use to help size the solution for a customer.
Table 8. Example Customer Sizing Worksheet
User type vCPUs Memory IOPS Equivalent reference virtual desktops
39 EMC VSPEX End-User Computing Citrix XenDesktop 7.5 and Microsoft Hyper-V with EMC XtremIO Design Guide User type vCPUs Memory IOPS Equivalent reference
virtual desktops
To complete the Customer Sizing Worksheet:
1. Identify the user types planned for migration into the VSPEX end-user-computing environment and the number of users of each type.
2. For each user type, determine the compute resource requirements in terms of vCPUs, memory (GB), storage performance (IOPS), and storage capacity.
3. For each resource type and user type, determine the equivalent reference virtual desktops requirements—that is, the number of reference virtual desktops required to meet the specified resource requirements.
4. Determine the total number of reference desktops needed from the resource pool for the customer environment.
Determining the resource requirements CPU
The reference virtual desktop outlined in Table 5 assumes that most desktop applications are optimized for a single CPU. If one type of user requires a desktop with multiple virtual CPUs, modify the proposed virtual desktop count to account for the additional resources. For example, if you virtualize 100 desktops, but 20 users require two CPUs instead of one, consider that your pool needs to provide 120 virtual desktops of capability.
Memory
Memory plays a key role in ensuring application functionality and performance. Each group of desktops will have different targets for the available memory that is
considered acceptable. Like the CPU calculation, if a group of users requires additional memory resources, simply adjust the number of planned desktops to accommodate the additional resource requirements.
For example, if there are 200 desktops to be virtualized, but each one needs 4 GB of memory instead of the 2 GB that the reference virtual desktop provides, plan for 400 reference virtual desktops.
IOPS
The storage performance requirements for desktops are usually the least understood aspect of performance. The reference virtual desktop uses a workload generated by an industry-recognized tool to execute a wide variety of office productivity
applications that should be representative of the majority of virtual desktop implementations.
Storage capacity
The storage capacity requirement for a desktop can vary widely depending on the types of applications in use and specific customer policies. The virtual desktops in
this solution rely on additional shared storage for user profile data and user documents. This requirement is an optional component that can be met by the addition of specific storage hardware defined in the solution. It can also be met by using existing file shares in the environment.
Determining the equivalent reference virtual desktops
With all of the resources defined, you determine the number of equivalent reference virtual desktops by using the relationships indicated in Table 9. Round all values up to the closest whole number.
Table 9. Reference virtual desktop resources Resource Value for reference
virtual desktop
Relationship between requirements and equivalent reference virtual desktops
CPU 1 Equivalent reference virtual desktops =
resource requirements
Memory 2 Equivalent reference virtual desktops =
(resource requirements)/2
IOPS 10 Equivalent reference virtual desktops =
(resource requirements)/10
For example, the heavy user type in Table 8 requires 2 virtual CPUs, 12 IOPS, and 8 GB of memory for each desktop. This translates to two reference virtual desktops of CPU, four reference virtual desktops of memory, and two reference virtual desktops of IOPS.
The number of reference virtual desktops required for each user type then equals the maximum required for an individual resource. For example, the number of equivalent reference virtual desktops for the heavy user type in Table 8 is four, as this number will meet the all resource requirements—IOPS, vCPU, and memory.
To calculate the total number of reference desktops for a user type, you multiply the number of equivalent reference virtual desktops for that user type by the number of users.
Determining the total reference virtual desktops
After the worksheet is completed for each user type that the customer wants to migrate into the virtual infrastructure, you compute the total number of reference virtual desktops required in the resource pool by calculating the sum of the total reference virtual desktops for all user types. In the example in Table 8, the total is 2,400 virtual desktops.
This VSPEX end-user computing reference architecture supports two separate points of scale, a Starter X-Brick capable of supporting up to 1,750 reference desktops, and an X-Brick capable of hosting up to 3,500 reference desktops. The total reference virtual desktops value from the completed Customer Sizing Worksheet can be used to verify that this reference architecture would be adequate for the customer
requirements. In the example in Table 8, the customer requires 2,400 virtual Selecting a
reference architecture
41 EMC VSPEX End-User Computing Citrix XenDesktop 7.5 and Microsoft Hyper-V with EMC XtremIO Design Guide desktops of capability from the pool. Therefore, this reference architecture provides sufficient resources for current needs as well as some room for growth.
However, there may be other factors to consider when verifying that this reference architecture will perform as intended. These factors can include concurrency and desktop workload.
Concurrency
The reference workload used to validate this solution assumes that all desktop users are active at all times. In other words, we tested this 3,500-desktop reference
architecture with 3,500 desktops, all generating workload in parallel, all booted at the same time, and so on. If the customer expects to have 3,500 users, but only 50 percent of them are logged on at any given time due to time zone differences or alternate shifts, the reference architecture may be able to support additional desktops in this case.
Heavier desktop workloads
The reference workload is considered a typical office worker load. However, some customers’ users might have a more active profile.
If a company has 3,500 users and, due to custom corporate applications, each user generates 50 predominantly write IOPS as compared to the 10 IOPS used in the reference workload, this customer will need 175,000 IOPS (3,500 users x 50 IOPS per desktop). This configuration would be underpowered in this case because the
proposed IO load is greater than the array maximum of 100,000 write IOPS. This company would need to deploy an additional X-Brick, reduce their current IO load, or reduce the total number of desktops to ensure that the storage array performs as required.
In most cases, the Customer Sizing Worksheet suggests a reference architecture adequate for the customer‘s needs. However, in some cases you may want to further customize the hardware resources available to the system. A complete description of the system architecture is beyond the scope of this document but you can customize your solution further at this point.
Storage resources
The XtremIO array is deployed in one of two specialized configurations, one being a Starter X-Brick, the other an X-Brick. While more X-Bricks can be added to increase the capacity or performance capabilities of the XtremIO cluster, this solution is based on a either a Starter X-Brick or a single X-Brick. The XtremIO array requires no tuning, and the number of SSDs available in the array is fixed. The VSPEX Sizing Tool or Customer Sizing Worksheet should be used to verify that the XtremIO array can provided the necessary levels of capacity and performance.
Server resources
For the server resources in the solution, it is possible to customize the hardware resources more effectively. To do this, first total the resource requirements for the server components as shown in Table 10. We added Total CPU resources and Total memory resources columns to the worksheet.
Fine tuning hardware resources
Table 10. Server resource component totals
The example in Table 10 requires 2,000 virtual vCPUs and 4,800 GB of memory. The reference architectures assume five desktops per physical processor core and no memory over-provisioning. This converts to 500 processor cores and 4,800 GB of memory for this example. Use these calculations to more accurately determine the total server resources required.
Note: Keep high availability requirements in mind when customizing the resource pool hardware.
EMC considers the requirements stated in this solution to be the minimum set of resources needed to handle the workloads defined for a reference virtual desktop. In any customer implementation, the load of a system can vary over time as users interact with the system. If the number of customer virtual desktops differs
significantly from the reference definition and varies in the same resource group, you might need to add more of that resource to the system.
Summary
43 EMC VSPEX End-User Computing Citrix XenDesktop 7.5 and Microsoft Hyper-V with EMC XtremIO Design Guide