EMC Infrastructure for Virtual Desktops - Insightimg2.insight.com/graphics/uk/media/pdf/infrastructure-virtual.pdfEMC Infrastructure for Virtual Desktops. Enabled by EMC Unified Storage

EMC Infrastructure for Virtual Desktops

Enabled by EMC Unified Storage (FC), Microsoft Windows Server 2008 R2 Hyper-V,

and Citrix XenDesktop 4

Proven Solution Guide

EMC <offerings> for<Application>

Enabled by <Products/Services> on <OS>

using <Network Transport>>

Copyright © December, 2010 EMC Corporation. All rights reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. Benchmark results are highly dependent upon workload, specific application requirements, and system design and implementation. Relative system performance will vary as a result of these and other factors. Therefore, this workload should not be used as a substitute for a specific customer application benchmark when critical capacity planning and/or product evaluation decisions are contemplated. All performance data contained in this report was obtained in a rigorously controlled environment. Results obtained in other operating environments may vary significantly. EMC Corporation does not warrant or represent that a user can or will achieve similar performance expressed in transactions per minute. No warranty of system performance or price/performance is expressed or implied in this document. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All other trademarks used herein are the property of their respective owners. Part number: h8111

EMC Infrastructure for Virtual Desktops Enabled by EMC Unified Storage (FC), Microsoft Windows Server 2008 R2 Hyper-V, and Citrix XenDesktop 4 Proven Solution Guide

2

Table of Contents

Chapter 1: About this Document...............................................................................................................4

Overview ...........................................................................................................................................4 Audience and purpose ......................................................................................................................4 Scope ................................................................................................................................................5 Technology solutions ........................................................................................................................6 Virtual Desktop Infrastructure............................................................................................................6 Reference architecture......................................................................................................................8 Validated environment profile............................................................................................................8 Prerequisites and supporting documentation..................................................................................10 Terminology.....................................................................................................................................11

Chapter 2: Virtual Desktop Infrastructure................................................................................................12 Overview .........................................................................................................................................12 XenDesktop VDI..............................................................................................................................12 Microsoft Virtualization ....................................................................................................................13 Windows infrastructure....................................................................................................................14 Conclusion.......................................................................................................................................15

Chapter 3: Storage Design......................................................................................................................16 Overview .........................................................................................................................................16 Concepts .........................................................................................................................................16 Storage design layout .....................................................................................................................16 LUN layout.......................................................................................................................................18 Capacity planning............................................................................................................................20 Best practices..................................................................................................................................21

Chapter 4: Network Design .....................................................................................................................22 Overview .........................................................................................................................................22 Considerations ................................................................................................................................22 Network layout.................................................................................................................................23 Virtual LANs ....................................................................................................................................23 High availability network..................................................................................................................24

Chapter 5: Installation and Configuration................................................................................................25 Overview .........................................................................................................................................25 Task 1: Set up and configure the FC LUNs ....................................................................................26 Task 2: Install and configure Desktop Delivery Controller ..............................................................26 Task 3: Install and configure Provisioning Server...........................................................................32 Task 4: Configure and provision the master virtual machine template...........................................45 Task 5: Deploy virtual desktops ......................................................................................................45

Chapter 6: Testing and Validation...........................................................................................................51 Overview .........................................................................................................................................51 Testing overview .............................................................................................................................51 Testing tools ....................................................................................................................................51 Test results......................................................................................................................................53 Result analysis of Desktop Delivery Controller ...............................................................................54 Result analysis of Provisioning Server............................................................................................58 Result analysis of the SCVMM Server............................................................................................62 Result analysis of SQL Server ........................................................................................................64 Result analysis of Windows 2008 R2 Hyper-V servers ..................................................................68 Result analysis of Celerra unified storage ......................................................................................73 Login storm scenario.......................................................................................................................82 Test summary..................................................................................................................................84


3


4

Chapter 1: About this Document

Overview

Introduction EMC's Total Customer Experience (TCE) program, a commitment to continuously improving quality, is driven by Six Sigma methodologies. As a result, EMC has built Customer Integration Labs in its Global Solutions Centers to reflect real-world deployment scenarios where TCE use cases are developed and executed. These use cases provide EMC with insight into the challenges currently facing its customers. This document summarizes a series of best practices that were discovered, validated, and observed during the validation of the EMC Virtual Infrastructure for Virtual Desktops Enabled by EMC® Celerra® Unified Storage (FC), Microsoft Windows Server 2008 R2 Hyper-V, and Citrix XenDesktop 4 solution.

Use case definition

A use case reflects a defined set of tests that validates the reference architecture for a customer environment. This validated architecture can then be used as a reference point for a Proven Solution.

Contents The chapter includes the following topics:

Topic See Page

Overview 4 Audience and purpose 4 Scope 5 Technology solutions 6 Virtual Desktop Infrastructure 6 Reference architecture 8 Validated environment profile 8 Prerequisites and supporting documentation 10 Terminology 11

Audience and purpose

Audience The intended audience for the Proven Solution Guide is:

Internal EMC personnel EMC partners Customers

Purpose The purpose of this solution is to: Develop a recommended Citrix XenDesktop 4 VDI for 1,000 users with the

EMC Celerra unified storage platform and the Microsoft Windows Server 2008 R2 Hyper-V virtualization platform.

Test and document the user response time, and performance of the associated servers.

Information in this document can be used as the basis for a solution build, white paper, best practices document, or training. It can also be used by other EMC organizations (for example, the technical services or sales organization) as the basis for producing documentation for technical services or a sales kit.

Scope

Scope This document describes the architecture of an EMC solution built at EMC’s Global

Solutions Lab. This solution is engineered to enable customers to: Implement a Citrix XenDesktop VDI 4 solution in their environment after

considering the storage configuration, design, sizing, and software. Reduce operational costs with VDI, when compared against existing desktop

solutions. Deliver the highest level of service level agreement (SLA) with the lowest cost per

application workload. Provide the VDI with the flexibility of a solution that offers a simple footprint for

midsize organizations, and can scale up to meet the requirements of large enterprises.

This solution provides information for: Creating a high-performance storage design for a Citrix XenDesktop 4 VDI on a

Microsoft Windows Server 2008 R2 Hyper-V virtualization platform for 1,000 desktop users on an EMC Celerra NS-120 unified storage system.

Documenting the performance in the validated environment, and suggesting methods to improve the performance of the Citrix XenDesktop 4 solution.

Not in scope Testing XenDesktop 4 VDI for a workload other than a typical office user workload

was outside the scope of this testing.


5


6

Technology solutions

Business challenges for midsize enterprises

With limited resources and increasing demands, today's business must address the following challenges: Consolidate desktops across the enterprise Ensure information access, availability, and continuity Maximize server and storage utilization, and deliver high desktop performance Manage upgrades and migration quickly and easily Reduce the demands on limited IT resources and budgets Reduce the complexity of selecting the right technology

Solution for midsize enterprises

The EMC Virtual Infrastructure for Virtual Desktops Enabled by EMC Celerra Unified Storage (FC), Microsoft Windows Server 2008 R2 Hyper-V, and Citrix XenDesktop 4 solution establishes a validated hardware and software configuration that permits an easy and repeatable deployment of virtual desktops using the storage provided by an EMC Celerra NS-120. This Proven Solution Guide describes the deployment and validation of Citrix XenDesktop 4 VDI on the Celerra NS-120 system in a configuration that provides high performance, recoverability, and protection.

Virtual Desktop Infrastructure

Introduction The VDI is used to run desktop operating systems and applications inside virtual

machines that reside on servers running a virtualization hypervisor. The desktop operating systems inside the virtual machines are referred to as virtual desktops. Users access the virtual desktops and applications from a desktop PC client or a thin client by using a remote display protocol. The applications and storage are centrally managed.

Citrix XenDesktop

Citrix XenDesktop is a leader in desktop virtualization. It enables fully personalized desktops for each user while providing security, and the simplicity of centralized management. XenDesktop simplifies desktop management. Using centralized management, adding, updating, and removing applications are easily accomplished. HDX™ technology gives users instant access to applications. The HDX technology is a set of capabilities that delivers a high-definition user experience over any network, including low-bandwidth and high-latency wide area network (WAN) connections. XenDesktop can instantly deliver every type of virtual desktop, with each virtual desktop specifically tailored to meet the performance and flexibility requirements of individual users.

Components of Citrix XenDesktop VDI

This solution has validated a XenDesktop 4 VDI deployment for high availability and simulated the workload of 1,000 real-world users. The VDI was built using the following components: Citrix DDC to broker and manage virtual desktops. Citrix Provisioning Services to provision the desktop operating system (OS). EMC unified storage to store virtual desktops. Microsoft Windows Server 2008 R2 Hyper-V and Microsoft System Center Virtual

Machine Manager 2008 R2 as the server virtualization infrastructure. Windows infrastructure to support services such as Active Directory, dynamic host

configuration protocol (DHCP), Domain Name System (DNS), and SQL Server.


7

Reference architecture

Corresponding reference architecture

This use case has a corresponding reference architecture document that is available on EMC Powerlink® and EMC.com. Refer to EMC Virtual Infrastructure for Virtual Desktops Enabled by EMC Unified Storage (FC), Microsoft Windows Server 2008 R2 Hyper-V, and Citrix XenDesktop 4 — Reference Architecture for details.

Reference architecture diagram

The following diagram shows the overall physical architecture of the solution.

Validated environment profile

Environment profile and test results

The solution was validated with the following environment profile.

Profile characteristic Value Number of virtual desktops 1,000


8

Size of each virtual desktop 3 GB (thin provisioned)

Number of building blocks 10

Number of virtual desktops per building block 100

Number of FC LUNs per building block 1

Number of XenDesktop Provisioning Services Servers 2

Number of XenDesktop Desktop Delivery Controllers 2

FC LUN – RAID type, physical drive size, and speed RAID 1, 450 GB, 15k rpm, FC disks Storage to host the Golden images, TFTP boot area, and ISO images – RAID type, physical drive size, and speed

RAID 5, 450 GB, 15k rpm, FC disks

Hardware resources

Chapter 6: Testing and Validation on page 51 provides more information on the performance results.

The following table lists the hardware used to validate the solution.

Equipment Quantity Configuration Notes

EMC Celerra NS-120 1

Two Data Movers (active/passive)

Two disk-array enclosures (DAEs) with 15 FC 450 GB 15k 2/4 Gb disks

FC LUN storage and Trivial File Transfer Protocol (TFTP) server

HP ProLiant DL380 G5 3

Memory: 20 GB RAM CPU: Two 3.0 GHz quad-core

processors Storage: One 67 GB disk NIC: Two Broadcom

NetXtreme II BCM 1,000 BaseT Adapters

Windows Server 2008 R2 Hyper-V servers to host virtual machines for SCVMM Server, Active Directory, DHCP, DNS, DDC, PVS, and SQL Server

Cisco UCS B200 M1 Blade Server

16

Memory: 48 GB RAM CPU: Two Intel® Xeon® 5500

Series processors 2.533 GHz quad-core processors

Storage: Two 146 GB disks Fibre Channel and Network

Adapter: M71KR-Q QLogic Converged Network Adapter

Windows Server 2008 R2 Hyper-V servers to host 1,000 virtual desktops

Software resources

The following table lists the software used to validate the solution.

Software Version

Celerra NS-120 (Celerra shared storage, file systems)

NAS or Data Access in Real Time (DART) Release 5.6.48-701


9


10

Software Version

CLARiiON® FLARE® Release 28 (4.28.000.5.504)

XenDesktop desktop virtualization

Citrix XenDesktop Version 4 Platinum Edition

Citrix Desktop Delivery Controller Server Version 4.0 SP1

Citrix Provisioning Services Server Version 5.1.2.2972

Microsoft SQL Server Version 2005 Enterprise Edition (64-bit)

Windows 2008 Hyper-V Virtualization Infrastructure Windows Server 2008 R2 Server Core with Hyper-V

Windows 2008 Server R2 Hyper-V (Build 7600)

QLogic FC HBA driver STOR Miniport version 9.1.7.36

QLogic SanSurf FC HBA Manager Version 5.0.1 Build 46

Navisphere® Agent Version 6.29.6.0.35-1

EMC PowerPath® Version 5.3 SP1 (64-bit)

System Center Virtual Machine Manager (SCVMM) 2008 R2

Version 2.0.4271.0

Operating System for SCVMM Server Microsoft Windows Server 2008 R2 Enterprise Edition

Virtual desktops or virtual machines (One vCPU and 512 MB RAM)

OS Microsoft Windows XP Pro Edition

Microsoft Office 2007 Version 12

Internet Explorer 6.0.2900.5512

Adobe Reader 9.1

Adobe Flash Player 10

Bullzip PDF Printer 6.0.0.865

Prerequisites and supporting documentation

Technology It is assumed that the reader has a general knowledge of the following products:

EMC Celerra unified storage Citrix XenDesktop Microsoft Windows Server 2008 R2 Hyper-V

Supporting documents

The following documents, located on Powerlink, provide additional, relevant information. Access to these documents is based on your login credentials. If you do not have access to the following content, contact your EMC representative. EMC Virtual Infrastructure for Virtual Desktops Enabled by EMC Celerra Unified

Storage (FC), Microsoft Windows Server 2008 R2 Hyper-V, and Citrix XenDesktop 4 — Reference Architecture

Configuring Citrix XenDesktop 3.0 with Provisioning Server using EMC Celerra — Build Document

Third-party documents

Product documentation is available on the Citrix and Microsoft websites. Citrix Product Documentation Library for XenDesktop Microsoft Hyper-V Server 2008 Configuration Guide

Terminology

Introduction This section defines the terms used in this document.

Term Definition Desktop Delivery Controller (DDC)

Part of the Citrix XenDesktop virtual desktop delivery system, this controller authenticates users, manages the assembly of users' virtual desktop environments, and brokers connections between users and their virtual desktops.

Citrix Provisioning Services Server (PVS)

Part of the Citrix XenDesktop virtual desktop delivery system, this service creates and de-provisions virtual desktops from a single desktop image on demand, optimizes storage utilization, and provides a pristine virtual desktop to each user every time they log on.

PVS vDisk vDisk exists as a disk image file stored on a Provisioning Server or shared storage device. The vDisk images are configured to provide a choice between Private, Standard, or Difference Disk modes. Private mode gives exclusive read-write access to a single desktop. In Standard or Difference Disk mode, the vDisk is shared between multiple desktops with read-only permissions for each desktop.

PVS write cache Any writes made to the desktop operating system are redirected to a temporary area called the write cache. The write cache can exist as a temporary file on a Provisioning Server in the virtual desktop’s memory or on the virtual desktop’s hard drive.

LoginVSI A third-party benchmarking tool developed by Login Consultants, LoginVSI simulates a real-world VDI workload using an AutoIT script and determines maximum system capacity based on the user’s response time.


11


12

Chapter 2: Virtual Desktop Infrastructure (VDI)

Overview

Introduction The VDI design layout instructions described in this chapter apply to the specific

components used during the development of this solution.

Contents This chapter contains the following topics:

Topic See Page

Overview 12 Citrix XenDesktop VDI 12 Microsoft virtualization 13 Windows infrastructure 14 Conclusion 15

Citrix XenDesktop VDI

Introduction Citrix XenDesktop 4 is a desktop virtualization system that centralizes and delivers

Microsoft Windows XP, 7, or Vista virtual desktops to users located anywhere, without any negative performance impact. XenDesktop 4 simplifies desktop management by using a single image to deliver personalized desktops to users and enables administrators to manage service levels with built-in desktop performance monitoring. The open architecture of XenDesktop 4 offers flexibility when virtualization platforms and user devices.

Deploying a XenDesktop farm

This VDI solution is deployed using a dual-server model in a XenDesktop 4 farm with high availability. This provides a working deployment on a minimal number of computers. As the farm grows, additional controllers and components can be seamlessly added to the farm. The essential elements of a XenDesktop 4 farm are: Desktop Delivery Controller Citrix Licensing Provisioning Server Apart from these Citrix elements, the following components are required for a XenDesktop 4 farm: Microsoft SQL Server to hold the configuration information and administrator

account information Active Directory DNS Server PXE boot and TFTP servers

Desktop Delivery Controller

The Desktop Delivery Controller (DDC) authenticates users, manages the assembly of users' virtual desktop environments, and brokers connections between users and their virtual desktops. It also controls the state of the virtual desktops. Starting and stopping the desktops are centrally-managed processes based on resource demand and administrative configuration. DDC also includes the User Profile Manager to manage user personalization settings in virtualized or physical Windows environments. The Citrix licensing service is also installed on the Desktop Delivery Controller.

Provisioning Server

The Provisioning Server creates and de-provisions virtual desktops on demand from a single desktop image, optimizes storage utilization, and provides a pristine virtual desktop to each user every time they log on. Desktop provisioning also simplifies desktop images, provides the most flexibility, and offers fewer points of desktop management for both applications and desktops.

High availability of XenDesktop components

In this solution, two DDCs and two Provisioning Servers were used to provide high availability and load balancing. For this solution with 1,000 virtual desktops, 500 virtual desktops were managed by each Desktop Delivery Controller. Similarly, each Provisioning Server managed 500 virtual desktops. If the DDC or Provisioning Server goes offline, the other DDC or Provisioning Server takes over the virtual desktops of the offline server and manages all 1,000 virtual desktops.

Microsoft virtualization

Introduction This Citrix XenDesktop 4 VDI solution is implemented on a Microsoft virtualization

infrastructure. This enables organizations to leverage existing investments in Microsoft implementation and infrastructure. The following elements of Microsoft Hyper-V virtualization were used in this solution: Windows Server 2008 R2 Hyper-V System Center Virtual Machine Manager (SCVMM) 2008 R2


13


14

Windows Server 2008 R2 Hyper-V

Microsoft Windows Server 2008 R2 Hyper-V is the virtualization hypervisor that can transform or virtualize computer hardware resources, including CPU, RAM, hard disks, and network controllers, to create a fully functional virtual machine that runs its own operating systems and applications like a physical computer. This solution uses Microsoft Windows Server 2008 R2 Hyper-V in Server Core mode for the Hyper-V servers that host the virtual desktops. The Server Core installation option reduces the attack surface of the operating system, limits the roles the server can host, uses 75 percent less disk space, and provides better performance. Windows Server 2008 R2 failover clustering, and high availability features coupled with cluster shared volumes (CSV) and live migration, enable movement of the virtual desktops from one hypervisor server to another with minimal impact to the end user.

System Center Virtual Machine Manager (SCVMM) 2008 R2

SCVMM 2008 R2 enables simple, efficient, and scalable management for the Microsoft Windows Server 2008 R2 Hyper-V virtualized environment. SCVMM provides the interface that allows XenDesktop 4 to communicate with the Microsoft Windows Server 2008 R2 Hyper-V hosts. SCVMM also provides a service-based interface that can be used by the XenDesktop Pool Management service to manage the virtual desktop.

Windows infrastructure

Introduction Microsoft Windows infrastructure is used in this solution to provide the following

services to virtual desktops and XenDesktop elements: Active Directory Service DNS server DHCP service SQL Server

Domain controller

The Windows domain controller contains the Active Directory service, which provides the ability to manage the identities and relationships of virtual desktops and other components in the VDI environment. Active Directory is used by the DDC to provide secure communication between the XenDesktop components.

DNS server DNS is the primary name resolution mechanism of Windows servers, and serves as

the backbone of Active Directory. Domain Controllers dynamically register information about themselves and about Active Directory in the DNS server. In this solution, the DNS server is installed on the domain controller.

DHCP service The virtual desktops receive their IP addresses, boot server names, and boot file

names from the DHCP server. The IP range of DHCP is configured to allocate IP addresses for 1,000 virtual desktops. Because the virtual desktop virtual machines use PXE boot from a bootstrap image prior to loading the master desktop image supplied by Citrix Provisioning Services, DHCP options 66 and 67 are configured to redirect the virtual desktops to retrieve the bootstrap image from a TFTP server hosted on the EMC Celerra.

SQL Server Microsoft SQL Server is a relational database management system (RDBMS).

In this solution, Microsoft SQL Server 2005 satisfies the database requirement for Citrix Provisioning Services and DDC. It can also be used to satisfy the database requirements for an SCVMM 2008 R2 Server. Microsoft SQL Server 2005 Enterprise Edition (64-bit) is used in this solution. Though Microsoft SQL Server 2005 Express Edition is free, lightweight, and can satisfy the database requirements for a very small virtual desktop farm, it is not recommended for use in production environments because its support is limited to 1 CPU, 1 GB of addressable RAM, and a maximum database size of 4 GB.

Conclusion

Conclusion This XenDesktop 4 VDI implementation for 1,000 virtual desktops is configured in a

desktop farm containing two Desktop Delivery Controllers and two Provisioning Servers for high availability, using existing Microsoft Hyper-V virtual infrastructure and Windows servers to provide networking and database services.


15


16

Chapter 3: Storage Design

Overview

Introduction The storage design and layout instructions described in this chapter apply to the

specific components of this solution


Topic See Page

Overview 16 Concepts 16 Storage design layout 16 LUN layout 18 Capacity planning 20 Best practices 21

Concepts

Introduction The EMC Celerra unified storage system is used for most of the storage needs of

this solution. The Celerra is a multiprotocol storage system that provides access to data over FC, and other storage access protocols. It can scale quickly to manage anticipated data growth, especially as the storage need for virtual machines increases on Microsoft Hyper-V servers. Celerra thin provisioning improves the utilization of storage capacity, and simplifies storage management by presenting virtual machines with sufficient capacity. It can be shared across multiple Microsoft Hyper-V servers, enabling storage consolidation to provide efficient use of storage resources, which is valuable for clustering and migration.

Storage design layout

Building block approach

This VDI solution is validated using a building block approach, which allows administrators to incrementally provision additional blocks of storage as the number of desktop users continues to increase. A building block is defined as two spindles on a 1+1 RAID 1 group. Each of these building blocks is designed to accommodate up to 100 virtual desktop users. The validation test uses up to 10 building blocks to support 1,000 virtual desktops.

Disk layout for 10 building blocks

The following figure shows the disk layout for 10 RAID 1 building blocks on three shelves that are configured using Navisphere Manager.

The NS-120 can be populated with up to eight disk shelves of 15 disk drives each. This validated solution uses three shelves of 450 GB 15k FC drives. Ten RAID 1 groups are used to store the virtual desktops. Two 4+1 RAID 5 groups (RG 0 and 10) are used to store the golden image of virtual desktops, the TFTP boot image, user profiles, and other support files.


17


18

LUN layout

LUN Configuration

Each building block consists of a single LUN in a RAID 1 group. LUNs of consecutive RAID groups are owned by a different storage processor (SP) for load balancing. Each LUN is presented to the Hyper-V host in as an NTFS-formatted volume within a primary partition. The following table shows the LUN ID selection for each of the volumes created.

File system Storage

TFTP boot Celerra FS from LUN ID 17

User Profiles (CIFS Share) Celerra FS from LUN ID 18

AD/SCVMM/SQL Server VMs LUN ID 19

DDC1/PVS1 VMs LUN ID 20

DDC2/PVS2 VMs LUN ID 21

Golden Image LUN ID 22

Failover Clustering Witness Disk LUN ID 23

Building Block 1 – LUN ID 24

Building Block 2 - LUN ID 25








Virtual desktop groups (FC storage for virtual desktops)


FC LUN usage The Celerra unified storage platform is used to store the following:

Virtual desktop virtual machines Citrix Provisioning Services vDisk TFTP boot image Roaming user profiles

Virtual desktop virtual machines

The virtual desktops are deployed as virtual machines that are hosted on Windows 2008 R2 Hyper-V servers. Each desktop virtual machine has its own folder that contains xml, bin, vsv, vhd, and other files that are stored on Fibre Channel LUNs bound on the EMC Celerra NS-120 unified storage system. In this proven solution, each building block is configured with one FC LUN that accommodates up to 100 virtual desktops. There are a total of 10 FC LUNs to support up to 1,000 virtual desktops.

Citrix Provisioning Services vDisk

The master desktop image is stored on a Citrix Provisioning Services vDisk, which corresponds to a virtual hard disk (VHD) file that resides on a local drive (NTFS formatted) on one of the Provisioning Servers. Because the Provisioning Servers are virtualized as virtual machines, the local drive that holds the master image is a pass-through disk that corresponds to a LUN, which is created from a 4+1 RAID 5 group (RG 10 as shown in the Disk layout for 10 building blocks on page 17) on the Celerra. The following figure shows the storage layers of the vDisk.

The NTFS file system is made read-only when the master image is finalized and ready to be sealed. The read-only file system enables concurrent access for multiple Provisioning Servers without the need for a clustering file system to handle any locking issues that may arise.

TFTP server All virtual desktops need to PXE boot from a bootstrap image when they are

powered up. This bootstrap image is stored on a file system on RAID group 0 on the Celerra. The image is then made available through the Celerra TFTP server.

FC LUN

Pass-through disk

Read-only NTFS

VHD file

vDisk

Desktop OS image


19


20

Roaming profiles and folder redirection

Using the local user profile is not recommended in a VDI environment because a performance penalty is incurred when a new local profile is created whenever a user logs in to a new desktop image. Roaming profiles and folder redirection allow user data to be stored centrally on a network location that can reside on a Celerra CIFS share. This reduces the performance hit during user logon while allowing user data to roam with the profiles. Alternative profile management tools such as Citrix User Profile Manager or a third-party tool such as AppSense Environment Manager provide more advanced and granular features to manage various user profile scenarios. Refer to User Profiles for XenApp and XenDesktop on the Citrix website for further details.

Capacity planning

Building block of 100 virtual desktops

Storage design layout on page 16 describes the building block approach used in this solution. Each building block consists of two spindles on a 1+1 RAID 1 group that is designed to accommodate up to 100 virtual desktop users. The Celerra NS-120 uses 450 GB FC 15k rpm spindles. As mentioned in Disk layout for 10 building blocks on page 17, a LUN is bound on a RAID 1 group that provides a storage space of approximately 402 GB. LUNs on consecutive RAID groups are owned by different storage processors (SPs) for load balancing. This 402 GB LUN presented to the Windows 2008 Server Hyper-V host is adequate for 100 virtual desktops of 3 GB each. The 3 GB is thin provisioned and used as Provisioning Services’ write cache storage, creating a temporary area to save changes made to the virtual desktops. Virtual desktops typically consume several hundred megabytes of write cache. Do not overflow the write cache area allocated to each virtual desktop. Users may experience disk errors when performing write operations if the write cache area has exceeded its capacity. In addition to virtual disk storage, each virtual desktop requires storage for a .bin file that stores the saved state information for a virtual machine. Its size is equal to the RAM allocated for each virtual machine. Because each virtual machine is allocated 512 MB of memory, 100 virtual desktops require 50 GB (100 x 512 MB) out of the 402 GB.

Thin provisioning

The virtual hard disk provided to virtual desktops from the FC LUN is thin provisioned. This enables users to control storage costs, provide a higher level of utilization, and eliminate storage waste and the need for dedicated storage capacity.

http://support.citrix.com/article/CTX124799

http://support.citrix.com/article/CTX124799

Best practices

Disk drives The general recommendations for disk drives are:

Drives with higher revolutions per minute (RPM) provide higher overall

random-access throughput and shorter response times than lower rpm drives. For optimum performance, higher RPM drives are recommended for storing the file systems that house the virtual desktops.

FC drives are preferred over Serial Advanced Technology Attached (SATA) drives because FC drives provide better performance than SATA drives.

Enterprise Flash Drives (EFDs) could have been considered for their performance, efficiency, power, space, and cooling requirements. However, they increase the cost drastically. As technology cost tends to reduce over the course of time, EFD can be used in such solutions in the near future.

RAID 1 compared to RAID 5

The I/O loads generated by virtual desktops are characterized as small, random, or write-intensive I/O. A workload is considered write-intensive when it consists of greater than 30 percent of random writes. In such a random workload, RAID 1 offers better performance than RAID 5 because of the write penalty that RAID 5 incurs when the parity bit is calculated for every write operation. Since RAID 1 does not calculate parity, it does not suffer a similar penalty when writing data.


21


22

Chapter 4: Network Design

Overview

Introduction This chapter describes the network design of Citrix XenDesktop 4 in the VDI

solution.


Topic See Page

Overview 22 Considerations 22 Network layout 23 Virtual LANs 23 High availability network 24

Considerations

Introduction Two types of network connections were configured in this solution, Fibre Channel

(FC) and Internet Protocol (IP). FC connections were established between the Windows Server 2008 R2 Hyper-V hosts and the Celerra NS-120 unified storage platform to allow the Hyper-V hosts to access the FC LUNs stored on the Celerra. Gigabit Ethernet (GbE) and virtual local area network (VLAN) IP connections were designed to eliminate network bottlenecks and provide maximum performance over a secured network.

Physical design considerations

EMC recommends that the network switches support gigabit Ethernet (GbE) connections and Link Aggregation Control Protocol (LACP), and that the ports on the switches support copper-based media.

Logical design considerations

This validated solution uses virtual local area networks (VLANs) to segregate network traffic of various types to improve throughput, manageability, application separation, high availability, and security. The IP scheme for the virtual desktop network must be designed in such a way that there are enough IP addresses available in one or more subnets for the DHCP server to assign them to each virtual desktop.

Link aggregation

The Celerra unified storage platform provides network high availability and redundancy by using link aggregation. This is one of the methods to deal with the problem of link or switch failure.

Link aggregation is a high availability feature that enables multiple active Ethernet connections to appear as a single link with a single MAC address and multiple IP addresses. In this solution, link aggregation applied on the Celerra combines two GbE ports into a single virtual device. If a link is lost on one Ethernet port, the link fails over to the other port. All traffic is distributed across the active links.

FC switch consideration

The Windows 2008 R2 Hyper-V servers consist of two FC HBA ports that are connected to the Celerra NS-120 unified storage platform via FC switches in a SAN fabric. Zoning is configured on the switch to regulate the connections between the Hyper-V servers and Celerra NS-120. EMC recommends WWN-based zoning, by which access is controlled using WWNs. EMC also recommends single initiator zoning, by which a single HBA port of the Hyper-V server is connected to one or more storage ports.

Network layout

Network layout for the validated scenario

The network layout implements the following physical connections: FC provides SAN connectivity between Windows Server 2008 R2 Hyper-V hosts

and the Celerra unified storage system. GbE with TCP/IP provides network connectivity. NIC teaming on Windows Server 2008 R2 Hyper-V hosts along with link

aggregation on Data Mover provide load-balancing and failover capabilities. Virtual desktop machines running on Windows Server 2008 R2 Hyper-V hosts are

connected to the production network. Dedicated network switches and VLANs are used to segregate production and

other networks.

Virtual LANs

Production VLAN

The production VLAN is used for end users to access virtual desktops, Citrix XenDesktop components, and associated infrastructure servers such as DNS, Active Directory, and DHCP. Virtual desktops also use this VLAN to access a Celerra TFTP server for the PXE boot image.

Other considerations

In addition to VLANs, separate redundant network switches for storage can be used. It is recommended that these switches support GbE connections, jumbo frames, and port channeling.


23


24

High availability network

Link aggregation on the Data Mover

LACP is enabled with two GbE ports available on the Data Mover. To configure the link aggregation that uses two ports of the Ethernet NIC on server_2, type: $ server_sysconfig server_2 -virtual -name <Device Name> -create trk –option "device=cge0,cge2 protocol=lacp" To verify if the ports are channeled correctly, type: $ server_sysconfig server_2 -virtual -info lacp0 server_2 : *** Trunk lacp0: Link is Up *** *** Trunk lacp0: Timeout is Short *** *** Trunk lacp0: Statistical Load C is IP *** Device Local Grp Remote Grp Link LACP Duplex Speed -------------------------------------------------------------- cge0 10000 1280 Up Up Full 1000 Mbs cge2 10000 1280 Up Up Full 1000 Mbs The remote group number for both cge ports needs to match and the LACP status must be “Up”. Confirm if the appropriate speed and duplex are established as expected.

NIC teaming on the Windows 2008 R2 Hyper-V server

NIC teaming is configured to provide highly available network connectivity to the Windows 2008 R2 Hyper-V server. If Intel NICs are installed, run the following command to create a two-port NIC team that uses the Virtual Machine Load Balancing (VMLB) algorithm. C:\Program Files\Intel\DMIX\CL>PROSetCL.exe team_create 1,2 Team1 VMLB Refer to the third-party vendor documentation for NIC teaming configuration detail.

Chapter 5: Installation and Configuration

Overview

Introduction This chapter provides procedures and guidelines for installing and configuring the

components that make up the validated solution scenarios. It is not intended to be a comprehensive step-by-step installation guide, and highlights only configurations that pertain to the validated solution.

Scope The installation and configuration instructions presented in this chapter apply to the

specific revision levels of components used during the development of this solution. Before attempting to implement any real-world-based solution on this validated scenario, gather the appropriate installation and configuration documentation for the revision levels of the hardware and software components used in this solution.


Topic See Page Overview 25 Task 1: Set up and configure the NFS datastore 26 Task 2: Install and configure Desktop Delivery Controller 26 Task 3: Install and configure Provisioning Server 32 Task 4: Configure and provision the master virtual machine template

45

Task 5: Deploy virtual desktops 45


25


26

Task 1: Set up and configure the FC LUNs

Configure the Windows 2008 R2 Hyper-V servers to access the FC LUNs

To prepare each Windows 2008 R2 Hyper-V server to access the shared FC LUNs as cluster shared volumes (CSV), complete the following steps:

Step Action 1 Install the following components on the Windows servers:

Fibre Channel HBA driver and utility Navisphere Agent PowerPath

2 Enable Failover Clustering features in Windows 3 Provision LUNs on the array and present them to the hosts 4 Configure Fibre Channel switch zoning 5 Quick format the FC LUNs using NTFS formatting 6 Add the newly formatted volumes to the shared storage in failover

clustering 7 Convert the shared storage into CSV

Task 2: Install and configure Desktop Delivery Controller

Database server

Microsoft SQL Server 2005 Enterprise Edition is installed on a dedicated Windows Server 2003 virtual machine to host the databases required to store the configurations for the following three components — Desktop Delivery Controller, Provisioning Server, and SCVMM Server. Use the following options when configuring SQL Server: Configure Windows Authentication Mode as the SQL Server’s Authentication

Mode. Provide a custom SQL Server instance name or use the default instance name. Provide this SQL Server name and instance name as Database Server options

while installing the Provisioning Server.

Note: The Provisioning Server installation CD comes with Microsoft SQL Server 2005 Express Edition. However, the databases on Express Edition may not offer the scalability required for the Provisioning Server, Desktop Delivery Controller, and SCVMM Server.

Install SCVMM Administrator Console

The DDC has to communicate with the SCVMM server to manage Hyper-V virtual machines. Prior to installing the DDC software, it is recommended to install the SCVMM administrator console so the DDC setup wizard will automatically install the SCVMM plugin that is required when creating a desktop group using Microsoft Virtualization as the hosting infrastructure. If the SCVMM administrator console is installed after the DDC software is installed, then the plugin must be manually added to the Citrix Pool Management service. Follow these steps to add the SCVMM plugin manually.

Step Action

1 On the DDC, open the Control Panel and click Add/Remove Programs.

2 Select Citrix Pool Management, and click the Change button. The Welcome to the Citrix Pool Mangement Setup Wizard dialog appears.

3 Click Next. The Modify, Repair or Remove Installation dialog

appears.


27

4 Click Modify. The Custom Setup dialog appears.

5 Select the Microsoft SCVMM plugin option and choose Will be

installed on local hard drive option. Click Next. The Ready to Install dialog appears.


28

6 Click Install. After the Microsoft SCVMM plugin is successfully installed, the Completing the Citrix Pool Management Setup Wizard dialog appears.

7 Click Finish.

Install Desktop Delivery Controller

On the virtual machine designated as the first Desktop Delivery Controller, install the following components from the Citrix DDC installation CD (or ISO): Citrix Desktop Delivery Controller Citrix Management Console Citrix License Server Select Create new farm from the Create or Join a Farm dialog. To use an external SQL server, select Use an existing Database Server for the Optional Server Configuration dialog box of the installation wizard. The Database Configuration dialog box appears, as shown in the figure below. Select the Database server type as SQL Server. Click the Configure button to configure the ODBC connection to the SQL Server database.


29

Configure additional Desktop Delivery Controllers

To install additional Desktop Delivery Controllers, select the Citrix Desktop Delivery Controller component from the installation CD (or ISO). Select Join existing Farm and type the name of the first DDC in the Type the name of the first controller in the farm dialog.


30

Throttle commands to SCVMM server

By default, the DDC Pool Management service will attempt to start 10 percent of a desktop pool size. It may be necessary to throttle the number of concurrent requests sent to the vCenter Server and not to overwhelm the VMware infrastructure. To modify the number of concurrent requests, edit the following configuration on each DDC:

1. Open the CDsPoolMgr.exe.config file from C:\Program Files (x86)\Citrix\VmManagement\ using a text editor such as Notepad.

2. Add the MaximumTransitionRate parameter on a new line and set the

value to the required number of concurrent requests. A value of 20 is used in this solution.

<?xml version="1.0" encoding="utf-8" ?>

<configuration> <appSettings>

<add key="LogToCdf" value ="1"/> <add key=”MaximumTransitionRate” value=”20”/>

</appSettings> </configuration>

3. After saving the file, restart either the DDC or the Citrix Pool Management

Service for the change to take effect.

Virtual desktop idle pool settings

The DDC manages idle virtual desktops based on time, and automatically optimizes the idle pool settings in the desktop group based on the number of virtual desktops in the group. These default idle pool settings need to be adjusted according to customer requirements to have virtual machines powered on in advance to avoid a boot storm scenario. During validation testing, the idle desktop count is set to match the number of desktops in the group to ensure that all desktops are powered on in a steady state and ready for client connections. To change the idle pool settings after a desktop group is created:

1. Navigate to Start > All Programs > Citrix > Management Consoles > Delivery Services Console on the DDC.

2. In the left pane, navigate to Citrix Resources > Desktop Delivery Controller > <XenDesktopFarmName> > Desktop Groups

3. Right-click the desktop group name and select Properties. 4. Select Idle Pool Settings in the left pane under the Advanced option. 5. In the Idle Desktop Count section in the right pane, modify the number of

desktops to be powered on during Business hours, Peak time, and Out of hours. You can optionally redefine business days and hours per your business requirements.

6. Click OK to save the settings and close the window.


31

Task 3: Install and configure Provisioning Server

Install Provisioning Server

Unlike the Citrix Desktop Delivery Controller, the installation process for the Provisioning Server is identical for the first Provisioning Server in the desktop farm and any additional Provisioning Servers installed in the farm. Run the Provisioning Services Configuration Wizard after the installation of the Provisioning Services software. The configuration options differ between the first and secondary (or additional) Provisioning Servers. The following steps highlight the configuration wizard options customized for this solution.


32

Provisioning Server – DHCP services

Since the DHCP services run on a dedicated DHCP server, select The service that runs on another computer for DHCP services when configuring the DHCP services in the configuration wizard. Click Next.


33

Provisioning Server – PXE services

The Provisioning Server is not used as a PXE server because DHCP services are hosted elsewhere. Select The service that runs on another computer for PXE services when configuring the PXE services in the configuration wizard. Click Next.


34

Provisioning Server – Farm configuration

From the Farm Configuration page of the Configuration Wizard, select Create farm to configure the first Provisioning Server or Join existing farm to configure additional Provisioning Servers. With either option, the wizard will prompt for a SQL server and its instance. First, Provisioning Server will use these inputs to create a database to store the configuration details of the Provisioning Server. Additional Provisioning Servers use these inputs to retrieve information about existing farms from the database. Click Next.


35

Provisioning Server – User account

Because the master desktop vDisk is stored on a local drive on each Provisioning Server, select Local system account (Use with SAN) as the user account to run the stream and soap services on the Provisioning Servers. Click Next.


36

Provisioning Server – Stream services

Select the appropriate network card for the stream services from the Available network cards pane. Use the default values for the First port, Last port, and Soap server port used for Console access fields. Click Next.


37

Provisioning Server – TFTP

Because the TFTP server is hosted on the Celerra, clear the Use the Provisioning Services TFTP service. Click Next.


38

Inbound communication

Each Provisioning Server maintains a range of User Datagram Protocol (UDP) ports to manage all inbound communications from the virtual desktops. The values of 21 ports, and eight threads per port may not support a large number of virtual desktops in this validated solution. The total number of threads supported by a Provisioning Server is calculated as: Total threads = (Number of UDP ports * Threads per port * Number of network adapters) Ideally, there should be one thread dedicated for each desktop session. The number of UDP ports is increased to 64 (port range of 6910 to 6973) and the number of threads per port is increased to 10 on each Provisioning Server (PVS) (64 * 10 * 1 NIC = 640 threads per server) to accommodate up to 1,000 desktops. The number of UDP ports can be modified in the Network tab of the Server Properties dialog box (as shown in the following figure). The Server Properties dialog box appears when you double-click a Provisioning Server in the Provisioning Services Console. The threads per port parameter can be modified by using the Advanced option.


39

By default the Citrix PVS two-stage boot service uses port 6969. Since this solution does not require this service, the two-stage boot service is disabled to avoid conflict, and it enables the UDP port to range up to 6973. It is a best practice to maintain the same server properties among all PVS servers. In particular, all servers must have the same port range configured.

Sharing the Master vDisk via Pass-through Disk

The Master vDisk is stored on a LUN that is shared among the PVS servers. Since each PVS run as a virtual machine, the LUN can be presented to the PVS VMs via a Hyper-V pass-through disk as shown in the figure below. The pass-through disk is added via SCSI controller, which allows the virtual disk to be hot swappable. The Master vDisk is not hot swappable if it is configured with an IDE controller.

Disk align virtual disk

For better performance, it is recommended to align the virtual disk of the Provisioning Server and other virtual machines. For Windows 2003 virtual machines, disk alignment is done by using the diskpart.exe tool. Select the appropriate disk in the DISKPART prompt and type the following command to align the partition with 1024 KB offset: DISKPART> create partition primary align=1024


40

Citrix XenConvert is used when the golden image of the master virtual machine is cloned to the master vDisk. Provisioning Services 5.1 contains XenConvert 2.0.x. XenConvert 2.0.x fixes the partition offset at 252 KB, which causes disk misalignment. XenConvert version 2.1 or later contains an option to specify the desired offset to align the disk correctly. Locate the XenConvert.ini file in the same location as the XenConvert executable. To set the offset to 1024 KB, add the following section and the value to the file: [parameters] PartitionOffsetBase=1048576 To specify the offset manually, upgrade Xenconvert to the latest version.

vDisk access mode

After the golden image of the master virtual machine is cloned to the master vDisk, the Access Mode must be changed from Private Image to Standard Image to enable virtual desktops to share the common vDisk. Thereafter, the vDisk becomes read-only, and virtual desktop changes are redirected to a write cache area. In this solution, the write cache type is set to Cache on device’s HD to ensure that each virtual desktop uses its own VHD to store the write cache.


41

Read only NTFS volume with vDisk

Modifying the master vDisk access mode to Standard Image changes the underlying VHD file to write-protected because the golden image is sealed. As a result, the NTFS volume that is used to host the vDisk can be made read-only such that it can be shared across other Provisioning Servers without the need of a clustered file system to handle any file locking issues. Read-only access to the NTFS volume is enabled by using the diskpart command. Run this command from the command prompt, select the target volume, and type: DISKPART> attributes volume set readonly After setting the read-only attribute, the NTFS volume needs to be remounted for the read-only flag to take effect. Since the PVS runs as a virtual machine this can be done by removing and adding the virtual disk from the Virtual Machine Properties screen. When the virtual machine is powered on, the add/remove operations are available in vSphere 4 only.

Configure a bootstrap file

The bootstrap file required for the virtual desktops to PXE boot is updated using the Configure Bootstrap option. This option is available in the Provisioning Services Console (Farm > Sites > Site-name > Servers). The Configure Bootstrap dialog box is shown in the following figure.

After the new PVS is added to the server farm, the bootstrap image must be updated to reflect the IP addresses used for all PVS servers that provide streaming services, in a round-robin fashion. The list of PVS servers can be obtained by either clicking Read Servers from Database or by manually adding the server information by clicking Add.


42

When modifying the configuration, click OK to update the ARDBP32.BIN bootstrap file, which is located at C:\Documents and Settings\All Users\Application Data\Citrix\Provisioning Services\Tftpboot. Navigate to the folder and examine the timestamp of the bootstrap file to ensure that the bootstrap file is updated on the intended Provisioning Server.

Copy the bootstrap file to the TFTP server on Celerra

In addition to serving FC LUNs, EMC Celerra unified storage is used as a TFTP server that provides a bootstrap image when virtual desktops PXE boot. To configure the Celerra TFTP server, complete the following steps:

Step Action 1 Enable the TFTP service by using the following command:

server_tftp <movername> -service –start

2 Set the TFTP working directory and enable read/write access for file transfer by using the following command syntax. It is assumed that the path name references to a file system created in RAID group 0 as shown in Disk layout for 10 building blocks on page 17. server_tftp <movername> -set -path <pathname> -readaccess all –writeaccess all

3 Use a TFTP client, of your choice, to upload the ARDBP32.BIN bootstrap file from C:\Documents and Settings\All Users\Application Data\Citrix\Provisioning Services\Tftpboot on the Provisioning Server to the Celerra TFTP server.

4 Set the TFTP working directory access to read-only to prevent accidental modification of the bootstrap file by running the following command:

server_tftp <movername> -set -path <pathname> –writeaccess none


43

Configure boot options 66 and 67 on the DHCP

In order for the virtual desktops to PXE boot successfully from the bootstrap image supplied by the Provisioning Servers, the DHCP server must have boot options 66 and 67 configured. To configure boot options 66 and 67 on the DHCP, complete the following steps:

Step Action 1 On the installed Microsoft DHCP server, select Scope Options. 2 Select 066 Boot Server Host Name. 3 Enter the IP address of the Data Mover configured as the TFTP server

in the String value box. 4 Enable 067 Bootfile Name and enter ARDBP32.BIN in the String

value field. The ARDBP32.BIN bootstrap image is loaded on a virtual desktop before the vDisk image is streamed from the Provisioning Server.


44

Task 4: Configure and provision the master virtual machine template

Create a virtual machine as a template for virtual desktops

To create a virtual machine to use as a template for the virtual desktops, use the Create New Virtual Machine wizard. This validated solution uses Microsoft Windows XP (32-bit edition) as the virtual desktop guest operating system. Ensure that the base virtual machine is allocated with one vCPU, 512 MB system RAM, and an emulated network adapter that uses a legacy driver. Emulated network adapter is chosen as opposed to synthetic adapter because when a desktop PXE boots to retrieve the desktop image from the PVS, a synthetic adapter cannot be used at that stage until the guest operating system is completely booted up. Creating a new virtual machine with a network adapter by default creates a synthetic network adapter. The synthetic adapter must be removed after the VM is created, and an emulated or legacy adapter needs to be added.

“New hardware found” message

When the virtual hard disk is attached to the master vDisk as a write-cache drive for the first time, Windows will detect the drive as new hardware and prompt for a reboot as soon as a virtual desktop session begins. To avoid such a reboot, attach the virtual hard disk to the master virtual machine before its image is cloned to the vDisk, such that the vDisk image contains the disk signature that will be recognized when the virtual desktops are started.

Task 5: Deploy virtual desktops

Install SCVMM Administrator Console

Prior to running XenDesktop Setup Wizard on the PVS to provision virtual desktops, the SCVMM Administrator Console needs to be installed to ensure the PVS can communicate with the SCVMM server.

Default virtual machine placement

When a Windows Server 2008 R2 Hyper-V server is added to the SCVMM to be managed, be sure to specify the CSV paths as the default virtual machine placement locations. Otherwise, the default behavior is to create the virtual machines on the local drive.


45

XenDesktop Setup Wizard

The XenDesktop Setup Wizard installed on the Provisioning Server simplifies virtual desktop deployment, and can rapidly provision a large number of desktops. To run this wizard, complete the following steps:

Step Action 1 Select Start > All Programs > Citrix > Administration Tools >

XenDesktop Setup Wizard on the Provisioning Server. The Welcome to XenDesktop Setup Wizard page appears. Click Next.

2 When the Desktop Farm page appears, select the relevant farm name from the Desktop farm list. The list of farms appears. Click Next.

3 On the Hosting Infrastructure page, select Microsoft virtualization


46

as the hosting infrastructure. Type the IP address or host name of the SCVMM Server. Click Next.

Note: You will be prompted to specify the user credentials for the SCVMM Server.

4 On the Virtual Machine Template page, select the virtual machine that you want to use as a template for the virtual desktops. These virtual machines are retrieved from the SCVMM Server. Click Next. The Virtual Disk (vDisk) page appears.


47

5 Select the vDisk from which the virtual desktops will be created. Only vDisks in standard mode appear. As shown in the following figure, the list of existing device collections contains only the device collections that belong to the same site as the vDisk. Click Next. The Virtual Desktops page appears.

6 Enter the following and click Next.

The number of desktops to create. The common name to use for all the desktops. The start number to enumerate the newly created desktops.

The sequence of this number will be appended to the common name, and will be assigned to the virtual desktop names.

The Organizational Unit Location page appears.


48

7 Select the OU to which the desktops will be added and click Next.

The Desktop Group page appears.

8 Specify the group of the Desktop Delivery Services to which to add the desktops and click Next.

The Desktop Creation page appears.

9 Ensure that the details are correct and then click Next to create the desktops.


49

The Summary page appears. Note: Clicking Next will start creating desktops and computer objects in the Active Directory. This process is irreversible.

Attaching write-cache drives

Although XenDesktop Setup Wizard creates VMs according to the template VM, it will not attach any drives to the new VMs. All write-cache drives (VHD files) need to be added after the desktops are created. The SCVMM Server can be used to create the write-cache drive and attach it to the virtual machines. Powershell scripts can be used to automate this process for all 1,000 VMs. For more information about the Powershell scripts, refer to the Citrix blog post at http://community.citrix.com/display/ocb/2010/04/29/PowerShell+Scripts+for+XenDesktop+Part+2.


50

Chapter 6: Testing and Validation

Overview

Introduction This solution for Citrix XenDesktop 4 on EMC Celerra explores several

configurations that can be used to implement a 1,000-user environment using EMC Celerra.

Contents This section contains the following topics:

Topic See Page

Overview 51 Testing overview 51 Testing tools 51 Test results 53 Result analysis of Desktop Delivery Controller 54 Result analysis of Provisioning Server 58 Result analysis of the vCenter Server 62 Result analysis of SQL Server 64 Result analysis of ESX servers 68 Result analysis of Celerra unified storage 73 Login storm scenario 82 Test summary 84

Testing overview

Introduction This chapter provides a summary and characterization of the tests performed to

validate the solution. The goal of the testing was to characterize the end-to-end solution and component subsystem response under reasonable load for Citrix XenDesktop 4 with a Celerra NS-120 over FC.

Testing tools

Introduction To apply a reasonable real-world user workload, a third-party benchmarking

tool — LoginVSI from Login Consultants was used. LoginVSI simulates a VDI workload using the AutoIT script on each desktop session to automate the execution of generic applications like Microsoft Office 2007, Internet Explorer, Adobe Acrobat Reader, Notepad, and other third-party software.


51


52

LoginVSI – Test methodology

Virtual Session Index (VSI) provides guidance to gauge the maximum number of users a desktop environment can support. LoginVSI workloads can be categorized as light, medium, heavy, and custom. Medium is the only workload that is available in the VSI Express (free edition) and Pro editions. VSI Pro edition and a medium workload were chosen for testing this solution. They have the following characteristics: Emulate a medium knowledge worker using Office, Internet Explorer, and Acrobat

Reader. Once a session is started, the medium workload will repeat every 12 minutes. The response time is measured every 2 minutes during each loop. The medium workload opens up to five applications simultaneously. The type rate is 160 ms for each character. The medium workload in VSI 2.0 is approximately 35 percent more

resource-intensive than VSI 1.0. Approximately 2 minutes of idle time is included to simulate real-world users. Each loop of the medium workload will open and use: Outlook 2007: Browse 10 messages. Internet Explorer: One instance is left open (BBC.co.uk). One instance is opened

to Wired.com, Lonelyplanet.com, and the heavy flash app, gettheglass.com (not used with MediumNoFlash workload).

Word 2007: One instance to measure response time and one instance to review and edit the document.

Bullzip PDF Printer and Acrobat Reader: The Word document is printed, and the PDF is reviewed.

Excel 2007: A very large, randomized spreadsheet is opened. PowerPoint 2007: A presentation is reviewed and edited. 7-zip: Using the command line version, the output of the session is zipped. The current LoginVSI version is 2.1.2. This version has a gating metric called VSImax that measures the response time of five operations:

1. Maximizing Microsoft Word. 2. Starting the File Open dialog box. 3. Starting the Search and Replace dialog box. 4. Starting the Print dialog box. 5. Starting Notepad.

The LoginVSI workload is gradually increased by starting desktop sessions one after another at a specified interval. Although the interval can be customized, the default interval of 1 second is used during the testing. The desktop infrastructure is considered saturated when the average response time of three consecutive users crosses the 2,000 ms threshold. The administrator guide available at www.loginconsultants.com provides more information on the LoginVSI tool.

LoginVSI launcher

A LoginVSI launcher is a Windows system that launches desktop sessions on target virtual desktop machines. There are two types of launchers — master and slave. There is only one master in a given test bed, but there can be as many slave launchers as required. Launchers coordinate the start of the sessions using a common CIFS share. In this validated testing, the share is created on a Celerra file

http://www.loginconsultants.com/

system that resides in the 4+1 RAID 5 group as shown in Disk layout for 10 building blocks on page 17. The number of desktop sessions a launcher can run is typically limited by CPU or memory resources. Login Consultants recommends using a maximum of 45 sessions per launcher with two CPU cores (or two dedicated vCPUs) and 2 GB of RAM when the GDI limit has not been tuned (default). If the GDI limit has been tuned, this limit extends to 60 sessions per two-core machine. In this validated testing, 1,000 desktop sessions were launched from 48 launchers, resulting in 20 or 21 sessions established per launcher. Each launcher is allocated two vCPUs and a 4 GB of RAM to prevent any system bottlenecks.

Test results

Result summary

The following graph shows the response time compared to the number of active desktop sessions, as generated by the LoginVSI launchers. It shows that the average response time increases marginally as the user count increases. Throughout the test run, the average response time hovers around 500 ms, which is significantly lower than the 2,000 ms gating metric. The maximum response time increases nominally as the user count increases, with some spikes. However, it never exceeds 7,000 ms.


53

Result analysis of Desktop Delivery Controller

Introduction Since the two DDCs are load balanced to host 1,000 desktops, their performance

counters are comparable. As a result, only the statistics for the first DDC are reported in the following sections.

CPU utilization The average percentage processor time is recorded at 9.99 percent with occasional

spikes that reach as high as 68 percent. The percentage processor time is reported based on the average of two vCPUs.


54

Memory utilization

Each DDC virtual machine was configured with 4 GB of RAM. The memory utilization fluctuates between 1.3 GB and 1.8 GB; however, the utilization exceeds 4 GB towards the end of the test as a result of concurrent user logoff. The average utilization is around 1.5 GB, consuming less than half of the available memory.


55

Disk throughput

A Windows operating system and XenDesktop software were installed on a local drive for each DDC. As seen in the following graph, despite spikes occurring at the end of the test due to concurrent user logoff, the average disk throughput is about 12.6 KB/s at the end of the test run.


56

Network throughput

Each DDC virtual machine was configured with a gigabit Ethernet adapter that uses a synthetic network adapter to manage the virtual desktops. An average transfer rate of 270 KB/s translates to 2.2 Mb/s. A surge of 1009 KB/s (or 8.1 Mb/s) was measured at the end of the test run due to concurrent users logging off.


57

Result analysis of Provisioning Server

Introduction Since the two PVSs are load balanced to host 1,000 desktops, their performance

counters are comparable. As a result, this section covers only the statistics for the first PVS.

CPU utilization Two vCPUs were configured for each PVS server that communicates with 500

desktops. The following graph validates that the two-CPU virtual machine is sufficient. The average percentage processor time is recorded at 6.81 percent with spikes at the end of the test that reach as high as 89 percent due to concurrent user logoff. The percentage processor time is reported based on the average of two vCPUs.


58

Memory utilization

Each PVS virtual machine was configured with 4 GB of RAM. The memory utilization remains steady in the range of 1.2 GB to 1.3 GB.


59

Disk throughput

The following graph shows the disk throughput measured for the physical disk that stores the master vDisk. Since the PVS servers cache the vDisk data blocks in memory, the initial read activity is observed at 1.9 MB/s. Negligible disk activity is observed thereafter.


60

Network throughput

Each PVS virtual machine was configured with a gigabit Ethernet adapter that uses a synthetic network adapter to stream the vDisk image to virtual desktops. The average network throughput is recorded at 3.67 MB/s (or 29.4 Mb/s). The maximum network throughput is capped below 48 MB/s (or 384 Mb/s) towards the end of the run despite a spike in activity as a result of concurrent user logoff.


61

Result analysis of the SCVMM Server

Introduction The SCVMM Server maintains a cluster of 16 Windows 2008 R2 Hyper-V servers

that host a total of 1,000 desktop virtual machines.

CPU utilization The SCVMM Server virtual machine is configured with four vCPUs. The average

CPU utilization is less than 9 percent throughout the test. Periodic surges hover around 75 percent while the logoff storm towards the end of the run momentarily catapults the utilization to as high as 100 percent.


62

Memory utilization

4 GB of RAM were allocated to the SCVMM Server virtual machine. Committed bytes seldom exceed 3 GB.

Disk throughput

A Windows operating system and SCVMM Server software were installed on an FC LUN. There is minimal disk I/O activity as seen in the following graph.


63

Network throughput

The SCVMM Server was configured with a gigabit Ethernet adapter that uses a synthetic network adapter. The majority of the network activity comes from the DDCs that manipulate and detect the state of each virtual desktop. The average network throughput is measured at 1101 KB/s (or 8.8 Mb/s). Logoff activity towards the end of the run triggers a spike of 7679 KB/s (or 61.4 Mb/s).

Result analysis of SQL Server

Introduction Three databases were created on the SQL server, which is the central repository of

the DDC, PVS, and SCVMM Server configurations. The database size for the SCVMM Server grows to nearly 2 GB — the largest of the three databases. The DDC and PVS databases require 10 MB and 5 MB, respectively.


64

CPU utilization The SQL Server virtual machine was configured with dual vCPUs. The average CPU

utilization is less than 9 percent throughout the test. Periodic surges are curbed at 41 percent.


65

Memory utilization

4 GB of RAM were allocated to the SQL Server virtual machine. Committed bytes were steady around 3.2 GB, increasing towards the end, but never exceeding 3.7 GB.


66

Disk throughput

A Windows operating system and SQL Server software were installed on an FC LUN. The average disk throughput is about 73 KB/s, while the maximum throughput is recorded around 2.2 MB/s, towards the end of the test during logoff storm.


67

Network throughput

The SQL server was configured with a gigabit Ethernet adapter that uses a synthetic network adapter. The average network throughput is measured at 328 KB/s (or 2.65 Mb/s). The maximum throughput is recorded at 6239 KB/s (or 50 Mb/s).

Result analysis of Windows 2008 R2 Hyper-V servers

Introduction 1,000 virtual machines are spread among 16 Windows 2008 R2 Hyper-V servers.

Each server is responsible for hosting 61 to 62 virtual machines. Because each Windows server hosts almost the same number of virtual machines, the performance counters are sampled from one of the 16 servers.


68

CPU utilization Each of the 16 Windows Hyper-V servers has eight Intel Xeon 2.53 GHz CPUs.

Each server hosts up to 62 desktop virtual machines, yielding a VM/core ratio of 7.75. As the workload gradually increases when more desktops become active during the test, CPU utilization grows linearly and reaches a maximum of 100 percent towards the end of the test run. Sessions begin to log off simultaneously, triggering a surge in CPU utilization.


69

Memory utilization

Each of the 16 Windows 2008 R2 Hyper-V servers has 48 GB of memory installed. Memory utilization remains steady throughout the test at 40 GB.


70

Disk throughput

Each of the 16 Windows 2008 R2 Hyper-V servers is configured with one internal hard disk and 10 FC LUNs that are configured as cluster shared volumes (CSV). There is a nominal disk I/O targeted to the internal drive as the majority of I/O operations are redirected to the FC LUN.


71

Network throughput

Each of the 16 Windows 2008 R2 Hyper-V servers is configured with NIC teaming on two 10-gigabit adapters to provide high availability. The following graph shows that the network utilization continues to increase as desktop sessions are ramped up. Despite the spike in network utilization towards the end of the test run, the maximum throughput of 90 Mb/s is well below the physical limit of the aggregated 10-gigabit network bandwidth.


72

Result analysis of Celerra unified storage

Celerra Data Mover stats

The Celerra command server_stats with the following syntax was used to collect the performance data of the Data Mover every 15 seconds.

$ /nas/bin/server_stats <server_name> -summary basic,caches -table net,dvol,fsvol -interval 15 -format csv -titles once -terminationsummary yes

The following table provides some of the significant Data Mover statistics that were collected:

Measurement parameter Average value Network input 217 KB/s ( 0.211 MB/s) Network output 171 KB/s (0.16 MB/s) Dvol read 67 KB/s (0.06 MB/s) Dvol write 161 KB/s (0.15 MB/s) Buffer cache hit rate 99.98% CPU utilization 2.4%

Data Mover CPU utilization

Despite the gradual increase in the CPU utilization on the Data Mover and the increase in the test workload, the CPU utilization remains below 10 percent until the end of the test run when the logoff storm causes a spike of 28 percent.


73

Data Mover disk throughput

The following graph shows the trend of the disk throughput measured on the Data Mover. Its pattern mimics the CPU utilization trend as the disk throughput gradually increases and reaches a maximum of 7.5 MB/s.


74

Storage array CPU utilization

The CLARiiON Analyzer GUI was started to collect performance data about the storage array at 60-second intervals. The following graph shows the CPU utilization at the storage processor (SP) level. The SP balances LUN ownership for the 10 building blocks that are used to store the virtual desktops. However, because SP A also owns the LUNs that store the golden vDisk image, and the CIFS file system that contains the roaming user profiles and LoginVSI results, additional CPU cycles are incurred on SP A.This causes its maximum CPU utilization to reach nearly 50 percent, while SP B reaches a maximum utilization of 46 percent.


75

Storage array total bandwidth

The storage array can easily handle the I/O bandwidth that the test workload generates, where less than 24 MB/s of I/O bandwidth is observed for each SP.


76

Storage array total throughput

The maximum aggregated throughput at the SP level is recorded at 6,372 IOPS (3648 + 2724) towards the end of the test run. This number includes all I/O activities for this storage array. Throughput measured for the virtual desktops alone is reported below the LUN level.


77

Storage array response time

The SP response time throughout the test run is less than 1 millisecond — an acceptable response time that suggests that the storage processor is not a bottleneck.


78

Most active LUN utilization

The following four graphs show the performance statistics for the busiest LUN. This is measured within the 10 building blocks used to store the virtual desktops. The maximum utilization for the most active LUN never exceeds 40 percent as shown in the following graph.


79

Most active LUN bandwidth

The maximum LUN bandwidth is measured at 3.67 MB/s for the most active LUN during the test. The storage array can easily handle the bandwidth requirement.


80

Most active LUN throughput

The maximum throughput measured for the most active LUN is slightly below 500 IOPS. Because the storage array write-cache absorbs some of the front-end IOPS before it writes to the physical disks, the LUN throughput can exceed the theoretical limit of what two 15k drives can yield in a building block.


81

Most active LUN response time

The response time during the steady state for the most active LUN is around 1 millisecond throughout the test run, which suggests that there is no bottleneck at the LUN level.

Login storm scenario

Introduction One of the areas of greatest concern in VDI implementation is the what-if scenarios

of login and boot storms. Given that the DDC has an option to adjust the idle desktop count, it is recommended to tune the parameter accordingly to power up enough virtual desktops ahead of business opening/peak hours and alleviate a boot storm scenario. The impact of login storm, on the other hand, may be minimized by keeping desktop users logged in as long as possible. However, this is beyond the control of the desktop administrators. The following section prepares for the worst-case scenario when logins occur in rapid succession.


82


83

Login timing To simulate a login storm, 500 desktops are powered up into a steady state by

setting the idle desktop count to 500. The login time of each session is then measured by starting a LoginVSI test that establishes the sessions with a custom interval of five seconds. The 500 sessions are logged in within 42 minutes (500 x 5 / 60 = 41.6), a period that models a surge of login activity that takes place in the opening hour of a production environment. The LoginVSI tool has a built-in login timer that measures from the start of the logon script defined in the Active Directory group policy, to the start of the LoginVSI workload for each session. Although it does not measure the total login time from an end user perspective, the measurement gives a good indication of how sessions will be affected in a login storm scenario. The following graph shows the trend of the login time in seconds as sessions are started in rapid succession. The average login time for 500 sessions is approximately 6 seconds. The maximum login time is recorded at 9 seconds, while minimum login time is around 4 seconds. It is concluded that while a very few desktop users might experience a slightly longer login delay during login storm, most users should receive their desktop sessions with a reasonable delay.


84

Test summary

Summary The following conclusions can be drawn from the tests:

RAID 1 is the preferred RAID type over RAID 5 in a XenDesktop 4 deployment due

to the write-intensive nature of the PVS write cache area. The recommended number of 100 desktops per two-disk RAID 1 building block is

based on the medium workload generated by LoginVSI. Individual sizing requirements must be calibrated based on both the capacity planning and workload characteristics of a production environment.

The ratio of 7.75 virtual machines per CPU core measured in the test should be used as a guideline for sizing. It would be wise to scale back on this ratio or reduce each user workload to reserve headroom for unforeseen overloaded activity such as boot storm.

Boot and login/logoff storms need to be taken in consideration when sizing a VDI implementation. While XenDesktop 4 has an option to cope with boot storm, care should be taken to monitor the environment to minimize the impact of potential login/logoff storm.