Desktop virtualisation – how to build scalable environments todayToby Coleridge, Systems EngineerCitrix Systems

• Architectural Overview

• Scalability Considerations and Results

• Sizing and Design

• High Availability

Agenda

Architectural Overview

Desktop Delivery Controller

Provisioning Server

Desktop Delivery Components: Virtual Desktops

Users

Operating Systems, Apps, and user Profiles are provisioned on demand

Users desktop is delivered

Users login and request their desktop

1 2

3

Apps

User Setting

s

OS

User Profiles

App Delivery

Desktop Provisioning

Virtual DesktopHosting Infrastructure

(XenServer, Hyper-v, ESX)

Virtual Desktop

Scalability Focus

Making Connections

LAN Connected UsersDesktop Appliances

Desktop Delivery Controller

XenApp

Portable Profiles

Provisioning Server

Domain Controller

ADOU

Xen, Hyper-V, VM

SANData Center

1. authenticate

2. find “best” virtual desktop

3. start VM

4. PXE-boot VM and

stream OS

5. register

6. connect using ICA

7. acquire license and determine policies

8. login

9. apply profile

10. deliver apps

Full range of authentication methods supported through web interface technology

Full support for SmartAccess and ICA session policies

Scalability Considerations and Results

Demonstration

Scalability Considerations and Results

XenDesktop Component Versions

Component VersionDesktop Delivery ControllerBroker 3.0

Virtual Desktop Agent 3.0 FP1XenServer VM Infrastructure

5.0 HF3

Provisioning ServerDesktop Provisioning 5.0 SP2

XD3 FP1

Scalability Metrics Definition

XenDesktop Component Scalability Metrics

XenServer VM Infrastructure

• # of VM’s/XenServer (Single Server Density)• # of servers/resource pool• ICA bandwidth/VM• # Storage IOPS/VM

Desktop Delivery ControllerBroker

• Sustained connection rate• Desktop heartbeat

Provisioning ServerDesktop Provisioning

• # of streamed desktops/server

Methodology• The results are based on Citrix proprietary

methodology measuring scalability while preserving a great user experience. These numbers cannot be compared with 3rd-party claims.

• Aggressive workload (more than real-life):– Mainstream office worker:

Office 2007: Outlook (~1257KB pst file), Word (2 ~265KB files), IE7 (2 tabs w. Flash content), Excel (~1325KB file), Acrobat Reader, Powerpoint (~1195KB file)

– High-rate of user actions: Script runs in 18 minute intervals, for 60 minutes (a doc opened and closed every 2min)

• Logon Storm (9am scenario):– Sessions launched at a rate of 5 sessions/sec, spread over 100 hosts (4,500 logons in 15min)

Desktop Delivery ControllerScalability Metrics

Virtual Desktop Infrastructure

Desktop Delivery Controller

XenServerXenServer

Hypervisor

Metric 1: Connection RateRepresents a brokered connectionSustained rate of desktop connections?

1 1

1

Metric 2: Desktop HeartbeatOngoing heartbeat load is very light

2

2

Users

Desktop Delivery Controller 3.0Measured Scalability

Scalability Metric DDC 3.0

Sustained Connection Rate(concurrent desktop launches/server)‘9 AM Logon Storm’

> 5 connections/sec *

Desktop Heartbeats Trivial

Notes:

* Peak CPU utilization at 60%

• Hardware – Dual quad core, 1.8 GHz, 16 GB RAM

• 2 GB RAM sufficient as RAM is not a limiting factor

All figures derived from Citrix proprietary methodology - provided for sizing guidance only, NOT suitable for comparative purposes

Desktop Delivery ControllerBest Practices

Virtual Desktop Infrastructure

Desktop Delivery Controller

XenServerXenServer

Hypervisor

Best Practice: ‘Scale up’ the delivery controller to address ‘9am scenario’ Single serverFaster processorMore cores

1

Best Practice: ‘Scale out’ the delivery controller to address heartbeatsAdd more servers

2

Users

XenServerScalability Metrics

Virtual Desktop Infrastructure

Desktop Delivery Controller

Metric 1: Single Server DensityStack represents a desktopHow many desktops on a single server?

XenServerXenServer

XenServer

Metric 2: # of Hosts/Resource PoolEach box represents a virtualized hostHow many desktops/resource pool?

Metric 3: IOPS/desktopYellow represents streamed imageHow many IOPS/desktop?Resource Pool

UsersMetric 4: ICA bandwidthLine represents an ICA sessionHow much bandwidth per desktop?

XenServer 5.0 HF3 Dual Quad Core 1.86Ghz 16GB

Dual Quad Core 2.4Ghz 32GB

# of VM’s/XenServer*Single Server Density

29 58

# of servers/resource poolVerified to

48(1,392 VMs/resource pool)

48(2,784 VMs/resource pool)

# IOPS/VM 6.1 avg (19.6 peak) 5.9 avg (24.8 peak)

ICA bandwidth/VM 14.79 Kb/sec (avg) 14.79 Kb/sec (avg)

XenServer 5.0Measured Scalability

Notes:• Tests run as of April 2009

• Tests run with WinXP; 512 MB of memory allocated per VM, aggregated 8Gbps of network bandwidth / host

• No Dedicated Pool Master required as of XenServer 5.0

• RAM-bound for these hardware specs – other bottlenecks expected (CPU, network) as RAM is added

HP Blade Server BL460

All figures derived from Citrix proprietary methodology - provided for sizing guidance only, NOT suitable for comparative purposes

XenServerBest Practices

Virtual Desktop Infrastructure

Desktop Delivery Controller

XenServerXenServer

XenServer

Users

Best Practice: Separate VM boots from LogonsUse Idle Pool SettingsPre-launches desktopsSpread out desktop launchesFaster desktop start-up times for usersSave energy/cost via timed shutdown

1

Provisioning Server

OS

Provisioning ServerScalability Metrics

Virtual Desktop Infrastructure

Desktop Delivery Controller

Hosted Desktop Streaming

XenServerXenServer

Hypervisor PXE-boot VM and stream OS

Users

Metric: Provisioning Server DensityNo of target devices (virtual desktops)How many desktops per Provisioning Server?

Local Desktop StreamingPC

Provisioning Server 5.0Measured Scalability

PvS 5.0 SP21 Hosted desktops

Localdesktops

# Desktops / PvS Server 500 - 750 desktopsper PvS server 2

250 - 450 desktopsper PvS server 3

Notes:1 Running on Windows Server 2008 64bit (for enhanced caching capability)2 Write-back cache on local VM storage (ie. on shared storage)3 Lack of separation of bootup vs logon events impacts concurrency. Also, diskless-endpoints

require handling of write-back cache through PvS server

• Hardware – Dual quad core, 2.3 GHz, 8 GB RAM, dual 1Ge NICs

• Network throughput generally the bottleneck - RAM and CPU not limiting factors

All figures derived from Citrix proprietary methodology - provided for sizing guidance only, NOT suitable for comparative purposes

Provisioning ServerBest Practices

Virtual Desktop Infrastructure

Desktop Delivery Controller

XenServerXenServer

Hypervisor

Best Practice: Proximity to hypervisor for: Improved bandwidth Effective NIC-teaming

1

Users

OSOS

OS

vDisk

SANNAS

Best Practice: vDisk Placement Store on LUN for backup & recovery Cache locally on Provisioning Server for

better performance (run on 64bit OS)

3

Best Practice: Write Cache Placement: Store on XenServer guest VM via a LUN Supports XenMotion and HA

4

Best Practice: Cluster Provisioning Servers for: Load balancing

2

PXE-boot VM and stream OS

• Sizing can be done by I/O or Capacity

• Storage can severely impact performance

• Disk technologies and considerations

Storage Considerations

Sizing and Design

Sizing Based on User Types

• Office user• Only using one-two application(s) at a time• Idle time• Lower memory and CPU requirements

• Power user• Using multiple applications at a time• Consumes more processor and memory of

the VM

• Environment Assessment• Identify your user groups• Categorize based on usage habits• Helps align hardware requirements with

user needs

Sizing Based on Applications

• Online (fka Hosted)• Applications run remotely on a XenApp server• Application processing occurs on XenApp server• Running multiple applications has little impact on virtual

desktop utilization

• Offline (fka Streamed)• Applications streamed to the virtual desktop upon request• Processing occurs on the virtual desktop• Slightly higher utilization when compared to installed

applications

• Installed• Applications part of the virtual desktop OS build• Processing occurs on the virtual desktop• May drive the need for multiple vDisks

For best practices on selecting app delivery model, see “XenDesktop – Design Handbook” available at http://support.citrix.com.article/ctx120760

Pooled Desktops: Storage Efficiencies

VDI without XenDesktop• Single image for every desktop• Apps installed in VM• Apps execute in VM• Desktops managed individually• Single infrastructure choice• Same problems, in a new location

VDI with XenDesktop• Single shared OS image to store & maintain• Central single App set to store & maintain• Apps can execute centrally or in VM• Profiles managed centrally – consistent UX• Open - supports most standard infrastructure• Lower TCO

Hypervisor Network Storage Xen, Hyper-V, VM, Blades Network Storage

Stack for every user Desktops assembled on-demand

High Availability

XenServer Resource Pool

XenServer #1

Overcoming FailuresXenServer 5.0

• If the hypervisor fails

XenServer #2

VMVM

VM VM

Hypervisor server failsVirtual machines are restarted to available hypervisor Virtual machines moved back when hypervisor restored

Overcoming FailuresDesktop Delivery Controller 3.0

• Multiple XenDesktop controllers within the farm

XenDesktop Farm Virtual desktops periodically “ping” their controller

VM

VM

VM

VMActive Directory

If a Controller goes offline

Virtual desktops re-register to new controllers

Overcoming FailuresProvisioning Server 5.0

• Multiple Provisioning Servers within the environment

• Shared enterprise storage hosts golden desktop image(s)

Provisioning Server Farm Virtual desktops continuously receive operating system stream

VM

VM

VM

VM

If Provisioning Server taken offline

Virtual desktops re-acquire stream by contacting other Provisioning Servers

Storage

Area of Concern Solution

End Point Failure Workspace Control

Access Gateway Failure High-Availability pair

XenDesktop Controller Failure

Redundant controllers with re-registration of virtual desktops

XenServer Failure Planned: XenMotion running virtual machinesUnplanned: Virtual machines restarted

Provisioning Server Failure Redundant servers (active/active)Shared enterprise storage

XenApp Failure Redundant controllers and redundant Application Hubs

Virtual Desktop Failure New virtual desktop built on-the-fly in matter of seconds

Overcoming FailuresXenDesktop – End-to-End High-Availability Solution

Questions?