TechNet Live spor 1 sesjon 6 - more vdi

MORE VDI! Morgan Simonsen, Atea

Agenda

• VDI Configuration

• Management

• Solution sizing

• Sessions vs. VDI smackdown

CONFIGURING MS VDI

Checklist: Deploy VDI

1. Install RD Session Host role service

2. Install RD Virtualization Host role service

3. Install RD Connection Broker role service

4. Install RD Web Access role service

5. Create virtual desktop VM

6. Configure TS Web Access Computers group on RD Connection Broker

7. Configure RD Web Access

8. Assign a Personal Desktop to a user

9. Configure RemoteApp and Desktop Connection

Connecting to a PVD

1. A user initiates the connection to the personal virtual desktop by using RD Web Access or by using RemoteApp and Desktop Connection

2. The request is sent to the RD Session Host server running in redirection mode

3. The RD Session Host server running in redirection mode forwards the request to the RD Connection Broker server

4. The RD Connection Broker server queries Active Directory Domain Services and retrieves the name of the virtual machine that is assigned to the requesting user account

5. The RD Connection Broker server sends a request to the RD Virtualization Host server to start the virtual machine

6. The RD Virtualization Host server returns the IP address of the fully qualified domain name to the RD Connection Broker server. The RD Connection Broker server then sends this information to the RD Session Host server running in redirection mode

7. The RD Session Host server running in redirection mode redirects the request to the client computer that initiated the connection

8. The client computer connects to the personal virtual desktop

VDI AND SESSIONS SIZING

VDI Capacity Planning

Caveats and Objectives Performance is very subjective with many variables

• Caveats – Data provided is based on benchmark results and is not reflective of many real-life

deployment considerations: • Is based on specific usage scenarios

• Does not account for necessary “cushion” to deal with temporary peaks in resource usage

– Recommend piloting for performance planning

– Multiple factors determine actual performance • Variations in hardware

• Driver versions

• Desktop Workloads

• Application quality

• What we used: – Two differently configured AMD servers

– Fiber Channel SAN

• Objectives to be determined: – An indication of VM’s per server that could VDI scale to

• Processor, Disk and Memory requirements

• Network requirements

– Service Placement

– Comparison against Session Virtualization scale on same hardware

What bottlenecks do you hit first?

• In order, generally that is:

– Disk IO

– Memory pressure

– Processor

• Disk IO is a performance and density related impact

• Memory is a density impact

• Processor is a performance and density related impact


Disk IO Rule of thumb: SANs are your new best friends

• Disk performance is the most critical factor in achieving density

• Internal testing showed Windows 7 having lower Disk IO than Windows XP

• SAN makes significant difference. Highly recommended – Plenty of cache

– Consider de-duplication support especially if persistent

– De-duplication allows the benefits of individual images at the cost of differencing disk

– Managing images on a SAN is way faster and easier than over network (provisioning is faster)

– We mean real SAN (iSCSI or FC) not NAS across the network…

– Remember RDS does not require this huge SAN investment…

• If you have low complexity requirements: – Think about cheaper DAS

– RAID 0+1 offers better read and write performance than RAID 5

– Make sure to consider RDS


Disk IO

• Peak of read/write @ 3500 IOPs on single un-clustered server (Starting 64 VMs simultaneously) – Multiply that by number of servers

– Result is the rough guidance for the maximum SAN disk IOPS you need

– Test for the most demanding user logon pattern (for example: 9 am scenario)

– This test based on Windows 7 Enterprise

• Why use IOPS as a measurement? – Trying to calculate drive perf differences based on seek, latency and

transfer rate is hard

– IOPS is an easier way of understanding disk/SAN performance

– Reference: http://en.wikipedia.org/wiki/IOPS

64

VMs

Read Write Read+Write

Mbytes/sec Ops/sec Mbytes/sec Ops/sec Mbytes/sec Ops/sec

Avg Peak Avg Peak Avg Peak Avg Peak Avg Peak Avg Peak

Logon 10 220 350 2500 8 75 350 2500 18 224 700 3500

Steady

State

.8 3.6 40 260 3.3 10 130 220 4 12 170 400

http://en.wikipedia.org/wiki/IOPS

http://en.wikipedia.org/wiki/IOPS


Memory Rule of thumb: More is better

• Biggest constraint of upper limit VM density (not performance related) – Constrained by:

• Available memory slots in servers

• Largest Available DIMMs

– Creates an artificial scale ceiling

• Buy as much RAM as you expect to scale the number of VM’s

• Plan for and allocate at least 1GB per Windows 7 VM – Memory allocation should be determined by upper maximum limit of

running apps

– Allocate enough RAM to prevent the VM paging to disk

– 1GB actually covers a fair amount of app use….

• Also refer to: http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv-R2.mspx.

http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv-R2.mspx




Processor

Rule of thumb: If it doesn’t have SLAT don’t buy it

• # of VMs per core is highly dependent on user scenarios – Application specific usage play a big role

• Hyper-V supports: – 64 VMs per Server in Clustered scenarios

– 384 VMs per Server in non-Clustered scenarios

– 8 VM’s per Core

• 8 VM’s/core is not an architectural limitation but what we have tested and support

• SLAT enabled processors provide up to 25% improvement in density

• What is Second Level Address Translation (SLAT)?

– Intel calls it Extended Page Tables (EPT)

– AMD calls it Nested Page Tables (NPT) or Rapid Virtualization Indexing (RVI)

– Processor provides two levels of translation

• Walks the guest OS page tables directly

• No need to maintain Shadow Page Table

• No hypervisor code for demand-fill or flush operations

– Resource savings

• Hypervisor CPU time drops to 2%

• Roughly 1MB of memory saved per VM


Processor

Single (Unclustered) server results: – Win7 VMs using 512 MBs RAM per instance – not supported!

– Only supported with 8 VM’s per core • Though lab benchmark testing went as high as 11 VMs per Core at the limit

– Note: Requirements for clustering will limit VDI VM supported capacity to 64 VMs per server

Server Cores SLAT VDI

VMs/Users

RDSH (TS)

Users

RDSH/VDI

Ratio

SERVER1 16 ON 175 310 ~1.75

SERVER1 16 OFF 140 N/A N/A

SERVER2 8 N/A 80 160 ~2.

Server CPU model Sockets Cores Core speed RAM HBA

SERVER1 AMD 8378 4 16 (4x4) 2.4 GHz 128 GB EMC LP 1150 4 Gbps

SERVER2 AMD 8216 4 8 (4x2) 2.4 GHz 64 GB EMC LP 1150 4 Gbps

Server Hardware:


Processor – “Real World”

Real world deployments reflect higher RDS scale

Our customer engagement feedback indicates differences between tests and real world deployments:

• VM’s per core are higher in our tests than in typical production VDI deployments

• Production Session Virtualization scale tends to be higher than our lab tests in users per server

• Our rough estimate is that some customers see as high as 5:1 in favor of Session Virtualization over VDI

• Use cases will determine actual numbers

That means at minimum Session Virt scales 2:1 over VDI and as high as 5:1


Network Performance

Rule of thumb: Rich User Experience requires rich bandwidth

• LAN – Generally place VDI (RDVH) servers as “close” as possible to the users

– VDI User experience is heavily dependent on network performance

– LAN performance generally not a bottleneck (calculate to be sure)

– Network redundancy is very important in switching fabric • When its down, the user is totally down

– Ensure Blade servers can sustain on the backplane

• WAN – WAN issues now equals worse issues later

– Latency kills user experience

– Persistent protocols take bandwidth per connection

– How to tell: Multiply the number of users by approximately 20kbps • Is that beyond the capacity of your internet/WAN network?

• 20kbps is the best case scenario based on HDX

• 20kbps represents a cut down user experience

– Look at WAN optimization technologies or compression solutions

MANAGEMENT – WHAT TRULY

REDUCES TCO

SCVMM Dynamic Placement

At capacit

y already

System Center Configuration

Manager Choices: Local Policy or Separate Primary – Hardware Inventory

– Software Inventory

– Timing of deployment

– Controlling Update targeting

– Restriction to purely OS, agent, definitions, required app servicing

– Choice for native application deployment over App Virtualization

In VDI, remember, its important to reduce VM IO and Churn

System Center Configuration Manager

• Tweaks – Apply Local Policy to limit Site Policy application

• Config Mgr v.Next plans will eliminate this requirement

• http://msdn.microsoft.com/en-us/library/cc146756.aspx

– Hardware Inventory • Eliminate/Minimize

– Software Inventory • Eliminate/Minimize

– Patch Updates • Be very specific with targeting updates (English Update to

English Client)

– Timing of deployment • Offline Machine Servicing Tool 3.0

• Wake up, force poll, apply updates, go back to sleep

http://msdn.microsoft.com/en-us/library/cc146756.aspx



System Center Configuration Manager

• App-V and Config Manager

– App-V 4.6 supports Shared Cache

However…

– Config Manager provides single console management

– Config Manager allows distributed package management

Be aware:

– Config Manager “takes over” App-V client • Cant use both App-V and Config Manager to target the same

VM

Offline Virtual Machine Servicing Tool 3.0 Patching VMs on the Host

REMOTE DESKTOP SESSIONS

VS. VDI SMACKDOWN

The Smackdown Contenders

Round #1 – User Density

Challenge RDSH Private

VMs Pooled

VMs Physical

PCs

User Density

Remote Desktop Protocol

Round #2 – Resource Isolation


VMs Pooled

VMs Physical

PCs

Resource Isolation


Round #3 – Desktop and Application

Performance


VMs Pooled

VMs Physical

PCs

Desktop and App Performance - -


Round #4 – Application

Compatibility


VMs Pooled

VMs Physical

PCs

Application Compatibility -


Round #5 – Network Bandwidth

and Latency


VMs Pooled

VMs Physical

PCs

Network Bandwidth and Latency

- - -


Round #6 – Personalization and

Localization


VMs Pooled

VMs Physical

PCs

Personalization and Localization -


Round #7 – Resource and Load

Management


VMs Pooled

VMs Physical

PCs

Resource and Load Management


Round #8 – Security (Access

Control and Data)


VMs Pooled

VMs Physical

PCs

Security -


Round #9 – Periphery Support


VMs Pooled

VMs Physical

PCs

Periphery Support -


Round #10 – Licensing and Costs


VMs Pooled

VMs Physical

PCs

Licensing and Costs -


Round #11 – Web Integration


VMs Pooled

VMs Physical

PCs

Web Integration


Round #12 – Offline Capabilities


VMs Pooled

VMs Physical

PCs

Offline Capabilities


Round #13 – Desktop Templates


VMs Pooled

VMs Physical

PCs

Desktop Templates


Round #14 – Software Vendor

Support


VMs Pooled

VMs Physical

PCs

Software Vendor Support -


Round #15 – Availability of Skilled

Staff


VMs Pooled

VMs Physical

PCs

Availability of Skilled Staff -


Results

More information

• Microsoft TechNet Remote Desktop guides

• Microsoft Infrastructure Planning and

Design (IPM) Guides

• Microsoft Answers ™

• Citrix: Ask the Architect

• www.v-alliance.net

• www.citrixandmicrosoft.com

Documents

TechNet Live spor 1 sesjon 6 - more vdi