P2P Session VIEW POC Findings Topic: Resource and Hardware Allocation June 2009
description
Transcript of P2P Session VIEW POC Findings Topic: Resource and Hardware Allocation June 2009
P2P Session
VIEW POC Findings
Topic: Resource and Hardware AllocationJune 2009
James Soler
Matt Mancini
Agenda
Topic Overview
Test Criteria
Results
Recommendations
Topic Overview
During the 2nd and 3rd weeks of June 2009 we benchmarked and tested the functionality of VMWARE View 3.1 against our current POC hardware
Our goals were Document how our hardware performed under loads
Document how we could control the load
Establish a baseline for hardware and resource loads
Recommend View Server hardware based on our findings
Test Criteria
The Blades
POC Blade is a BL460c / 32GB RAM / 6 NIC / 2 x Quad Core Xeon x5355 Clovertown Core 2.66Ghz CPU ~21.5Ghz / 2 Fiber HBA / ESX 3.5 U4
The Rack Servers
Demo Servers are DL380 G6/ 108GB RAM / 10 NIC / 2 x Quad Core Xeon x5560 Gainstown Nehalem 2.8 GHz CPU ~ 22.4 GHz / 6 Fiber HBA / ESX 3.5 U4
Test VM’s
MAX 1 x vCPU 2.66Ghz / 1GB RAM
Normal 1 x vCPU 1.5Ghz / 1GB Ram Limits (Limited using Vcenter Resource Pool)
View Environment
Thin Client
Desktop
Notebook
View Connection Manager
VCenter Server
ESX Host Cluster
View Virtual Desktop Pool
Test Criteria
How we Tested the Blades and VM’s
We would deploy between 1 to 41 VM’s across each server
VM’s were deployed with XP using VMWare’s XP deployment guide
We would use one VM as the benchmark and the others as the load
The load VM’s would run PassMark’s Burn in Test which would enable us to drive the CPU / RAM / NIC / HD at different saturation levels
Situations levels were tested in different combinations of 5, 10, 25, 50 and 100%
While the Burn In Test was running we’d run Passmark’s Performance Test to establish a benchmark score. This score was double and often triple verified
Base Line Performance Test
Environment
We did test Vista, however it seamed to make no difference in performance. In fact it seamed to waste resources as it wouldn’t settle down when idle
During testing if VM’s were unlimited they would saturate the blades and the benchmark PC will score very low with BL460c blades
If VM’s are restricted by CPU GHz then the tend to work better together and score higher even at full loads with the BL460c blades
Limiting Resources on the DL380 G6 did not have same effect as the BL460c blades. In most cases it actually hurt overall performance even with 20+ VM’s
Resource Pool
BL460c 10 VM’s Running @ 100%
Resource Limited @ 1.5 GHz – 331 Resources Unlimited – 308
BL460c 20VM’s Running @ 100%
Resource Limited @ 1.5 GHz – 169 Resources Unlimited – 128
DL380 G6 10 VM’s Running @ 100%
Resource Limited @ 1.5 GHz – 447 Resources Unlimited – 535
DL380 G6 30VM’s Running @ 25%
Resource Limited @ 1.5 GHz – 358 Resources Unlimited – 370
Multi Pathing
We also found early on that the Virtual Desktops were scoring very low in the Disk Mark compared to Physical systems
Once we enabled Multi Pathing with in VCenter our Disk I/O doubled improving the overall score of the View Desktops
Multi Path Disk I/O Comparison
BL460c 10 VM’s Running @ 100% with out Multi Path configured
Disk Mark – 31.3
Passmark Rating – 193
BL460c 10 VM’s Running @ 100% with Multi Path configured
Disk Mark – 69.5
Passmark Rating – 308
Multipathing
Multipathing
Logical Test Layout
Host Server 10 Virtual Desktops running @ 100% Load
1 Virtual Desktop running benchmark tool
View Virtual Desktop Pool
10 VM’s @ 100%
Logical Test Layout
Host Server 20 Virtual Desktops running @ 25% Load
1 Virtual Desktop running benchmark tool
View Virtual Desktop Pool
20 VM’s @ 25%
Logical Test Layout
Host Server 30 Virtual Desktops running @ 25% Load
1 Virtual Desktop running benchmark tool
View Virtual Desktop Pool
30 VM’s @ 25%
Recommendations for BL460c
We should enable VM Resource limits to
1 vCPU at 1.5Ghz
1GB of RAM
Resource Pools should be limited to 1.5GHz less the max for an ESX servers CPU
Disk I/O is a performance issues. By enabling multipathing and keeping HBA to LUN relationship as low as possible our performance issues should be minimized.
If we are to deploy 600 VM’s across 2TB with 4 to 8 LUNS then we should consider a 1:1 or 1:2 HBA / LUN relationship
4 VM’s per core due to performance issues at Max capacity.
Recommendations for DL380 Physical Servers
Resource Limits are not necessary with new processors
Minimum 4 to 6 HBA’s per server
NIC’s 6 to 8 are adequate
96 GB Memory or more per server
5 VM’s per core – Conservative to VMWare’s 8 VM’s per core
Conclusion Depending on your hardware and performance
requirements View 3.1 will easily support 4-8 VM’s per Core.
VCenter configuration is very important to performance of View
Build you environment based on what your needs are