Tips 1278

8/9/2019 Tips 1278

1/70

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: 04 May 2015

Version 1.1

8/9/2019 Tips 1278

2/70

ii

Reference Architecture: Lenovo Client Virtualization with Citrix XenDesktop

version 1.1

Table of Contents

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 (ILIO Persistent VDI) ............................................ ................... 9

3.3.3 Atlantis Simple In-Memory Volume (ILIO Diskless VDI) ........................................ ................... 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 ................................................................................................................. 12

4.3 Compute servers for virtual desktops ..................................................................... 13 4.3.1 Intel Xeon E5-2600 v3 processor family servers .......................... ......................... ................. 13

4.3.2 Intel Xeon E5-2600 v2 processor family servers with Atlantis ILIO ......................... ................ 17

4.4 Compute servers for hosted shared desktops ........................................................ 20 4.4.1 Intel Xeon E5-2600 v3 processor family servers .......................... ......................... ................. 21

4.4.2 Intel Xeon E5-2600 v2 processor family servers with Atlantis ILIO ......................... ................ 22

4.5 Compute servers for SMB virtual desktops ............................................................ 23 4.5.1 Intel Xeon E5-2600 v2 processor family servers with local storage ........................................ 24

4.6 Compute servers for hyper-converged systems ..................................................... 25 4.6.1 Intel Xeon E5-2600 v3 processor family servers with Atlantis USX.............................. ........... 25

4.7 Graphics Acceleration ............................................................................................ 27

4.8 Management servers ............................................................................................. 29

8/9/2019 Tips 1278

3/70

iii

Reference Architecture: Lenovo Client Virtualization with Citrix XenDesktop

version 1.1

4.9 Shared storage ...................................................................................................... 31 4.9.1 IBM Storwize V7000 and IBM Storwize V3700 storage ......................................... ................. 32

4.9.2 IBM FlashSystem 840 with Atlantis ILIO storage acceleration ....................... ......................... 34

4.10 Networking ............................................................................................................. 35 4.10.1 10 GbE networking ............................................................................................................... 35

4.10.2 10 GbE FCoE networking...................................................................................................... 36

4.10.3 Fibre Channel networking ..................................................................................................... 36

4.10.4 1 GbE administration networking ....................... ......................... .......................... ................. 36

4.11 Racks ..................................................................................................................... 37

4.12 Deployment models ............................................................................................... 37 4.12.1 Deployment example 1: Flex Solution with single Flex System chassis .......................... ........ 37

4.12.2 Deployment example 2: Flex System with 4500 stateless users .................................... ........ 38

4.12.3 Deployment example 3: System x server with Storwize V7000 and FCoE ........................... ... 41

5 Appendix: Bill of materials ..................................................................... 43

5.1 BOM for enterprise compute servers ..................................................................... 43

5.2 BOM for hosted desktops ....................................................................................... 48

5.3 BOM for SMB compute servers ............................................................................. 52

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

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

5.6 BOM for shared storage ......................................................................................... 60

5.7 BOM for networking ............................................................................................... 62

5.8 BOM for racks ........................................................................................................ 63

5.9 BOM for Flex System chassis ................................................................................ 63

5.10 BOM for OEM storage hardware ............................................................................ 64

5.11 BOM for OEM networking hardware ...................................................................... 64

Resources ....................................................................................................... 65

Document history .......................................................................................... 66

8/9/2019 Tips 1278

4/70

1Reference Architecture: Lenovo Client Virtualization with Citrix XenDesktop

version 1.1

1 Introduction

The intended audience for this document is technical IT architects, system administrators, and managers who

are interested in server-based desktop v irtualization 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.

http://lenovopress.com/tips1275http://lenovopress.com/tips1275http://lenovopress.com/tips1275

8/9/2019 Tips 1278

5/70


version 1.1

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 y p er v i s or

SharedStorage

F I R

E WAL L

F I R

E WAL L

3rd party

VPNInternetClients

WebInterface

ConnectionBroker

(DeliveryController)

Internal

Clients

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

Dedicated Virtual Desktops

H y p er v i s or

LicenseServer

Machine CreationServices

Hosted Desktops and Apps

H y p e

r v i s or

Figure 1: LCV reference architectu re with Citr ix XenDeskto p

8/9/2019 Tips 1278

6/70


version 1.1

3 Component model

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

infrastructure.

SupportServicesLenovo Client Virtualization- Citrix XenDesktop

Management Services

Web Interface

PVS and MCS

Delivery Controller

Directory

OS Licensing

DHCP

DNS

Client Devices

ClientReceiver

Shared Storage

VMRepository

Difference andIdentity Disks

User Data Files

User Profiles

NFS and CIFS

M a n a g e m e n t P r o t o c o l s

XenDesktop SQL Server

HTTP/HTTPS ICA

XenDesktopData Store

Administrator

GUIs forSupportServices

License Server

DesktopStudio Client

Receiver Client

Receiver

S u p p o r t S e r v

i c e P r o t o c o l s

Hypervisor Management

vCenter Server

vCenter SQL Server

Hypervisor Hypervisor

DedicatedVirtual

Desktops

StatelessVirtual

Desktops

Local SSDStorage

VM

Agent

VM Agent

Hypervisor

HostedShared

Desktopsand Apps

SharedDesktop

Shared

Desktop

Shared Application

VM

Agent

VM Agent

Accelerator VM

Accelerator VM

Accelerator VM

Lenovo ThinClient Manager

Figure 2: Comp onent mod el with Citr ix 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 XenDesktopenvironment. 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.

8/9/2019 Tips 1278

7/70


version 1.1

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 becomesunavailable. 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 managementof 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, redundantservers must be available to provide fault tolerance. Customer SQL databases

(including respective redundancy) can be used.

8/9/2019 Tips 1278

8/70


version 1.1

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 moreinformation, 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.

It is a best practice to use snapshots for changes to the master VM images and also keep copies as a backup.

http://lenovopress.com/tips1275http://lenovopress.com/tips1275http://lenovopress.com/tips1275http://lenovopress.com/tips1275

8/9/2019 Tips 1278

9/70


version 1.1

vDisk

WriteCache

SnapshotMasterImage

Provisioning Services Server

Virtual Desktop

Request for vDisk

Streaming vDisk

Figure 3: Using PVS for a stateless mod el

3.1.2 Machine Creation Services

Unlike PVS, MCS does not require more servers. Instead, it uses integrated functionality that is built into thehypervisor (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 dif ference/ ident i ty disk storag e model

The following types of Image Assignment Models for MCS are available:

8/9/2019 Tips 1278

10/70


version 1.1

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 thanphysical 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

de-duplication of data, coalescing of blocks, and compression, which significantly reduces the data that is

8/9/2019 Tips 1278

11/70


version 1.1

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: Atlant is Volume Types

Volume

Type

Min Number

of Servers

Performance

Tier

Capacity

TierHA Comments

Hyper-

convergedCluster of 3

Memory or

local flashDAS USX HA

Good balance between

performance and capacity

Simple

Hybrid1

Memory

or flash

Shared

storageHypervisor HA

Functionally equivalent to

Atlantis ILIO Persistent VDI

Simple

All Flash1 Local flash

Shared

flashHypervisor HA

Good performance, but lower

capacity

Simple

In-Memory1

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 performanceand 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.

Figure 5: Atlant is USX Hyper-con verged Cluster

8/9/2019 Tips 1278

12/70


version 1.1

3.3.2 Atlantis Simple Hybrid Volume (ILIO Persistent VDI)

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 ofdesktops 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 (ILIO Diskless VDI)

Atlantis simple in-memory volumes eliminate storage from stateless VDI deployments by using local server

RAM and the ILIO 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. The

ILIO SnapClone technology is used to persist the ILIO data store in case of ILIO VM reboots, power outages,

or other failures.

8/9/2019 Tips 1278

13/70


version 1.1

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 5 on page 43. 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, nx360Hypervisor • ESXi, XenServer

Graphics Acceleration

• NVIDIA GRID K1 or K2Shared Storage

• IBM Storwize V7000• IBM FlashSystem 840

Networking• 10GbE• 10GbE FCoE

• 8 or 16 Gb FC

Flex System Chassis

Compute/Management Servers• Flex System x240Hypervisor

• 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

• x3650Hypervisor • ESXi, XenServer

Graphics Acceleration

• NVIDIA GRID K1 or K2Shared Storage

• Not applicableNetworking

• 10GbE

Not Recommended

E n t e r p r i s e ( > 6 0 0 u s e r s )

S M B ( < 6 0 0 u s e r s )

Figure 6: Operat ional mod el 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

8/9/2019 Tips 1278

14/70


version 1.1

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 Shared storage

4.10 Networking

4.11 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.8 Management servers (may not be needed)

4.9 Shared storage (see section on IBM Storwize V3700)

4.10 Networking (see section on 10 GbE and iSCSI)

4.11 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:


4.6 Compute servers for hyper-converged


8/9/2019 Tips 1278

15/70


version 1.1


4.10.1 10 GbE networking

4.11 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.


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.

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.

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.

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.

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

http://www.ibm.com/systems/x/os/vmware/http://www.ibm.com/systems/x/os/vmware/http://www.ibm.com/systems/x/os/vmware/

8/9/2019 Tips 1278

16/70


version 1.1

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.

Because the SCVMM library is large, it is recommended that it is accessed by using a remote share.

4.3 Compute servers for virtual desktopsThis 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 andvSwap can be disabled.

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

4.3.1 Intel Xeon E5-2600 v3 processor family servers

Table 2 lists the LoginVSI performance of E5-2600 v3 processors from Intel that use the Login VSI 4.1 office

worker workload with ESXi 6.0.

http://support.microsoft.com/kb/2681638http://support.microsoft.com/kb/2681638http://support.microsoft.com/kb/2681638

8/9/2019 Tips 1278

17/70


version 1.1

Table 2: Performanc e with off ice worker wo rkload

Processor with office worker workload MCS Stateless MCS Dedicated

Two E5-2650 v3 2.30 GHz, 10C 105W 239 users 234 users




Table 3 lists the results for the Login VSI 4.1 knowledge worker workload.

Table 3: Performance with know ledge worker worklo ad

Processor with knowledge worker workload MCS Stateless MCS Dedicated



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 mightoutweigh 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.

Previous Reference Architectures used Login VSI 3.7 medium and heavy workloads. Table 4 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.

8/9/2019 Tips 1278

18/70


version 1.1

Table 4: Comp arison of Lo gin VSI 3.7 and 4.1 Worklo ads

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 4.1 Knowledge worker 252 users 246 users

Two E5-2690 v3 2.60 GHz, 12C 135W 3.7 Heavy 348 users 319 users

Table 5 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 5: Comp arison of E5-2600 v2 and E5-2600 v3 processo rs

Processor Workload MCS Stateless MCS Dedicated







Table 6 lists the LoginVSI performance of E5 2600 v3 processors from Intel that uses the Office worker

workload with XenServer 6.5.

Table 6: XenServer 6.5 perform ance with Off ice worker worklo ad

Processor with medium workload Hypervisor MCS stateless MCS dedicated

Two E5-2650 v3 2.30 GHz, 10C 105W XenServer 6.5 225 users 224 users


Table 7 shows the results for the same comparison that uses the Knowledge worker workload.

Table 7: XenServer 6.5 perform ance with Kno wledge wo rker work load

Processor with heavy workload Hypervisor MCS stateless MCS dedicated


The default recommendation for this processor family is the Xeon E5-2650v3 processor and 512 GB of system

memory because this configuration provides the best coverage for a range of users. For users who need VMs

that are larger than 3 GB, Lenovo recommends the use of 768 GB and the Xeon E5-2680v3 processor.

8/9/2019 Tips 1278

19/70


version 1.1

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 8 lists the processor usage with ESXi for the recommended user counts for normal mode and failover

mode.

Table 8: 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 9 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.

Table 9: Recomm ended number of virtual desktops p er 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 10 lists the approximate number of compute servers that are needed for different numbers of users and

VM sizes.

Table 10: Com pute servers needed for di f ferent num bers of u sers 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

Compute servers @140 users (normal) 5 11 33 72

Compute servers @168 users (failover) 4 9 27 60

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

8/9/2019 Tips 1278

20/70


version 1.1

For stateless desktops, local SSDs can be used to store the write-back cache for improved performance. 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.

4.3.2 Intel Xeon E5-2600 v2 processor family servers with Atlantis ILIO

Atlantis ILIO 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 ILIO

technology and gives an indication of the storage usage and performance. Dedicated and stateless virtual

desktops have different performance measurements and recommendations.

VMs under ILIO are deployed on a per server basis. It is also recommended to use a separate storage logical

unit number (LUN) for each ILIO VM to support failover. Therefore, the performance measurements and

recommendations in this section are on a per server basis. Note that these measurements are currently for theE5-2600 v2 processor using Login VSI 3.7.

Dedicated virtual desktops

For environments that are not using Atlantis ILIO, it is recommended to use linked clones to conserve shared

storage space. However, with Atlantis ILIO, 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.

ILIO Persistent VDI with disk-backed mode (USX simple hybrid volume) is used for dedicated virtual desktops.

The memory that is required for in-memory mode is high and is not examined further in this version of the

reference architecture. Table 11 shows the Login VSI performance with and without the ILIO Persistent VDIdisk-backed solution on ESXi 5.5.

Table 11: Performance o f persistent d esktops with ILIO Persistent VDI

Processor Workload Dedicated Dedicated with ILIO Persistent VDI

Two E5-2650v2 8C 2.7 GHz Medium 218 users 175 users


Two E5-2690v2 10C 3.0 GHz Heavy 249 users 186 users

There is an average difference of 20% - 30% in the work that is done by the two vCPUs of the Atlantis ILIO VM.

It is recommended that higher-end processors (such as E5-2690v2) are used to maximize density.

The ILIO Persistent VDI VM uses 5 GB of RAM. In addition, the ILIO RAM cache requires more RAM and

Atlantis Computing provides a calculator for this RAM. Lenovo testing found that 275 VMs used 35 GB out of

the 50 GB RAM. In practice, most servers host less VMs, but each VM is much larger. Proof of concept (POC)

testing can help determine the amount of RAM, but for most situations 50 GB of RAM should be sufficient.

Assuming 4 GB for the hypervisor, 59 GB (50 + 5 + 4) of system memory should be reserved. It is

recommended that at least 384 GB of server memory is used for ILIO Persistent VDI deployments.

8/9/2019 Tips 1278

21/70


version 1.1

Table 12 lists the recommended number of virtual desktops per server for different VM memory sizes for a

medium workload. This configuration can be a more cost-effective, higher-density route for larger VMs that

balance RAM and processor utilization.

Table 12: Recommend ed numb er of virtual desktops p er server with ILIO Persistent VDI



Total system memory 384 GB 512 GB 768 GB

Reserved system memory 59 GB 59 GB 59 GB

System memory for desktop VMs 325 GB 452 GB 709 GB



Table 13 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 13: Compu te servers needed for di f ferent num bers of users w ith ILIO Persistent VDI

600 users 1500 users 4500 users 10000 users

Compute servers for 125 users (normal) 5 12 36 80

Compute servers for 150 users (failover) 4 10 30 67


The amount of disk storage that is used depends on several factors, including the size of the original image,the amount of user unique storage, and the de-duplication and compression ratios that can be achieved.

Here is a best case example: A Windows 7 image uses 21 GB out of an allocated 30 GB. For 160 VMs that are

using full clones, the actual storage space that is needed is 3360 GB. For ILIO, the storage space that is used

is 60 GB out of an allocated datastore of 250 GB. This configuration is a saving of 98% and is best case, even

if you add the 50 GB of disk space that is needed by the ILIO VM.

It is still a best practice to separate the user folder and any other shared folders into separate storage. That

leaves all of the other possible changes that might occur in a full clone must be stored in the ILIO data store.

This configuration is highly dependent on the environment. Testing by Atlantis Computing suggests that 3.5 GB

of unique data per persistent VM is sufficient. Comparing against the 4800 GB that is needed for 160 full cloneVMs, this configuration still represents a saving of 88%. It is recommended to reserve 10% - 20% of the total

storage that is required for the ILIO data store.

As a result of the use of ILIO Persistent VDI, 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, such as the IBM FlashSystem™ 840 system, a

8/9/2019 Tips 1278

22/70


version 1.1

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 ILIO. Without the

use of XenDesktop, a boot of 100 VMs in a single ILIO 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

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.

Stateless virtual desktops

Two different options were tested for stateless virtual desktops: one is ILIO Persistent VDI with disk- backed

mode to local SSDs and the other is ILIO Diskless VDI (USX simple in-memory volume) to server memory

without compression. For ILIO Persistent VDI, the difference data is stored on the local SSDs as before. For

ILIO Diskless ILIO, it is important to issue a SnapClone to a backing store so that the diskless VMs do not need

to be re-created each time the ILIO Diskless VM is started. Table 14 lists the Login VSI performance with and

without the ILIO VM on ESXi 5.5.

Table 14: Perform ance of stateless deskto ps

Processor Workload MCS stateless MCS stateless

with ILIO

Persistent VDI

MCS stateless

with ILIO

Diskless VDI

Two E5-2650v2 8C 2.7 GHz Medium 218 users 178 users 180 users

Two E5-2690v2 10C 3.0 GHz Medium 282 users 226 users 236 users

Two E5-2690v2 10C 3.0 GHz Heavy 247 users 178 users 189 users

There is an average difference of 20% - 35% in the work that is done by the two vCPUs of the Atlantis ILIO VM.

It is recommended that higher-end processors (such as the E5-2690v2) are used to maximize density. The

maximum number of users that is supported is slightly higher for ILIO Diskless VDI, but the RAM requirement

is also much higher.

For the ILIO Persistent VDI that uses local SSDs, the memory calculation is similar to that for persistent virtual

desktops. It is recommended that at least 384 GB of server memory is used for ILIO Persistent VDI

deployments. For more information about recommendations for ILIO Persistent VDI that use local SSDs for

stateless virtual desktops, see Table 12 and Table 13. The same configuration can also be used for stateless

desktops with shared storage; however, the performance of the write operations likely becomes much worse.

The ILIO Diskless VDI VM uses 5 GB of RAM. In addition, the ILIO RAM cache and RAM data store requires

extra RAM. Atlantis Computing provides a calculator for this RAM. Lenovo testing found that 230 VMs used 69

GB of RAM. In practice, most servers host less VMs and each VM has more differences. POC testing can help

determine the amount of RAM, but 128 GB should be sufficient for most situations. Assuming 4 GB for the

hypervisor, 137 GB (128 + 5 + 4) of system memory should be reserved. In general, it is recommended that a

8/9/2019 Tips 1278

23/70


version 1.1

minimum of 512 GB of server memory is used for ILIO Diskless VDI deployments.

Table 15 lists the recommended number of stateless virtual desktops per server for different VM memory sizes

for a medium workload.

Table 15: Recommend ed numb er of virtual desktops p er server with ILIO Diskless VDI



Total system memory 512 GB 512 GB 768 GB

Reserved system memory 137 GB 137 GB 137 GB

System memory for desktop VMs 375 GB 375 GB 631 GB



Table 16 shows the number of compute servers that are needed for different numbers of users and VM sizes. A

server with 512 GB system memory is used for 2 GB and 3 GB VMs, and 768 GB system memory is used for 4

GB VMs.

Table 16: Compu te servers needed for di f ferent num bers of users and VM sizes with ILIO Diskless VDI

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



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

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




Disk storage is needed for the master images and each SnapClone data store for ILIO Diskless VDI VMs. This

storage does not need to be fast because it is used only to initially load the master image or to recover an ILIO

Diskless VDI VM that was rebooted.

As with persistent virtual desktops, the addition of the ILIO technology reduces the IOPS that is needed for

boot, login, remaining in steady state, and logoff. This reduces the time to bring a VM online and improves user

response time.

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.

8/9/2019 Tips 1278

24/70


version 1.1

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 48.

4.4.1 Intel Xeon E5-2600 v3 processor family servers

Table 17 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 17: ESXi 6.0 results for sh ared hosted d esktops usin g the E5-2600 v3 processo rs

Processor Hypervisor Workload Hosted Desktops

Two E5-2650 v3 2.30 GHz, 10C 105W ESXi 6.0 Office Worker 222 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 18 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 18: XenServer 6.5 results for shared ho sted deskto ps u sing the E5-2600 v3 proc essors

Processor Hypervisor Workload Hosted Desktops

Two E5-2650 v3 2.30 GHz, 10C 105W XenServer 6.5 Office Worker 225 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

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 a 25% headroom on servers to cope with possible

failover scenarios. Lenovo recommends a general failover ratio of 5:1.

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

8/9/2019 Tips 1278

25/70


version 1.1

Table 19: Processor usage

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 20 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.





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

4.4.2 Intel Xeon E5-2600 v2 processor family servers with Atlantis ILIO

Atlantis ILIO provides in-memory storage optimization by using a 100% software solution. There is an effect on

processor and memory usage while offering decreased storage usage and increased IOPS. This section

contains performance measurements for processor and memory utilization of ILIO technology and describes

the storage usage and performance.

VMs under ILIO are deployed on a per server basis. It is recommended to use a separate storage LUN for

each ILIO VM to support failover. The performance measurements and recommendations in this section are on

a per server basis. Note that these measurements are currently for the E5-2600 v2 processor using Login VSI

3.7.

The performance measurements and recommendations are for the use of ILIO Persistent VDI with hosted

shared desktops. Table 21 lists the processor performance results for the Xeon E5-2600 v2 series of

processors.

Table 21: Performance results for sh ared hosted desktop s using the E5-2600 v2 processor s

Workload Hypervisor Processor Desktops without

ILIO

Desktops with ILIO

Persistent VM

Medium VMware ESXi 5.5 Two E5-2650v2 214 users 193 users

Medium VMware ESXi 5.5 Two E5-2690v2 283 users 257 users

Heavy VMware ESXi 5.5 Two E5-2690v2 241 users 220 users

On average, there is a difference of 20% - 30% that can be attributed to work that is done by the two vCPUs of

the Atlantis ILIO VM. It is recommended that higher-end processors (such as E5-2690v2) are used to maximize

density.

8/9/2019 Tips 1278

26/70


version 1.1

The ILIO Persistent VDI VM uses 5 GB of RAM. In addition, the ILIO RAM cache requires more RAM. Atlantis

Computing provides a calculator for this RAM. Lenovo testing found that the four VMs used 32 GB. In practice,

most servers host less VMs and each VM is much larger. POC testing can help determine the amount of RAM.

However, for most circumstances, 60 GB should be enough. It is recommended that at least 192 GB of server

memory is used for ILIO Persistent VDI deployments of hosted desktops.

Table 22 shows the recommended number of shared hosted desktops per compute server that uses two Xeon

E5-2690v2 series processors, which allows for some processor headroom for the hypervisor and a 5:1 failover

ratio in the compute servers.

Table 22: Recommended num ber of shared hosted desktop s per server

Workload Normal case Normal utilization Failover case Failover utilization

Medium 180 70% 216 84%

Heavy 160 73% 192 87%

Table 23 shows the number of compute servers that is needed for different number of users. Each compute

server has 256 GB of system memory for the four VMs and the ILIO Persistent VDI VM.





Failover ratio 3:1 3.5:1 5:1 4.5:1

The amount of disk storage that is used depends on several factors, including the size of the original Windows

Server image, the amount of unique storage and the de-duplication and compression ratios that can be

achieved. A Windows 2008 R2 image uses 19 GB. For four VMs, the actual storage space that is needed is

76 GB. For ILIO, the storage space that is used is 25 GB, which is a saving of 67%.

As a result of the use of ILIO Persistent VDI, the only read I/O operations that are needed are those 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 booting, logging in, remaining in steady state, and logging off,

but the overall IOPS count is substantially reduced.

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 and4.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

8/9/2019 Tips 1278

27/70


version 1.1

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 thatare 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 v2 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

13. Note that these measurements are currently for the E5-2600 v2 processor using Login VSI 3.7.

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 24 shows the processor performance results for the Xeon E5-2650v2 and Xeon E5-2690v2 series of

processors by using stateless virtual machines on local HDDs with XenServer 6.5. This configuration used 12

300 GB 15 k RPM HDDs in a RAID 10 array. Measurements showed that 8 HDDs was barely sufficient for the

required IOPS and the capacity requirements. Table 24 also shows the performance with SSDs to compare the

overhead of local HDD usage.

Table 24: Performanc e results for stateless virtual deskto ps u sing the E5-2600 v2 processo rs

Processor Workload XenServer 6.5 with HDD XenServer 6.5 with SSD



Two E5-2690v2 10C 3.0 GHz Heavy 192 users 213 users

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-2650v2 processors,

256 GB of memory, and 8 HDDs. The extra memory is needed for the VM for management servers.

http://www.citrix.com/go/products/xendesktop/feature-matrix.htmlhttp://www.citrix.com/go/products/xendesktop/feature-matrix.htmlhttp://www.citrix.com/go/products/xendesktop/feature-matrix.html

8/9/2019 Tips 1278

28/70


version 1.1

For average user counts, each server supports 125 users at most by using two E5-2650v2 processors,

256 GB of memory, and 12 HDDs.

For heavy users the E5-2690v2 processor can be used with 384 GB of memory.

These configurations need two HDDs for XenServer or a USB key for ESXi.

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

Table 25: SMB Com pute servers needed for di f ferent numb ers of users and VM sizes


Compute servers for 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

For more information, see “BOM for SMB compute servers” on page 43.

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 52.

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 26 lists the processor usage for the recommended number of

users.

Table 26: Processor usage fo r Atlant is 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.

8/9/2019 Tips 1278

29/70


version 1.1

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

Table 27: Recommended number of virtual deskto ps per server for Atlant is USX

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


System memory 384 GB 512 GB 768 GB

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

Memory for virtual machines 321 GB 449 GB 705 GB



Table 28 lists the approximate number of compute servers that are needed for different numbers of users and

VM sizes.

Table 28: Com pute servers needed for di f ferent num bers of u sers for Atlant is USX

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: Atlant is USX pro cessor usag e: server power off

8/9/2019 Tips 1278

30/70


version 1.1

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.


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 vDGA and vGPU because

accelerated graphics tends to put an extra load on the processor. For the vDGA option, 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.

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.

Table 29 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 29: Perform ance of GRID K1 pass-thro ugh mod e by usin g DirectX 11

Quality Tessellation Anti-Aliasing Resolution K1

High Normal 0 1024x768 14.3


High Normal 0 1280x1024 11.4



Table 30 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.

8/9/2019 Tips 1278

31/70


version 1.1

Table 30: Perform ance of GRID K2 pass-thro ugh mod e by usin g DirectX 11

Quality Tessellation Anti-Aliasing Resolution K2

High Normal 0 1680x1050 52.6

Ultra Extreme 8 1680x1050 29.2





adapter by using vGPU mode with DirectX 11. The K180Q profile has similar performance to the K1

pass-through mode.

Table 31: Performance o f GRID K1 vGPU m odes b y usin g DirectX 11

Quality Tessellation Anti-Aliasing Resolution K180Q K160Q K140Q

High Normal 0 1024x768 14.3 7.8 4.4

High Normal 0 1280x768 12.3 6.7 3.7

High Normal 0 1280x1024 11.4 5.5 3.1

High Normal 0 1680x1050 7.8 4.3 N/A

High Normal 0 1920x1200 5.5 3.5 N/A


adapter by using vGPU mode with DirectX 11. The K280Q profile has similar performance to the K2

pass-through mode.

Table 32: Performance o f GRID K2 vGPU modes b y usin g DirectX 11

Quality Tessellation Anti-Aliasing Resolution K280Q K260Q K240Q

High Normal 0 1680x1050 52.6 26.3 13.3

High Normal 0 1920x1200 N/A 20.3 10.0

Ultra Extreme 8 1680x1050 29.2 N/A N/A


Ultra Extreme 8 1920x1200 23.9 11.5 N/A


The GRID K2 GPU has more than twice the performance of the GRID K1 GPU, even with the high quality,

tessellation, and anti-aliasing options. This result is expected because of the relative performance

characteristics of the GRID K1 and GRID K2 GPUs. The frame rate decreases as the display resolution

increases.

8/9/2019 Tips 1278

32/70


version 1.1

Because there are many variables when graphics acceleration is used, Lenovo recommends that testing is

done in the customer environment to verify the performance for the required user workloads.

For more information about the bill of materials (BOM) for GRID K1 and K2 GPUs for Lenovo System x3650

M5 and NeXtScale nx360 M5 servers, see the following corresponding BOMs:

“BOM for enterprise compute servers” on page 43

“BOM for SMB compute servers” on page 52

“BOM for hyper-converged compute servers” on page 53


Management servers should have the same hardware specification as compute servers so that they can be

used interchangeably in a worst-case scenario. The Citrix XenDesktop management servers also use the

same hypervisor, but have management VMs instead of user desktops. Table 33 lists the VM requirements and

performance characteristics of each management service for Citrix XenDesktop.

Table 33: Characterist ics o f XenDesktop and ESXi managemen t services

Management

service VM

Virtual

processors

System

memory

Storage Windows

OS

HA

needed

Performance

characteristic

Delivery

controller

4 4 GB 15 GB 2008 R2 Yes 5000 user connections

Web Interface 4 4 GB 15 GB 2008 R2 Yes 30,000 connections per

hour

Citrix 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

(depends

on number

of images)

2008 R2 Yes Up to 1000 desktops,

memory should be a

minimum of 2 GB plus

1.5 GB per image served

vCenter server 4 4 GB 15 GB 2008 R2 No Up to 2000 desktops

vCenter SQLserver

4 4 GB 15 GB 2008 R2 YesDouble the virtualprocessors and memory

for more than 2500 users

PVS servers often are run natively on Windows servers. The testing showed that they can run well inside a VM,

if it is sized per Table 33. The disk space for PVS servers is related to the number of provisioned images.

Table 34 lists the number of management VMs for each size of users following the high availability and

performance characteristics. The number of vCenter servers is half of the number of vCenter clusters because

each vCenter server can handle two clusters of up to 1000 desktops.

8/9/2019 Tips 1278

33/70


version 1.1

Table 34: Management VMs n eeded

XenDesktop management service VM 600 users 1500 users 4500 users 10000 users

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(1+1)

N

N

Web Interface N/A 2 (1+1) 2 (1+1) 2 (1+1)

Citrix 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)

ESXi 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)

Each management VM requires a certain amount of virtual processors, memory, and disk. There is enough

capacity in the management servers for all of these VMs. Table 35 lists an example mapping of the

management VMs to the four physical management servers for 4500 users.

Table 35: Management server VM m apping (4500 users)

Management service for 4500

stateless users

Management

server 1

Management

server 2

Management

server 3

Management

server 4

vCent

Documents

Tips 1278