Reference Architecture: Lenovo Client Virtualization with Citrix XenDesktop

(1)

Reference Architecture:

Lenovo Client Virtualization

with Citrix XenDesktop

Reference Architecture for

Citrix XenDesktop

Contains performance data and

sizing recommendations for

servers, storage, and networking

Describes variety of storage

models including SAN storage

and hyper-converged systems

Contains detailed bill of materials

for servers, storage, networking,

and racks

Mike Perks

Kenny Bain

Pawan Sharma

Last update: 24 June 2015

Version 1.2

(2)

ii

Reference Architecture: Lenovo Client Virtualization with Citrix XenDesktop version 1.2

1 Introduction ... 1

2 Architectural overview ... 2

3 Component model ... 3

3.1 Citrix XenDesktop provisioning ... 5

3.1.1 Provisioning Services ... 5

3.1.2 Machine Creation Services ... 6

3.2 Storage model ... 7

3.3 Atlantis Computing ... 7

3.3.1 Atlantis hyper-converged volume ... 8

3.3.2 Atlantis simple hybrid volume ... 9

3.3.3 Atlantis simple in-memory volume ... 9

4 Operational model ... 10

4.1 Operational model scenarios ... 10

4.1.1 Enterprise operational model ... 11

4.1.2 SMB operational model ... 11

4.1.3 Hyper-converged operational model ... 11

4.2 Hypervisor support ... 12

4.2.1 VMware ESXi ... 12

4.2.2 Citrix XenServer ... 12

4.2.3 Microsoft Hyper-V ... 13

4.3 Compute servers for virtual desktops ... 14

4.3.1 Intel Xeon E5-2600 v3 processor family servers ... 14

4.3.2 Intel Xeon E5-2600 v3 processor family servers with Atlantis USX... 19

4.4 Compute servers for hosted shared desktops ... 22

4.4.1 Intel Xeon E5-2600 v3 processor family servers ... 22

4.5 Compute servers for SMB virtual desktops ... 24

4.5.1 Intel Xeon E5-2600 v3 processor family servers with local storage ... 24

4.6 Compute servers for hyper-converged systems ... 26

4.6.1 Intel Xeon E5-2600 v3 processor family servers with Atlantis USX... 26

4.7 Graphics Acceleration ... 28

(3)

iii

Reference Architecture: Lenovo Client Virtualization with Citrix XenDesktop version 1.2

4.9 Systems management ... 32

4.10 Shared storage ... 33

4.10.1 IBM Storwize V7000 and IBM Storwize V3700 storage ... 34

4.10.2 IBM FlashSystem 840 with Atlantis USX storage acceleration ... 36

4.11 Networking ... 37

4.11.1 10 GbE networking ... 37

4.11.2 10 GbE FCoE networking... 38

4.11.3 Fibre Channel networking ... 38

4.11.4 1 GbE administration networking ... 38

4.12 Racks ... 39

4.13 Deployment models ... 39

4.13.1 Deployment example 1: Flex Solution with single Flex System chassis ... 39

4.13.2 Deployment example 2: Flex System with 4500 stateless users ... 40

4.13.3 Deployment example 3: System x server with Storwize V7000 and FCoE ... 43

4.13.4 Deployment example 4: Hyper-converged using System x servers ... 45

4.13.5 Deployment example 5: Graphics acceleration for 120 CAD users ... 45

5 Appendix: Bill of materials ... 47

5.1 BOM for enterprise compute servers ... 47

5.2 BOM for hosted desktops ... 52

5.3 BOM for SMB compute servers ... 56

5.4 BOM for hyper-converged compute servers ... 57

5.5 BOM for enterprise and SMB management servers ... 60

5.6 BOM for shared storage ... 64

5.7 BOM for networking ... 66

5.8 BOM for racks ... 67

5.9 BOM for Flex System chassis ... 67

5.10 BOM for OEM storage hardware ... 68

5.11 BOM for OEM networking hardware ... 68

Resources ... 69

(4)

1 Reference Architecture: Lenovo Client Virtualization with Citrix XenDesktop _{version 1.2}

1 Introduction

The intended audience for this document is technical IT architects, system administrators, and managers who are interested in server-based desktop virtualization and server-based computing (terminal services or

application virtualization) that uses Citrix XenDesktop. In this document, the term client virtualization is used as to refer to all of these variations. Compare this term to server virtualization, which refers to the virtualization of

server-based business logic and databases.

This document describes the reference architecture for Citrix XenDesktop 7.6 and also supports the previous versions of Citrix XenDesktop 5.6, 7.0, and 7.1. This document should be read with the Lenovo Client Virtualization (LCV) base reference architecture document that is available at this website:

lenovopress.com/tips1275

The business problem, business value, requirements, and hardware details are described in the LCV base reference architecture document and are not repeated here for brevity.

This document gives an architecture overview and logical component model of Citrix XenDesktop. The document also provides the operational model of Citrix XenDesktop by combining Lenovo® hardware platforms such as Flex System™, System x®, NeXtScale System™, and RackSwitch networking with OEM hardware and software such as IBM Storwize and FlashSystem storage, and Atlantis Computing software. The operational model presents performance benchmark measurements and discussion, sizing guidance, and some example deployment models. The last section contains detailed bill of material configurations for each piece of hardware.

(5)

2 Architectural overview

Figure 1 shows all of the main features of the Lenovo Client Virtualization reference architecture with Citrix XenDesktop. This reference architecture 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 description to the components that are inside the customer’s intranet.

XenDesktop Pools

Stateless Virtual Desktops

H yp e rvi so r Shared Storage FI R E W A LL FI R E W A LL 3rd_party VPN Internet Clients Web Interface Connection Broker (Delivery Controller) Internal Clients

Active Directory, DNS SQL Database Server Provisioning Server (PVS)

Dedicated Virtual Desktops

H yp e rvi so r License Server Machine Creation Services

Hosted Desktops and Apps

H

ype

rvi

sor

(6)

3 Component model

Figure 2 is a layered view of the LCV solution that is mapped to the Citrix XenDesktop virtualization infrastructure.

Support

Services

Lenovo Client Virtualization- Citrix XenDesktop

Management Services Web Interface PVS and MCS Delivery Controller Directory OS Licensing DHCP DNS

Client Devices

Client Receiver

Shared Storage

VM Repository Difference and

Identity Disks _ProfilesUser _{Data Files}User

NFS and CIFS M a n a g e m e n t P ro to c o ls XenDesktop SQL Server HTTP/HTTPS ICA XenDesktop Data Store

Administrator

GUIs for

Support

Services

License Server Desktop Studio Client Receiver Client Receiver S u p p o rt S e rv ic e P ro to c o ls Hypervisor Management vCenter Server vCenter SQL Server Hypervisor Hypervisor Dedicated Virtual Desktops Stateless Virtual Desktops Local SSD Storage VM Agent VM Agent Hypervisor Hosted Shared Desktops and Apps Shared Desktop Shared Desktop Shared Application VM Agent VM Agent Accelerator VM Accelerator VM Accelerator VM Lenovo Thin Client Manager

Figure 2: Component model with Citrix XenDesktop

Citrix XenDesktop features the following main components:

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 start, delivers a .ica file to the Citrix Receiver on the user‘s local device to start 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.

(7)

Delivery controller The Delivery controller is 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. Each delivery controller in the XenDesktop acts as an XML server that is responsible for brokering user authentication, resource enumeration, and desktop starting. 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 and MCS Provisioning Services (PVS) is used to provision stateless desktops at a large scale. Machine Creation Services (MCS) is used to provision dedicated or stateless desktops in a quick and integrated manner. For more information, see “Citrix XenDesktop provisioning” section on page 5.

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 site requires an SQL Server database that is called

the data store, which used to centralize farm configuration information and transaction logs. The data store maintains all static and dynamic information about the XenDesktop environment. Because the XenDeskop SQL server is a critical component, redundant servers must be available to provide fault tolerance.

vCenter Server By using a single console, vCenter Server provides centralized management of the virtual machines (VMs) for the VMware ESXi hypervisor. VMware vCenter can be used to perform live migration (called VMware vMotion), which allows a running VM to be moved from one physical server to another without downtime.

Redundancy for vCenter Server is achieved through VMware high availability (HA). The vCenter Server also contains a licensing server for VMware ESXi.

vCenter SQL Server vCenter Server for VMware ESXi hypervisor requires an SQL database. The vCenter SQL server might 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. Customer SQL databases (including respective redundancy) can be used.

(8)

Client devices Citrix XenDesktop supports a broad set of devices and 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, which customizes 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 by using the ICA/HDX protocol.

VDA Each VM needs a Citrix Virtual Desktop Agent (VDA) to capture desktop data and send it to the Citrix Receiver in the client device. The VDA also emulates keyboard and gestures sent from the receiver. ICA is the Citrix remote display protocol for VDI.

Hypervisor XenDesktop has an open architecture that supports the use of several different hypervisors, such as VMware ESXi (vSphere), Citrix XenServer, and Microsoft Hyper-V.

Accelerator VM The optional accelerator VM in this case is Atlantis Computing, For more information, see “Atlantis Computing” on page 7.

Shared storage Shared storage is used to store user profiles and user data files. Depending on the provisioning model that is used, different data is stored for VM images. For more information, see “Storage model” on section page 7.

For more information, see the Lenovo Client Virtualization base reference architecture document that is available at this website: lenovopress.com/tips1275.

3.1 Citrix XenDesktop provisioning

Citrix XenDesktop features the following primary provisioning models:

 Provisioning Services (PVS)

 Machine Creation Services (MCS)

3.1.1 Provisioning Services

Hosted VDI desktops can be deployed with or without Citrix PVS. The advantage of the use of 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 shows the sequence of operations that are run by XenDesktop to deliver a hosted VDI virtual desktop. When the virtual disk (vDisk) master image is available from the network, the VM on a target device no longer needs its local hard disk drive (HDD) to operate; it boots directly from the network and behaves as if it were running from a local drive on the target device, which is why PVS is recommended for stateless virtual

desktops. PVS often is not used for dedicated virtual desktops because the write cache is not stored on shared storage.

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.

(9)

6 Reference Architecture: Lenovo Client Virtualization with Citrix XenDesktop _{version 1.2} vDisk Write Cache Snapshot Master Image Provisioning Services Server Virtual Desktop

Request for vDisk Streaming vDisk

Figure 3: Using PVS for a stateless model

3.1.2 Machine Creation Services

Unlike PVS, MCS does not require more servers. Instead, it uses integrated functionality that is 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 (as shown in Figure 4). The difference disk is used to capture any changes that are 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

(10)

 Pooled-random: Desktops are assigned randomly. When they log off, the desktop is free for another user. When rebooted, any changes that were 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 that are 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 that are made persist across subsequent restarts.

MCS thin provisions each desktop from a master image by using built-in technology to provide each desktop with a unique identity. Only changes that are made to the desktop use more disk space. For this reason, MCS dedicated desktops are used for dedicated desktops.

3.2 Storage model

This section describes the different types of shared data stored for stateless and dedicated desktops. Stateless and dedicated virtual desktops should have the following common shared storage items:

 The master VM image and snapshots are stored by using Network File System (NFS) or block I/O shared storage.

 The paging file (or vSwap) is transient data that can be redirected to NFS storage. In general, it is recommended to disable swapping, which reduces storage use (shared or local). The desktop memory size should be chosen to match the user workload rather than depending on a smaller image and swapping, which reduces overall desktop performance.

 User profiles (from MSRP) are stored by using Common Internet File System (CIFS).

 User data files are stored by using CIFS.

Dedicated virtual desktops or stateless virtual desktops that need mobility require the following items to be on NFS or block I/O shared storage:

 Difference disks are used to store user’s changes to the base VM image. The difference disks are per user and can become quite large for dedicated desktops.

 Identity disks are used to store the computer name and password and are small.

 Stateless desktops can use local solid-state drive (SSD) storage for the PVS write cache, which is used to store all image writes on local SSD storage. These image writes are discarded when the VM is shut down.

3.3 Atlantis Computing

Atlantis Computing provides a software-defined storage solution, which can deliver better performance than physical PC and reduce storage requirements by up to 95% in virtual desktop environments of all types. The key is Atlantis HyperDup content-aware data services, which fundamentally changes the way VMs use storage. This change reduces the storage footprints by up to 95% while minimizing (and in some cases, entirely

eliminating) I/O to external storage. The net effect is a reduced CAPEX and a marked increase in performance to start, log in, start applications, search, and use virtual desktops or hosted desktops and applications. Atlantis software uses random access memory (RAM) for write-back caching of data blocks, real-time inline

(11)

de-duplication of data, coalescing of blocks, and compression, which significantly reduces the data that is cached and persistently stored in addition to greatly reducing network traffic.

Atlantis software works with any type of heterogeneous storage, including server RAM, direct-attached storage (DAS), SAN, or network-attached storage (NAS). It is provided as a VMware ESXi or Citrix XenServer

compatible VM that presents the virtualized storage to the hypervisor as a native data store, which makes deployment and integration straightforward. Atlantis Computing also provides other utilities for managing VMs and backing up and recovering data stores.

Atlantis provides a number of volume types suitable for virtual desktops and shared desktops. Different volume types support different application requirements and deployment models. Table 1 compares the Atlantis volume types.

Table 1: Atlantis Volume Types

Volume Type Min Number of Servers Performance Tier Capacity Tier HA Comments Hyper- converged Cluster of 3 Memory or

local flash DAS USX HA

Good balance between performance and capacity Simple Hybrid 1 Memory or flash Shared storage Hypervisor HA Functionally equivalent to Atlantis ILIO Persistent VDI Simple

All Flash 1 Local flash

Shared

flash Hypervisor HA

Good performance, but lower capacity Simple In-Memory 1 Memory or flash Memory or flash N/A (daily backup) Functionally equivalent to Atlantis ILIO Diskless VDI

3.3.1 Atlantis hyper-converged volume

Atlantis hyper-converged volumes are a hybrid between memory or local flash for accelerating performance and direct access storage (DAS) for capacity and provide a good balance between performance and capacity needed for virtual desktops.

As shown in Figure 5, hyper-converged volumes are clustered across three or more servers and have built-in resiliency in which the volume can be migrated to other servers in the cluster in case of server failure or entering maintenance mode. Hyper-converged volumes are supported for ESXi and XenServer.

(12)

3.3.2 Atlantis simple hybrid volume

Atlantis simple hybrid volumes are targeted at dedicated virtual desktop environments. This volume type provides the optimal solution for desktop virtualization customers that are using traditional or existing storage technologies that are optimized by Atlantis software with server RAM. In this scenario, Atlantis employs memory as a tier and uses a small amount of server RAM for all I/O processing while using the existing SAN, NAS, or all-flash arrays storage as the primary storage. Atlantis storage optimizations increase the number of desktops that the storage can support by up to 20 times while improving performance. Disk-backed

configurations can use various different storage types, including host-based flash memory cards, external all-flash arrays, and conventional spinning disk arrays.

A variation of the simple hybrid volume type is the simple all-flash volume that uses fast, low-latency shared flash storage whereby very little RAM is used and all I/O requests are sent to the flash storage after the inline de-duplication and compression are performed.

This reference architecture concentrates on the simple hybrid volume type for dedicated desktops, stateless desktops that use local SSDs, and host-shared desktops and applications. To cover the widest variety of shared storage, the simple all-flash volume type is not considered.

3.3.3 Atlantis simple in-memory volume

Atlantis simple in-memory volumes eliminate storage from stateless VDI deployments by using local server RAM and the in-memory storage optimization technology. Server RAM is used as the primary storage for stateless virtual desktops, which ensures that read and write I/O occurs at memory speeds and eliminates network traffic. An option allows for in-line compression and decompression to reduce the RAM usage.

(13)

4 Operational model

This section describes the options for mapping the logical components of a client virtualization solution onto hardware and software. The “Operational model scenarios” section gives an overview of the available mappings and has pointers into the other sections for the related hardware. Each subsection contains

performance data, has recommendations on how to size for that particular hardware, and a pointer to the BOM configurations that are described in section 0 on page 47. The last part of this section contains some

deployment models for example customer scenarios.

4.1 Operational model scenarios

Figure 6 shows the following operational models (solutions) in Lenovo Client Virtualization: enterprise, small-medium business (SMB), and hyper-converged.

Traditional

Converged

Hyper-converged

Compute/Management Servers • x3550, x3650, nx360 Hypervisor • ESXi, XenServer Graphics Acceleration • NVIDIA GRID K1 or K2 Shared Storage • IBM Storwize V7000 • IBM FlashSystem 840 Networking • 10GbE • 10GbE FCoE • 8 or 16 Gb FC

Flex System Chassis

Compute/Management Servers • Flex System x240 Hypervisor • ESXi Shared Storage • IBM Storwize V7000 • IBM FlashSystem 840 Networking • 10GbE • 10GbE FCoE • 8 or 16 Gb FC Compute/Management Servers • x3550, x3650, nx360 Hypervisor

• ESXi, XenServer, Hyper-V Graphics Acceleration • NVIDIA GRID K1 or K2 Shared Storage • IBM Storwize V3700 Networking • 10GbE Compute/Management Servers • x3650 Hypervisor • ESXi, XenServer Graphics Acceleration • NVIDIA GRID K1 or K2 Shared Storage • Not applicable Networking • 10GbE Not Recommended En ter p ri se (> 600 u ser s) SM B (< 600 u ser s)

Figure 6: Operational model scenarios

The vertical axis is split into two halves: greater than 600 users is termed Enterprise and less than 600 is termed SMB. The 600 user split is not exact and provides rough guidance between Enterprise and SMB. The last column in Figure 6 (labelled “hyper-converged”) spans both halves because a hyper-converged solution can be deployed in a linear fashion from a small number of users (100) up to a large number of users (>4000). The horizontal axis is split into three columns. The left-most column represents traditional rack-based systems with top-of-rack (TOR) switches and shared storage. The middle column represents converged systems where the compute, networking, and sometimes storage are converged into a chassis, such as the Flex System. The

(14)

right-most column represents hyper-converged systems and the software that is used in these systems. For the purposes of this reference architecture, the traditional and converged columns are merged for enterprise solutions; the only significant differences are the networking, form factor and capabilities of the compute servers.

Converged systems are not generally recommended for the SMB space because the converged hardware chassis can be more overhead when only a few compute nodes are needed. Other compute nodes in the converged chassis can be used for other workloads to make this hardware architecture more cost-effective.

4.1.1 Enterprise operational model

For the enterprise operational model, see the following sections for more information about each component, its performance, and sizing guidance:

 4.2 Hypervisor support

 4.3 Compute servers for virtual desktops

 4.4 Compute servers for hosted shared desktops

 4.7 Graphics Acceleration  4.8 Management servers  4.9 Systems management  4.10 Shared storage  4.11 Networking  4.12 Racks

To show the enterprise operational model for different sized customer environments, four different sizing models are provided for supporting 600, 1500, 4500, and 10000 users.

4.1.2 SMB operational model

For the SMB operational model, see the following sections for more information about each component, its performance, and sizing guidance:

 4.5 Compute servers for SMB virtual desktops

 4.7 Graphics Acceleration

 4.8 Management servers (may not be needed)

 4.9 Systems management

 4.10 Shared storage (see section on IBM Storwize V3700)

 4.11 Networking (see section on 10 GbE and iSCSI)

 4.12 Racks (use smaller rack or no rack at all)

To show the SMB operational model for different sized customer environments, four different sizing models are provided for supporting 75, 150, 300, and 600 users.

4.1.3 Hyper-converged operational model

For the hyper-converged operational model, see the following sections for more information about each component, its performance, and sizing guidance:

(15)

 4.6 Compute servers for hyper-converged

 4.7 Graphics Acceleration

 4.8 Management servers

 4.9 Systems management

 4.11.1 10 GbE networking

 4.12 Racks

To show the hyper-converged operational model for different sized customer environments, four different sizing models are provided for supporting 300, 600, 1500, and 3000 users. The management server VMs for a hyper-converged cluster can either be in a separate hyper-converged cluster or on traditional shared storage.

4.2 Hypervisor support

The Citrix XenDesktop reference architecture was tested with VMware ESXi 6.0, XenServer 6.5, and Microsoft Hyper-V 2012.

4.2.1 VMware ESXi

The VMware ESXi hypervisor is convenient because it can start from a USB flash drive and does not require any more local storage. Alternatively, ESXi can be booted from SAN shared storage. For the VMware ESXi hypervisor, the number of vCenter clusters depends on the number of compute servers.

For stateless desktops, local SSDs can be used to store the base image and pooled VMs for improved performance. Two replicas must be stored for each base image. Each stateless virtual desktop requires a linked clone, which tends to grow over time until it is refreshed at log out. Two enterprise high-speed 400 GB SSDs in a RAID 0 configuration should be sufficient for most user scenarios; however, 800 GB SSDs might be needed. Because of the stateless nature of the architecture, there is little added value in configuring reliable SSDs in more redundant configurations.

To use the latest version ESXi, obtain the image from the following website and upgrade by using vCenter:

ibm.com/systems/x/os/vmware/.

4.2.2 Citrix XenServer

For the Citrix XenServer hypervisor, it is necessary to install the OS onto drives in each compute server. For stateless desktops, local SSDs can be used to improve performance by storing the delta disk for MCS or the write-back cache for PVS. Each stateless virtual desktop requires a cache, which tends to grow over time until the virtual desktop is rebooted. The size of the write-back cache depends on the environment. Two enterprise high-speed 200 GB SSDs in a RAID 0 configuration should be sufficient for most user scenarios; however, 400 GB (or even 800 GB) SSDs might be needed. Because of the stateless nature of the architecture, there is little added value in configuring reliable SSDs in more redundant configurations.

The Flex System x240 compute nodes has two 2.5” drives. It is possible to both install XenServer and store stateless virtual desktops on the same two drives by using larger capacity SSDs. The System x3550 and System x3560 rack servers do not have this restriction and use separate HDDs for Hyper-V and SSDs for local stateless virtual desktops.

(16)

For Internet Explorer 11, the software rendering option must be used for flash videos to play correctly with Login VSI 4.1.3.

4.2.3 Microsoft Hyper-V

For the Microsoft Hyper-V hypervisor, it is necessary to install the OS onto drives in each compute server. For anything more than a small number of compute servers, it is worth the effort of setting up an automated installation from a USB flash drive by using Windows Assessment and Deployment Kit (ADK).

The Flex System x240 compute nodes has two 2.5” drives. It is possible to both install XenServer and store stateless virtual desktops on the same two drives by using larger capacity SSDs. The System x3550 and System x3560 rack servers do not have this restriction and use separate HDDs for Hyper-V and SSDs for local stateless virtual desktops.

Dynamic memory provides the capability to overcommit system memory and allow more VMs at the expense of paging. In normal circumstances, each compute server must have 20% extra memory to allow failover. When a server goes down and the VMs are moved to other servers, there should be no noticeable performance degradation to VMs that is already on that server. The recommendation is to use dynamic memory, but it should only affect the system when a compute server fails and its VMs are moved to other compute servers. For Internet Explorer 11, the software rendering option must be used for flash videos to play correctly with Login VSI 4.1.3.

The following configuration considerations are suggested for Hyper-V installations:

 Disable Large Send Offload (LSO) by using the Disable-NetadapterLSO command on the

Hyper-V compute server.

 Disable virtual machine queue (VMQ) on all interfaces by using the Disable-NetAdapterVmq

command on the Hyper-V compute server.

 Apply registry changes as per the Microsoft article that is found at this website:

support.microsoft.com/kb/2681638

The changes apply to Windows Server 2008 and Windows Server 2012.

 Disable VMQ and Internet Protocol Security (IPSec) task offloading flags in the Hyper-V settings for the base VM.

 By default, storage is shared as hidden Admin shares (for example, e$) on Hyper-V compute server and XenDesktop does not list Admin shares while adding the host. To make shared storage available to XenDesktop, the volume should be shared on the Hyper-V compute server.

(17)

4.3 Compute servers for virtual desktops

This section describes stateless and dedicated virtual desktop models. Stateless desktops that allow live migration of a VM from one physical server to another are considered the same as dedicated desktops because they both require shared storage. In some customer environments, stateless and dedicated desktop models might be required, which requires a hybrid implementation.

Compute servers are servers that run a hypervisor and host virtual desktops. There are several considerations

for the performance of the compute server, including the processor family and clock speed, the number of processors, the speed and size of main memory, and local storage options.

The use of the Aero theme in Microsoft Windows® 7 or other intensive workloads has an effect on the

maximum number of virtual desktops that can be supported on each compute server. Windows 8 also requires more processor resources than Windows 7, whereas little difference was observed between 32-bit and 64-bit Windows 7. Although a slower processor can be used and still not exhaust the processor power, it is a good policy to have excess capacity.

Another important consideration for compute servers is system memory. For stateless users, the typical range of memory that is required for each desktop is 2 GB - 4 GB. For dedicated users, the range of memory for each desktop is 2 GB - 6 GB. Designers and engineers that require graphics acceleration might need 8 GB - 16 GB of RAM per desktop. In general, power users that require larger memory sizes also require more virtual processors. This reference architecture standardizes on 2 GB per desktop as the minimum requirement of a Windows 7 desktop. The virtual desktop memory should be large enough so that swapping is not needed and vSwap can be disabled.

For more information, see “BOM for enterprise compute servers” on page 47.

4.3.1 Intel Xeon E5-2600 v3 processor family servers

This section shows the performance results and sizing guidance for Lenovo compute servers that are based on the Intel Xeon E5-2600 V3 processors (Haswell).

ESXi 6.0 performance results

Table 2 lists the Login VSI performance of E5-2600 v3 processors from Intel that use the Login VSI 4.1 office worker workload with ESXi 6.0.

Table 2: ESXi 6.0 performance with office worker workload

Processor with office worker workload Hypervisor MCS Stateless MCS Dedicated

Two E5-2650 v3 2.30 GHz, 10C 105W ESXi 6.0 239 users 234 users Two E5-2670 v3 2.30 GHz, 12C 120W ESXi 6.0 283 users 291 users Two E5-2680 v3 2.50 GHz, 12C 120W ESXi 6.0 284 users 301 users Two E5-2690 v3 2.60 GHz, 12C 135W ESXi 6.0 301 users 306 users

(18)

15 Reference Architecture: Lenovo Client Virtualization with Citrix XenDesktop _{version 1.2} Table 3 lists the results for the Login VSI 4.1 knowledge worker workload.

Table 3: ESXI 6.0 performance with knowledge worker workload

Processor with knowledge worker workload Hypervisor MCS Stateless MCS Dedicated

Two E5-2680 v3 2.50 GHz, 12C 120W ESXi 6.0 244 users 237 users Two E5-2690 v3 2.60 GHz, 12C 135W ESXi 6.0 252 users 246 users Table 4 lists the results for the Login VSI 4.1 power worker workload.

Table 4: ESXI 6.0 performance with power worker workload

Processor with power worker workload Hypervisor MCS Stateless MCS Dedicated

Two E5-2680 v3 2.50 GHz, 12C 120W ESXi 6.0 203 users 202 users These results indicate the comparative processor performance. The following conclusions can be drawn:

 The performance for stateless and dedicated virtual desktops is similar.

 The Xeon E5-2650v3 processor has performance that is similar to the previously recommended Xeon E5-2690v2 processor (IvyBridge), but uses less power and is less expensive.

 The Xeon E5-2690v3 processor does not have significantly better performance than the Xeon E5-2680v3 processor; therefore, the E5-2680v3 is preferred because of the lower cost.

Between the Xeon E5-2650v3 (2.30 GHz, 10C 105W) and the Xeon E5-2680v3 (2.50 GHz, 12C 120W) series processors are the Xeon E5-2660v3 (2.6 GHz 10C 105W) and the Xeon E5-2670v3 (2.3GHz 12C 120W) series processors. The cost per user increases with each processor but with a corresponding increase in user density. The Xeon E5-2680v3 processor has good user density, but the significant increase in cost might outweigh this advantage. Also, many configurations are bound by memory; therefore, a faster processor might not provide any added value. Some users require the fastest processor and for those users the Xeon

E5-2680v3 processor is the best choice. However, the Xeon E5-2650v3 processor is recommended for an average configuration. The Xeon E5-2680v3 processor is recommended for power workers.

Previous Reference Architectures used Login VSI 3.7 medium and heavy workloads. Table 5 gives a

comparison with the newer Login VSI 4.1 office worker and knowledge worker workloads. The table shows that Login VSI 3.7 is on average 20% to 30% higher than Login VSI 4.1.

Table 5: Comparison of Login VSI 3.7 and 4.1 Workloads

Processor Workload MCS Stateless MCS Dedicated

Two E5-2650 v3 2.30 GHz, 10C 105W 4.1 Office worker 239 users 234 users Two E5-2650 v3 2.30 GHz, 10C 105W 3.7 Medium 286 users 286 users Two E5-2690 v3 2.60 GHz, 12C 135W 4.1 Office worker 301 users 306 users Two E5-2690 v3 2.60 GHz, 12C 135W 3.7 Medium 394 users 379 users Two E5-2690 v3 2.60 GHz, 12C 135W 4.1 Knowledge worker 252 users 246 users Two E5-2690 v3 2.60 GHz, 12C 135W 3.7 Heavy 348 users 319 users

(19)

Table 6 compares the E5-2600 v3 processors with the previous generation E5-2600 v2 processors by using the Login VSI 3.7 workloads to show the relative performance improvement. On average, the E5-2600 v3 processors are 25% - 40% faster than the previous generation with the equivalent processor names.

Table 6: Comparison of E5-2600 v2 and E5-2600 v3 processors

Processor Workload MCS Stateless MCS Dedicated

Two E5-2650 v2 2.60 GHz, 8C 85W 3.7 Medium 204 users 204 users Two E5-2650 v3 2.30 GHz, 10C 105W 3.7 Medium 286 users 286 users Two E5-2690 v2 3.0 GHz, 10C 130W 3.7 Medium 268 users 257 users Two E5-2690 v3 2.60 GHz, 12C 135W 3.7 Medium 394 users 379 users Two E5-2690 v2 3.0 GHz, 10C 130W 3.7 Heavy 224 users 229 users Two E5-2690 v3 2.60 GHz, 12C 135W 3.7 Heavy 348 users 319 users

XenServer 6.0 performance results

Table 7 lists the Login VSI performance of E5 2600 v3 processors from Intel that uses the Office worker workload with XenServer 6.5.

Table 7: XenServer 6.5 performance with Office worker workload

Processor with office worker workload Hypervisor MCS stateless MCS dedicated

Two E5-2650 v3 2.30 GHz, 10C 105W XenServer 6.5 225 users 224 users Two E5-2680 v3 2.50 GHz, 12C 120W XenServer 6.5 274 users 278 users Table 8 shows the results for the same comparison that uses the Knowledge worker workload.

Table 8: XenServer 6.5 performance with Knowledge worker workload

Processor with knowledge worker workload Hypervisor MCS stateless MCS dedicated

Two E5-2680 v3 2.50 GHz, 12C 120W XenServer 6.5 210 users 208 users Table 9 lists the results for the Login VSI 4.1 power worker workload.

Table 9: XenServer 6.5 performance with power worker workload

Two E5-2680 v3 2.50 GHz, 12C 120W XenServer 6.5 181 users 179 users

(20)

Table 10 lists the Login VSI performance of E5 2600 v3 processors from Intel that uses the Office worker workload with Hyper-V Server 2012 R2.

Table 10: Hyper-V Server 2012 R2 performance with Office worker workload

Processor with office worker workload Hypervisor MCS stateless MCS dedicated

Two E5-2650 v3 2.30 GHz, 10C 105W Hyper-V 270 users 272 users Table 11 shows the results for the same comparison that uses the Knowledge worker workload.

Table 11: Hyper-V Server 2012 R2 performance with Knowledge worker workload

Processor with knowledge worker workload Hypervisor MCS stateless MCS dedicated

Two E5-2680 v3 2.50 GHz, 12C 120W Hyper-V 250 users 247 users Table 12 lists the results for the Login VSI 4.1 power worker workload.

Table 12: Hyper-V Server 2012 R2 performance with power worker workload

Two E5-2680 v3 2.50 GHz, 12C 120W Hyper-V 216 users 214 users

Compute server recommendation for Office and Knowledge workers

The default recommendation is the Xeon E5-2650v3 processor and 512 GB of system memory because this configuration provides the best coverage for a range of users up to 3GB of memory. For users who need VMs that are larger than 3 GB, Lenovo recommends the use of up to 768 GB and the Xeon E5-2680v3 processor. Lenovo testing shows that 150 users per server is a good baseline and has an average of 76% usage of the processors in the server. If a server goes down, users on that server must be transferred to the remaining servers. For this degraded failover case, Lenovo testing shows that 180 users per server have an average of 89% usage of the processor. It is important to keep this 25% headroom on servers to cope with possible failover scenarios. Lenovo recommends a general failover ratio of 5:1.

Table 13 lists the processor usage with ESXi for the recommended user counts for normal mode and failover mode.

Table 13: Processor usage

Processor Workload Users per Server Stateless Utilization Dedicated Utilization

Two E5-2650 v3 Office worker 150 – normal node 78% 75%

Two E5-2650 v3 Office worker 180 – failover mode 88% 87%

Two E5-2680 v3 Knowledge worker 150 – normal node 78% 77%

Two E5-2680 v3 Knowledge worker 180 – failover mode 86% 86%

Table 14 lists the recommended number of virtual desktops per server for different VM memory. The number of users is reduced in some cases to fit within the available memory and still maintain a reasonably balanced system of compute and memory.

(21)

Table 14: Recommended number of virtual desktops per server

Processor E5-2650v3 E5-2650v3 E5-2680v3

VM memory size 2 GB (default) 3 GB 4 GB

System memory 384 GB 512 GB 768 GB

Desktops per server (normal mode) 150 140 150

Desktops per server (failover mode) 180 168 180

Table 15 lists the approximate number of compute servers that are needed for different numbers of users and VM sizes.

Table 15: Compute servers needed for different numbers of users and VM sizes

Desktop memory size (2 GB or 4 GB) 600 users 1500 users 4500 users 10000 users

Compute servers @150 users (normal) 5 10 30 68

Compute servers @180 users (failover) 4 8 25 56

Failover ratio 4:1 4:1 5:1 5:1

Desktop memory size (3 GB) 600 users 1500 users 4500 users 10000 users

Failover ratio 4:1 4.5:1 4.5:1 5:1

Compute server recommendation for Power workers

For power workers, the default recommendation is the Xeon E5-2680v3 processor and 384 GB of system memory. For users who need VMs that are larger than 3 GB, Lenovo recommends up to 768 GB of system memory.

Lenovo testing shows that 125 users per server is a good baseline and has an average of 79% usage of the processors in the server. If a server goes down, users on that server must be transferred to the remaining servers. For this degraded failover case, Lenovo testing shows that 150 users per server have an average of 88% usage of the processor. It is important to keep this 25% headroom on servers to cope with possible failover scenarios. Lenovo recommends a general failover ratio of 5:1.

(22)

Two E5-2680 v3 Power worker 125 – normal node 78% 80%

Two E5-2680 v3 Power worker 150 – failover mode 88% 88%

Table 17 lists the recommended number of virtual desktops per server for different VM memory. The number of power users is reduced to fit within the available memory and still maintain a reasonably balanced system of compute and memory.

Table 17: Recommended number of virtual desktops per server

Table 18 lists the approximate number of compute servers that are needed for different numbers of power users and VM sizes.

Table 18: Compute servers needed for different numbers of power users and VM sizes

Desktop memory size 600 users 1500 users 4500 users 10000 users

4.3.2 Intel Xeon E5-2600 v3 processor family servers with Atlantis USX

Atlantis USX provides storage optimization by using a 100% software solution. There is a cost for processor and memory usage while offering decreased storage usage and increased input/output operations per second (IOPS). This section contains performance measurements for processor and memory utilization of USX simple hybrid volumes and gives an indication of the storage usage and performance.

For persistent desktops, USX simple hybrid volumes provide acceleration to shared storage. For environments that are not using Atlantis USX, it is recommended to use linked clones to conserve shared storage space. However, with Atlantis USX hybrid volumes, it is recommended to use full clones for persistent desktops because they de-duplicate more efficiently than the linked clones and can support more desktops per server. For stateless desktops, USX simple hybrid volumes provide storage acceleration for local SSDs. USX simple in-memory volumes are not considered for stateless desktops because they require a large amount of memory. Table 19 lists the Login VSI performance of USX simple hybrid volumes using two E5-2680 v3 processors and ESXi 6.0.

(23)

Table 19: ESXi 6.0 performance with USX hybrid volume

Login VSI 4.1 Workload Hypervisor MCS Stateless MCS Dedicated

Office worker ESXi 6.0 204 users 206 users

Knowledge worker ESXi 6.0 194 users 193 users

Power worker ESXi 6.0 155 users 156 users

A comparison of performance with and without the Atlantis VM shows that increase of 20 - 30% with the Atlantis VM. This result is to be expected and it is recommended that higher-end processors (like the E5-2680v3) are used to maximize density.

For office workers and knowledge workers, Lenovo testing shows that 125 users per server is a good baseline and has an average of 74% usage of the processors in the server. If a server goes down, users on that server must be transferred to the remaining servers. For this degraded failover case, Lenovo testing shows that 150 users per server have an average of 83% usage of the processor. For power workers, Lenovo testing shows that 100 users per server is a good baseline and has an average of 74% usage of the processors in the server. If a server goes down, users on that server must be transferred to the remaining servers. For this degraded failover case, Lenovo testing shows that 120 users per server have an average of 85% usage of the processor. It is important to keep this 25% headroom on servers to cope with possible failover scenarios. Lenovo

recommends a general failover ratio of 5:1.

Two E5-2680 v3 Knowledge worker 125 – normal node 72% 75%

Two E5-2680 v3 Knowledge worker 150 – failover mode 82% 83%

Two E5-2680 v3 Power worker 100 – normal node 74% 73%

Two E5-2680 v3 Power worker 120 – failover mode 85% 85%

It is still a best practice to separate the user folder and any other shared folders into separate storage. This configuration leaves all of the other possible changes that might occur in a full clone to be stored in the simple hybrid volume. This configuration is highly dependent on the environment. Testing by Atlantis Computing suggests that 3.5 GB of unique data per persistent desktop is sufficient.

Atlantis USX uses de-duplication and compression to reduce the storage that is required for VMs. Experience shows that a 85% - 95% reduction is possible depending on the VMs.

Assuming each VM is 30 GB, the uncompressed storage requirement for 150 full clones is 4500 GB. The simple hybrid volume must be only 10% of this volume, which is 450 GB. To allow some room for growth and the Atlantis VM, a 600 GB volume should be allocated.

Atlantis has some requirements on memory. The VM requires 5 GB, and 5% of the storage volume is used for in memory metadata. In the example of a 450 GB volume, this amount is 22.5 GB. The default size for the RAM

(24)

cache is 15%, but it is recommended to increase this size to 25% for the write heavy VDI workload. In the example of a 450 GB volume, this size is 112.5 GB.

Assuming 4 GB for the hypervisor, 144 GB (22.5 + 112.5 + 5 + 4) of system memory should be reserved. It is recommended that at least 384 GB of server memory is used for USX simple hybrid VDI deployments. Proof of concept (POC) testing can help determine the actual amount of RAM.

Table 21 lists the recommended number of virtual desktops per server for different VM memory sizes.

Table 21: Recommended number of virtual desktops per server with USX simple hybrid volumes

Total system memory 384 GB 512 GB 768 GB

Reserved system memory 144 GB 144 GB 144 GB

System memory for desktop VMs 240 GB 368 GB 624 GB

Table 22 lists the number of compute servers that are needed for different numbers of users and VM sizes. A server with 384 GB system memory is used for 2 GB VMs, 512 GB system memory is used for 3 GB VMs, and 768 GB system memory is used for 4 GB VMs.

Table 22: Compute servers needed for different numbers of users with USX simple hybrid volumes

600 users 1500 users 4500 users 10000 users

Compute servers for 100 users (normal) 6 15 45 100

Compute servers for 120 users (failover) 5 13 38 84

Failover ratio 5:1 6.5:1 5:1 5:1

As a result of the use of Atlantis simple hybrid volumes, the only read operations are to fill the cache for the first time. For all practical purposes, the remaining reads are few and at most 1 IOPS per VM. Writes to persistent storage are still needed for starting, logging in, remaining in steady state, and logging off, but the overall IOPS count is substantially reduced.

Assuming the use of a fast, low-latency shared storage device, a single VM boot can take 20 - 25 seconds to get past the display of the logon window and get all of the other services fully loaded. This process takes this time because boot operations are mainly read operations, although the actual boot time can vary depending on the VM. Citrix XenDesktop boots VMs in batches of 10 at a time, which reduces IOPS for most storage

systems but is actually an inhibitor for Atlantis simple hybrid volumes. Without the use of XenDesktop, a boot of 100 VMs in a single data store is completed in 3.5 minutes; that is, only 11 times longer than the boot of a single VM and far superior to existing storage solutions.

Login time for a single desktop varies, depending on the VM image but can be extremely quick. In some cases, the login will take less than 6 seconds. Scale-out testing across a cluster of servers shows that one new login

(25)

every 6 seconds can be supported over a long period. Therefore, at any one instant, there can be multiple logins underway and the main bottleneck is the processor.

4.4 Compute servers for hosted shared desktops

This section describes compute servers for hosted shared desktops that use Citrix XenDesktop 7.x. This functionality was in the separate XenApp product, but it is now integrated into the Citrix XenDesktop product. Hosted shared desktops are more suited to task workers that require little in desktop customization.

As the name implies, multiple desktops share a single VM; however, because of this sharing, the compute resources often are exhausted before memory. Lenovo testing showed that 128 GB of memory is sufficient for servers with two processors.

Other testing showed that the performance differences between four, six, or eight VMs is minimal; therefore, four VMs are recommended to reduce the license costs for Windows Server 2012 R2.

For more information, see “BOM for hosted desktops” section on page 52.

4.4.1 Intel Xeon E5-2600 v3 processor family servers

Table 23 lists the processor performance results for different size workloads that use four Windows Server 2012 R2 VMs with the Xeon E5-2600v3 series processors and ESXi 6.0 hypervisor.

Table 23: ESXi 6.0 results for shared hosted desktops

Processor Hypervisor Workload Hosted Desktops

Two E5-2650 v3 2.30 GHz, 10C 105W ESXi 6.0 Office Worker 222 users Two E5-2670 v3 2.30 GHz, 12C 120W ESXi 6.0 Office Worker 255 users Two E5-2680 v3 2.50 GHz, 12C 120W ESXi 6.0 Office Worker 264 users Two E5-2690 v3 2.60 GHz, 12C 135W ESXi 6.0 Office Worker 280 users Two E5-2680 v3 2.50 GHz, 12C 120W ESXi 6.0 Knowledge Worker 231 users Two E5-2690 v3 2.50 GHz, 12C 120W ESXi 6.0 Knowledge Worker 237 users

Table 24 lists the processor performance results for different size workloads that use four Windows Server 2012 R2 VMs with the Xeon E5-2600v3 series processors and XenServer 6.5 hypervisor.

Table 24: XenServer 6.5 results for shared hosted desktops

Two E5-2650 v3 2.30 GHz, 10C 105W XenServer 6.5 Office Worker 225 users Two E5-2670 v3 2.30 GHz, 12C 120W XenServer 6.5 Office Worker 243 users Two E5-2680 v3 2.50 GHz, 12C 120W XenServer 6.5 Office Worker 262 users Two E5-2690 v3 2.60 GHz, 12C 135W XenServer 6.5 Office Worker 271 users Two E5-2680 v3 2.50 GHz, 12C 120W XenServer 6.5 Knowledge Worker 223 users Two E5-2690 v3 2.50 GHz, 12C 120W XenServer 6.5 Knowledge Worker 226 users

(26)

Table 25 lists the processor performance results for different size workloads that use four Windows Server 2012 R2 VMs with the Xeon E5-2600v3 series processors and Hyper-V Server 2012 R2.

Table 25: Hyper-V Server 2012 R2 results for shared hosted desktops

Two E5-2650 v3 2.30 GHz, 10C 105W Hyper-V Office Worker 337 users Two E5-2680 v3 2.50 GHz, 12C 120W Hyper-V Office Worker 295 users Two E5-2680 v3 2.50 GHz, 12C 120W Hyper-V Knowledge Worker 264 users

Lenovo testing shows that 170 hosted desktops per server is a good baseline. If a server goes down, users on that server must be transferred to the remaining servers. For this degraded failover case, Lenovo recommends 204 hosted desktops per server. It is important to keep 25% headroom on servers to cope with possible failover scenarios. Lenovo recommends a general failover ratio of 5:1.

Table 26 lists the processor usage for the recommended number of users.

Processor Workload Users per Server Utilization

Two E5-2650 v3 Office worker 170 – normal node 78% Two E5-2650 v3 Office worker 204 – failover mode 88% Two E5-2680 v3 Knowledge worker 170 – normal node 65% Two E5-2680 v3 Knowledge worker 204 – failover mode 78%

Table 27 lists the number of compute servers that are needed for different numbers of users. Each compute server has 128 GB of system memory for the four VMs.

Table 27: Compute servers needed for different numbers of users and VM sizes

(27)

4.5 Compute servers for SMB virtual desktops

This section presents an alternative for compute servers to be used in an SMB environment that can be more cost-effective than the enterprise environment that is described in 4.3 Compute servers for virtual desktops and 4.4 Compute servers for hosted shared desktops. The following methods can be used to cut costs from a VDI solution:

 Use a more restrictive XenDesktop license

 Use hypervisor with a lower license cost

 Do not use dedicated management servers for management VMs

 Use local HDDs in compute servers and use shared storage only when necessary

The Citrix XenDesktop VDI edition has fewer features than the other XenDesktop versions and might be sufficient for the customer SMB environment. For more information and a comparison, see this website:

citrix.com/go/products/xendesktop/feature-matrix.html

Citrix XenServer has no other license cost and is an alternative to other hypervisors. The performance measurements in this section show XenServer and ESXi.

Providing that there is some kind of HA for the management server VMs, the number of compute servers that are needed can be reduced at the cost of less user density. There is a cross-over point on the number of users where it makes sense to have dedicated compute servers for the management VMs. That cross-over point varies by customer, but often it is in the range of 300 - 600 users. A good assumption is a reduction in user density of 20% for the management VMs; for example, 125 users reduces to 100 per compute server.

Shared storage is expensive. Some shared storage is needed to ensure user recovery if there is a failure and the IBM Storwize V3700 with an iSCSI connection is recommended. Dedicated virtual desktops always must be on a server in case of failure, but stateless virtual desktops can be provisioned to HDDs on the local server. Only the user data and profile information must be on shared storage.

4.5.1 Intel Xeon E5-2600 v3 processor family servers with local storage

The performance measurements and recommendations in this section are for the use of stateless virtual machines with local storage on the compute server. For more information about for persistent virtual desktops as persistent users must use shared storage for resilience, see “Compute servers for virtual desktops” on page 14.

XenServer 6.5 formats a local datastore by using the LVMoHBA file system. As a consequence XenServer 6.5 supports only thick provisioning and not thin provisioning. This fact means that VMs that are created with MCS are large and take up too much local disk space. Instead, only PVS was used to provision stateless virtual desktops.

Table 28 shows the processor performance results for the Xeon E5-2650v3 series of processors by using stateless virtual machines on local HDDs with XenServer 6.5. This configuration used 12 or 16 300 GB 15k RPM HDDs in a RAID 10 array. Measurements showed that 8 HDDs is not sufficient for the required IOPS and the capacity requirements.

(28)

Table 28: Performance results for PVS stateless virtual desktops with XenServer 6.5

Processor Workload 12 HDDs 16 HDDs

Two E5-2680 v3 2.50 GHz, 12C 120W Office worker 211 users 211 users Two E5-2680 v3 2.50 GHz, 12C 120W Knowledge worker 117 users 162 users For Office worker, 12 HDDs have sufficient IOPS but the storage capacity with 300 GB HDDs was 96%. If the number of VMs is reduced to 125, there should be sufficient capacity for a default 6GB write cache per VM with some room left over for VM growth. For VMs that are larger than 30 GB, it is recommended that 600 GB 15k RPM HDDs are used.

For Knowledge worker, 12 HDDs do not have sufficient IOPS. In this case, at least 16 HDDs should be used. Because an SMB environment is used with a range of user sizes from less than 75 to 600, the following configurations are recommended:

 For small user counts, each server can support 75 users at most by using two E5-2650v3 processors, 256 GB of memory, and 12 HDDs. The extra memory is needed for the VM for management servers.

 For average user counts, each server supports 125 users at most by using two E5-2650v3 processors, 256 GB of memory, and 16 HDDs.

These configurations also need two extra HDDs for installing XenServer 6.5.

Table 29 shows the number of compute servers that are needed for different number of medium users.

Table 29: SMB Compute servers needed for different numbers of users and VM sizes

Compute servers for 75 users (normal) 2 3 N/A N/A

Compute servers for 75 users (failover) 1 2 N/A N/A

Compute servers for 100 users (normal) N/A N/A 3 5

Compute servers for 125 users (failover) N/A N/A 2 4

Includes VMs for management servers Yes Yes No No

(29)

4.6 Compute servers for hyper-converged systems

This section presents the compute servers for Atlantis USX hyper-converged system. Additional processing and memory is often required to support storing data locally, as well as additional SSDs or HDDs. Typically HDDs are used for data capacity and SSDs and memory is used for provide performance. As the price per GB for flash memory continues to reduce, there is a trend to also use all SSDs to provide the overall best

performance for hyper-converged systems.

For more information, see “BOM for hyper-converged compute servers” on page 56.

4.6.1 Intel Xeon E5-2600 v3 processor family servers with Atlantis USX

Atlantis USX is tested by using the knowledge worker workload of Login VSI 4.1. Four Lenovo x3650 M5 servers with E5-2680v3 processors were networked together by using a 10 GbE TOR switch. Atlantis USX was installed and four 400 GB SSDs per server were used to create an all-flash hyper-converged volume across the four servers that were running ESXi 5.5 U2.

This configuration was tested with 500 dedicated virtual desktops on four servers and then three servers to see the difference if one server is unavailable. Table 30 lists the processor usage for the recommended number of users.

Table 30: Processor usage for Atlantis USX

Processor Workload Servers Users per Server Utilization

Two E5-2680 v3 Knowledge worker 4 125 – normal node 66% Two E5-2680 v3 Knowledge worker 3 167 – failover mode 89%

From these measurements, Lenovo recommends 125 user per server in normal mode and 150 users per server in failover mode. Lenovo recommends a general failover ratio of 5:1.

Table 31 lists the recommended number of virtual desktops per server for different VM memory sizes.

Table 31: Recommended number of virtual desktops per server for Atlantis USX

Processor E5-2680 v3 E5-2680 v3 E5-2680 v3

Memory for ESXi and Atlantis USX 63 GB 63 GB 63 GB

Memory for VMs 321 GB 449 GB 705 GB

Table 32 lists the approximate number of compute servers that are needed for different numbers of users and VM sizes.

(30)

Desktop memory size 300 users 600 users 1500 users 3000 users

An important part of a hyper-converged system is the resiliency to failures when a compute server is

unavailable. Login VSI was run and then the compute server was powered off. This process was done during the steady state phase. For the steady state phase, 114 - 120 VMs were migrated from the “failed” server to the other three servers with each server gaining 38 - 40 VMs.

Figure 7 shows the processor usage for the four servers during the steady state phase when one of the servers is powered off. The processor spike for the three remaining servers is noticeable.

Figure 7: Atlantis USX processor usage: server power off

There is an impact on performance and time lag if a hyper-converged server suffers a catastrophic failure, yet VSAN can recover quite quickly. However, this situation is best avoided as it is important to build in redundancy at multiple levels for all mission critical systems.

(31)

4.7 Graphics Acceleration

The XenServer 6.5 hypervisor supports the following options for graphics acceleration:

 Dedicated GPU with one GPU per user which is called pass-through mode.

 GPU hardware virtualization (vGPU) that partitions each GPU for 1 to 8 users.

The performance of graphics acceleration was tested on the NVIDIA GRID K1 and GRID K2 adapters by using the Lenovo System x3650 M5 server and the Lenovo NeXtScale nx360 M5 server. Each of these servers supports up to two GRID adapters. No significant performance differences were found between these two servers when they were used for graphics acceleration and the results apply to both.

Because pass-through mode offers a low user density (eight for GRID K1 and four for GRID K2), it is recommended that this mode is only used for power users, designers, engineers, or scientists that require powerful graphics acceleration.

Lenovo recommends that a high-powered CPU, such as the E5-2680v3, is used for pass-through mode and vGPU because accelerated graphics tends to put an extra load on the processor. For the pass-through mode, with only four or eight users per server, 128 GB of server memory should be sufficient even for the high end GRID K2 users who might need 16 GB or even 24 GB per VM. See also NVidia’s release notes on vGPU for Citrix XenServer 6.0:

The Heaven benchmark is used to measure the per user frame rate for different GPUs, resolutions, and image quality. This benchmark is graphics-heavy and is fairly realistic for designers and engineers. Power users or knowledge workers usually have less intense graphics workloads and can achieve higher frame rates. All tests were done by using the default H.264 compatibility display mode for the clients. This configuration offers the best compromise between data size (compression) and performance.

Table 33 lists the results of the Heaven benchmark as frames per second (FPS) that are available to each user with the GRID K1 adapter by using pass-through mode with DirectX 11.

Table 33: Performance of GRID K1 pass-through mode by using DirectX 11

Quality Tessellation Anti-Aliasing Resolution K1

High Normal 0 1024x768 14.3

High Normal 0 1280x1024 11.4

Table 34 lists the results of the Heaven benchmark as FPS that are available to each user with the GRID K2 adapter by using pass-through mode with DirectX 11.

Reference Architecture: Lenovo Client Virtualization with Citrix XenDesktop