Upload
bach-ngoc-dat
View
50
Download
3
Embed Size (px)
DESCRIPTION
Architecture - The VMware® View™ 4.5 Floating Reference
Citation preview
The VMware® View™ 4.5 Floating Reference Architecture R E F E R E N C E A R C H I T E C T U R E
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 2
Table of Contents
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Hybrid Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Design Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Reference Architecture Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
The Building Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Virtual Infrastructure Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Physical Component Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Compute Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Shared Storage Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Access Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Physical Network Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
VMware View Pod Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
VMware View Building Block Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Desktop Pool Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Active Directory Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Detailed VMware View Pool Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Virtual Machine Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Validation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Client Access Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Workload Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Validation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
CPU Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Memory Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Application Response Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Storage Subsystem Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Network Subsystem Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 3
OverviewIncreasingly, organizations are turning to virtual desktop technologies to address the operational and strategic issues related to traditional corporate desktop environments. VMware® View™ 4.5 not only provides a virtual desktop environment that is secure, cost effective, and easy to deploy; but also provides comprehensive design flexibility.
VMware View 4.5 modernizes the desktop experience to deliver on-demand private cloud capabilities to users for a consistent experience across the global enterprise.
This document provides a reference architecture for floating virtual desktops with VMware View 4.5. Full descriptions of the test environment as well as performance metrics captured during test validation are provided.
This reference architecture provides a proven and tested floating architecture for enterprise desktop deployments. The goal was to design and validate a standardized building block, consisting of components capable of supporting 1,000 virtual desktops. The overall design also includes the infrastructure components necessary to integrate ten building blocks to support a 10,000-user VMware View “pod” that can be managed as a single entity.
The architecture uses common components and a standardized design to reduce the overall cost of implementation and management. All the infrastructure components used to validate the reference architecture are interchangeable, which allows components from an organization’s vendor of choice to be incorporated and utilize unique features that enhance the value of the overall solution.
Hybrid Design
In the previous Stateless Reference Architecture White Paper, a design based around a single host with unmatched scalability was introduced. The fresh design was enabled by a highly flexible design methodology where the individual needs of the desktop were treated as separate layers.
Design flexibility allows for a floating desktop regardless of back-end storage medium, including both local solid-state drives and shared storage. A blended design is possible using both solid-state drives within the host in addition to shared storage. This allows use of both shared storage and the local SSD depending on the pool use case. Individual desktop types could even use local host cache in very specific ways if application needs required.
The primary purpose of a hybrid design is to allow an environment to start with extremely low up- front capital cost, but still allow the architecture to easily take advantage of shared storage as required for certain desktop pool types.
The architecture focuses on enterprise desktop environments and targets larger deployments commonly found in campus environments. However, a floating design provides a high degree of scalability from only a few hosts to hundreds of hosts because of the assembly of the desktop at the last minute for the end user. This allows even small environment to utilize the same design, yet allow for that design to scale to tens of thousands of users.
This whitepaper, based around the same flexible design methodology, is designed to be an extension of previous work. Please view the prior document for VMware View 4.5 component descriptions and VMware View reference architecture methodology. While the prior architecture used local solid-state disk, the design principles in this reference architecture are the same.
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 4
Design Flexibility
When building a highly scalable, flexible, and cost-effective architecture, it is important to view each area of a virtual desktop separately. User data, applications, and desktop operating systems must be thought of as dynamic, flexible layers. Each layer must be independent of another layer if the environment is to have the highest level of scalability and cost effectiveness.
Individualized data is extremely important to be separated for the cost effectiveness of virtualized desktops, as it is the lynchpin to allow floating desktop environments.
User information can be handled using several primary methods:
•Redirectkeyfolderstonetwork-basedfileshares,anduseroamingprofiles
•Useprofilemanagementsoftware,suchasRTOSoftwareorLiquidwareLab’sProfileUnity
•ConfigureVMwareuserdatadisks,attachedatthevirtualizationlayer.
Regardlessoftheuserdatahandling,theimportantaspecttorememberistheactualdesktopshouldbeviewed as disposable. Floating architecture is only able to obtain low cost and high flexibility when user data is properly separated.
While roaming profiles have had a perception of being problematic in the past, with proper design they can be stable and successfully leveraged on a very large scale. A key to successful roaming profiles is keeping the size of the profiles as small as possible. Using extensive folder redirection, especially beyond the defaults that are found in standard group policy objects, the roaming profiles can be stripped down to a bare minimum of files.
Examples of recommended folder redirections:
•ApplicationData
•Documents
•Media(includebothpicturesandmusic)
•Desktop
•Favorites
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 5
Lockingdownthedesktop,specificallynotallowingtheusertosavedatalocallyisespeciallyimportantwithfloating desktops as the data on the desktop could be eliminated entirely when a user logs out of the system. While a persistent design is not required, it is still considered a best practice to allow for addition flexibility and cost savings.
Application flexibility can take on many forms, which include the applications in the base desktop image. As mentioned in the previous stateless whitepaper, if the application was abstracted from the base image additional, use cases are easily provided by the same base image. A single pool could be deployed within an environment with multiple user roles. The abstraction of the application would allow each user to leverage the samebaseOSbutstillmaintainsubstantialdifferencesintheapplicationset.
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 6
Reference Architecture DesignFor this reference architecture a building block-based floating desktop solution capable of supporting at least 10,000 virtual desktops was designed. The solution includes the typical components necessary to integrate 10,000 users into a VMware View “Pod”, which can be managed as a single unit, leveraging a 1,000-user
“building block” as the single replicated entity.
Because VMware View 4.5 enables the centralization of the virtual desktop environment in a highly modular fashion, a high degree of design flexibility is possible in the design. This reference architecture leverages VMwarevSphere™4.1andVMwareView4.5,inadditiontonetwork,compute,andstorage.Overall,thesecomponents optimize performance, scalability, and design flexibility while reducing costs.
This architecture uses common components and a standardized design across the building blocks to reduce the overall cost of implementing and managing the solution. All the physical infrastructure components used to validate this reference architecture are interchangeable. This means that an organization can use a vendor of choice for any physical component of the architecture, including the network, storage, and server components. Various vendors might offer or include unique features that further enhance the value of the overall VMware View offering for a particular enterprise.
The VMware View 4.5 floating 10,000-user pod is show below.
VMware ESX Cluster
Eight VMware vSphere Hosts
VMware View Building Block
Switched Network
1,000 Users
VMware ESX Cluster
Eight VMware vSphere Hosts
VMware View Building Block
VMware ESX Cluster
Eight VMware vSphere Hosts
VMware View Building Block
1,000 Users
VMware ESX Cluster
Eight VMware vSphere Hosts
VMware View Building Block
1,000 Users
VMware ESX Cluster
Eight VMware vSphere Hosts
VMware View Building Block
1,000 Users
VMware ESX Cluster
Eight VMware vSphere Hosts
VMware View Building Block
1,000 Users
VMware ESX Cluster
Eight VMware vSphere Hosts
VMware View Building Block
1,000 Users
VMware ESX Cluster
Eight VMware vSphere Hosts
VMware View Building Block
1,000 Users
VMware ESX Cluster
Eight VMware vSphere Hosts
VMware View Building Block
1,000 Users
VMware ESX Cluster
Eight VMware vSphere Hosts
VMware View Building Block
1,000 Users
VMware ESX Cluster
Eight VMware vSphere Hosts
VMware View Building Block
1,000 Users
Load Balancing
Network Core
VMware View Manager VMware View Manager VMware View Manager VMware View Manager VMware View Manager VMware View Manager
Switched Network
vCenter ServervCenter Server vCenter Server vCenter Server vCenter Server
1,000 Users
Figure 1: VMware View 10,000-User Pod
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 7
The Building Block
The overall pod contains 10 building blocks of 1,000 users each, which is the focus of this reference architecture. Each buildingblockcontainseightphysicalserversconfiguredinasinglecluster.Centralizedsharedstorageisusedforthevirtualization desktops, applications, and user profile data, as well as the core infrastructure server data.
The blade server chassis used for this validation were each capable of supporting 16 blade servers at full capacity; however,anytypeofserverwiththesamehardwarespecificationcanalsobeused.Oneconsiderationwhenusing blades is the port consolidation of each blade server-to-uplink module. Port consolidation is a common factor when leveraging blade servers. Because of the ability to leverage 10Gbit Ethernet, extensive bandwidth was available to the cluster tested, and would easily scale to accommodate 16 blades within the chassis.
A separate set of servers were used to host the common infrastructure components needed for an enterprise desktopenvironment,suchasMicrosoftActiveDirectory,DNS,DHCP,andtheVMwareViewConnectionServers.TheVMwarevCenter™serversalsoranwithinthiscluster.EachdesktopinfrastructureservicewasimplementedasavirtualmachinerunningWindows2008ServerR2.Theinfrastructurebladechassisalso hosted the simulated client devices. Because of the minimal load created by the core infrastructure in comparison to the overall infrastructure, the actual performance of the core infrastructure was left out of this document for clarity.
Each building block shared items such as the physical networking layer, as did the core infrastructure environment. In a smaller environment, it would be possible to have both local and shared storage within the same cluster and provide the floating desktops and the support infrastructure from the same building block.
Figure 2: VMware View 4 .5 Floating Cluster
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 8
Virtual Infrastructure Configuration
The virtual infrastructure at the core of each building block is comprised of physical servers and VMware Virtual Infrastructure4(VI4).Theoverallvirtualinfrastructureisdesignedtosupport10,000desktopusersacross80hosts. Depending on the environment and desktop workload, these results may vary.
TheoverallVMwareView4.5floatingbuildingblockisdesignedtobesupportedbyasingleVMwarevCenter4.1server.TheVMwarevCenterserverdatabasewashostedonasingleMicrosoftSQL2008server.BothVMwarevCenterandtheMicrosoftSQLserverwereimplementedasvirtualmachines.ThevSpherehostsrunningtheseinfrastructurevirtualmachineswerepartofastandardVMwarevSphereHighAvailability(HA)clustertoprotect them from any physical server failures. This is a common approach for hosting desktop infrastructure services that helps provide the highest level of availability.
Each VMware View building block contains one VMware vSphere ESXi 4.1.0 cluster of eight physical servers each. The 8-node cluster is designed to host 1,100 virtual desktops with N+1 redundancy. The cluster was configured with HA and vMotion enabled and configured with default requirements.
AlthoughtheoverallpodisdesignedwithadedicatedVMwarevCenterserverthatincludesitsowndedicateddatabase server, it might be desirable to consolidate the database servers into only one or a few larger database servers. However, database consolidation is not covered as part of this validation effort.
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 9
Physical Component Configuration
Compute Configurations High performing commodity-compute capabilities were chosen to maximize the per-host value of the reference architecture.ParticularwhentestingwithWindows7,ampleCPUisnecessarytoprovideastandarduserusecase a cost effective yet low latency desktop consolidation.
VMwARe View DeskTOp 1,000-UseR ClUsTeR
QTY Description
8 ComputeServers–vSphereESXi4.1.0Build260247
2 SixCore2.93GhzIntelXeonX5670Processors
18 144GBRAMTotalperhost,comprisedofKingston8GBDDR3-1333,Part#KTH-PL313/8G
2 73GBSASdrives,10kRPM,configuredasRAID1
2 BroadcomCorporationNetXtremeII57711E10GbitEthernet
inFRAsTRUCTURe seRVeRs
QTY Description
8 ComputeServers–vSphereESXi4.1.0Build2602472–InfrastructureServices(AD,SQL,andsoon)6–Loadtestinghosts
2 QuadCoreIntelX55702.93GHzProcessors
12 48GBRAM,Kingston4GBDDR3-1333RAM,Part#KCSB200A/4G
2 73GBSASDrives,notused(ESXibootfromSAN)
2 BroadcomCorporationNetXtremeII57711E10GbitEthernet
1 VMwarevCenterVirtualMachineWindows2008ServerR22–vCPU8GB–RAM30GBVirtualDisk
1 MicrosoftSQL2008ServerWindows2008ServerR22–vCPU8GB-RAM40GB Virtual Disk
1 Windows2008ServerR21–vCPU4GB–RAM20GB Virtual DiskActive Directory DNS/DHCP
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 1 0
Shared Storage Configuration
VMwARe View DeskTOp 1,000-UseR ClUsTeR
QTY/Version Description
1 NetApp3140
1 OnTapRelease8.07-mode
2 10G Ethernet
2 2.2GHzPentiumIVCPUs2x32-bit(SingleCore)
4 1,024DoubleDataRateRAM(400MHzDIMMS)
2 10/100/1,100BaseTEthernetports
Release3.0 BIOS
28 (3)300GB15,000rpmdisks(usedforuserdata,applicationstreaming,andsoon)
(25)300GB15,000rpmdisks(usedforthedesktoplinkedclonesandrelateddata)
Access InfrastructureThe physical networking was implemented with a redundant network core of a full 10Gbit Ethernet Module. The networkcorealsoloadbalancesincomingrequestsacrossVMwareViewConnectionServers,whereuserrequestswere routed to the appropriate building block for each virtual desktop session.
Realistically,itwouldbepossibletoprovidenetworkingat10Gbitspeedsfor80hosts(inbladechassis)withapair of switches.
The primary purpose of load balancing in VMware View architecture is to optimize performance by distributing desktopsessionsevenlyacrossallavailableVMwareViewConnectionServers.Italsoimprovesserviceabilityandavailability by directing requests away from servers that are unavailable, and improves scalability by distributing connection requests automatically to new resources as they are added to the VMware View environment.
Secondarily, load balancing provides a critical protection from log on storms, specifically as it relates to spikes in users attempting to be authenticated to the system. This issue is easily mitigated with replica connection servers and proper load balancing.
Support for a redundancy and failover mechanism, typically at the network level, prevents the load balancer from becomingasinglepointoffailure.Forexample,VirtualRouterRedundancyProtocol(VRRP)communicateswiththe load balancer to add redundancy and failover capability. If the main load balancer fails, another load balancer in the group automatically starts handling connections.
To provide fault tolerance, a load balancing solution must be able to remove failed VMware View server clusters from the load balancing group. How failed clusters are detected may vary, but regardless of the method used to remove or blacklist an unresponsive server, the solution must ensure that new, incoming sessions are not directed to the unresponsive server. If a VMware View server fails or becomes unresponsive during an active session, users do not lose data. Instead, desktop states are preserved in the virtual desktop so that, when users reconnect to a different VMware View connection server in the group, their desktop sessions resume from where they were when the failure occurred.
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 1 1
Physical Network Details
pOD CORe neTwORking COMpOnenTs
QTY Description
2 ModularCoreNetworking
8 10 Gbit Ethernet Modules
2 LoadBalancingModules
BUilDing BlOCk neTwORk COMpOnenT (TeChniCAlly shAReD ACROss BUilDing BlOCks)
2 10Gbit Network Switches
VlAn COnFigURATiOn
VLANID Description
10-16 VMwareViewDesktops–Infrastructure802.11qTagged
17 InfrastructureServers–802.11qTagged
20 ManagementNeeds–802.11qTagged
23 Storage–iSCSIandNFS–802.11qTagged
24 vMotion–802.11qTagged
VMware View Connection ServersTwoVMwareViewConnectionServerswereimplementedwithloadbalancingtoprovideredundancyforthebuildingblockforthistest.Fora10,000-userPod,atleastsixVMwareViewConnectionServersshouldbedeployed to support added capacity and provide the highest level of performance and redundancy.
PerVMwarebestpractices,theVMwareViewConnectionServerswereconfiguredasareplicagroup,withtheloadbalancerinfrontofthebrokerprovidingclientnetworktrafficrouting.ThisallowsaViewConnectionServer to fail and have zero impact to the end user base.
VMware View Pod Detail
pOD CORe neTwORking COMpOnenTs
QTY Description
5+1 VMwareViewConnectionServerConnectionServers
10 VMwareViewBuildingBlockClusters
2 VMwareViewPodNetworkCoreComponents
5 VMwarevCenterServer4.1.0–ViewComposerInstalled
1 Microsoft2008SQLServer
1 SharedStorageComponent
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 1 2
VMware View Building Block Detail
1 ,000-UseR VMwARe View ClUsTeR
QTY Description
1 VMwarevSphereESXi4.1.0Clusters
8 VMware vSphere ESXi 4.1.0 Hosts
Details for each connection server were as follows:
•VMwareViewGlobalSettings(includedforclarity)
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 1 3
•ViewConnectionServerSettings
•ViewConnectionServerAuthenticationSettings
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 1 4
Session Management
Desktop Pools were configured to match a floating deployment in a simulated production environment. Because of the type of design, only two pools were needed and thus created per 1,000-user building block.
Individual user accounts were created in Active Directory and assigned to specific groups. Each Group was entitledtoaVMwareViewConnectionServerdesktoppool.
Desktop Pool ConfigurationsView MAnAgeR pOOl COnFigURATiOns
Users Unique ID Desktop Persistence Image Type ClusterAssignment
500 RA_Testing_1 Floating LinkedClone RATesting1
500 RA_Testing_2 Floating LinkedClone RATesting2
Active Directory GroupsView MAnAgeR ACTiVe DiReCTORy gROUps
Group Name Number of Users
Entitle_RA_Testing_1 500
Entitle_RA_Testing_2 500
Detailed VMware View Pool ConfigurationOnceapoolwascreated,theconfigurationforeachwasasfollows:
•PoolSettings
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 1 5
•ProvisioningSettings
• vCenterSettings
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 1 6
Virtual Machine Image
Each virtual desktop in the reference architect environment was based on a single optimized Microsoft Windows732-bittemplate.Windows7isnotdesignedforavirtualenvironment,andassuch,isexpectedtouse a traditional hard disk. Because of these two facts, it is highly recommended to optimize the Windows 7 desktop.
An optimized image will have a drastic decrease in processor, memory, and disk utilization. All testing in this reference architect was performed with an optimized image following the VMware View Windows 7 Optimization Guide in detail.
The template configuration:
ViRTUAl MAChine COnFigURATiOn
QTY Description
1,000 Windows732-bitVirtualMachines
1GB RAM
24GB Virtual Disk
Applications contained with the template:
ViRTUAl MAChine AppliCATiOns
MicrosoftOffice2010
AdobeAcrobatReader9
Microsoft Internet Explorer 8
Windows Media Player
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 1 7
Validation MethodologyWhen validating VMware View reference architecture designs, it is important to simulate a real world environment as closely as possible. For this validation, each component was built and validated for the virtual infrastructure necessary in a 1,000-user cluster using a simulated workload. The networking, load balancing, and core common infrastructure components were also implemented for access infrastructure necessary to support a 10,000-user VMware View Pod.
Figure 3: VMware View Reference Architecture Lab Workflow
Each test was then conducted in two phases. In the first phase, desktop pools were created provisioning the virtual machines to a single server. Each pool was created manually, just as it typically would be created in a normal environment. Testing was performed to find a realistic limit of the single server, which for a 12-core serverallowed143desktops.
The second phase of the validation included session establishment, log on, and execution of a workload across a full cluster. Each client access device established individual VMware View session connections to assigned ViewDesktopsusingtheVMwareViewClient.Onceasessionwasestablished,theworkloadwasruntosimulate typical user activity.
Each session worked in the environment as a standard user throughout the test, during which time the overall system statistics were collected from several components of the architecture. The following sections explain in more detail how each layer was implemented and used as part of the validation and how the workload was implemented.
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 1 8
Client Access Devices
To test and validate each layer of the architecture, simulated client access devices were deployed to simulate arealworldenvironmentusingVMwareDesktopReferenceArchitectureWorkloadSimulator(RAWC).Thesimulated users connect from a client access device through the supporting infrastructure and establish network-basedsessionswiththeViewDesktops.TheRAWCclientaccessdeviceswereimplementedseparatelyfromtheactualbuildingblocksandotherinfrastructurecomponents,suchasActiveDirectory,DNS,DHCP,andfile and print services, to allow for realistic simulation of end users that are outside the datacenter.
EachRAWCclientaccessdevicewasimplementedusingWindowsXPSP364-bitrunningthe64-bitVMwareViewClient.Tenclientaccessdevicesweredeployed,andeachwasusedtoestablishonehundreduniqueVMwareView sessions. Each session was established using a unique individual user account that was entitled to use the desktop pool. During the tests, virtual clients were logged in at random intervals until all the virtual clients had been logged in. Each simulated client’s 100 sessions were started, logging in 10 sessions every 20 seconds.
TheexactRAWCconfigurationisshowbelow:
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 1 9
Workload Description
Each virtual machine was equipped to run a workload that simulates typical user behavior, using an application set commonly found and used across a broad array of desktop environments. The workload has a set of randomly executed functions that perform operations on a variety of applications. Several other factors can be implemented to increase the load or adjust the user behavior, such as the number of words per minute that are typed and the delay between applications being launched.
TheworkloadconfigurationusedforthisvalidationincludedOffice2010,includingWord,Excel,PowerPoint,andInternetExplorer8,AdobeAcrobatReader,andWindowsMediaPlayer.Duringtheexecutionoftheworkload, multiple applications were opened at the same time and windows were minimized and maximized as the workload progressed, randomly switching between each application. Individual application operations that were randomly performed included:
•MicrosoftWord2010 Open/minimize/close,writerandomwords/numbers,savemodifications.
•MicrosoftExcel2010
Open/minimize/close,writerandomnumbers,insert/deletecolumns/rows,copy/pasteformulas, save modifications.
•MicrosoftPowerPoint2010 Open/minimize/close,conductaslideshowpresentation.
•AdobeAcrobatReader Open/minimize/close,browsepagesinPDFdocument.
• InternetExplorer8 Open/minimize/close,browsepage.
•WindowsMediaPlayer OpenandViewasamplevideo.
Based on the “think time” and words per minute used for this validation, this workload could be compared tothatofahigh-endtaskworkerorlower-endknowledgeworker.Realresultswouldabsolutelydependonthe environment’s actual usage, but in general the results in this reference architecture are designed to be conservative.
With this workload, it was validated that at least 1,000 users were able to be maintained by this architecture using the provided server, network, storage resources, and configuration. In addition to being able to sustain 1,000 users with fast application response time, the necessary resources were also available to accommodate a host failure within each cluster, as well as to accommodate a moderate amount of growth or unpredicted increase or change in user workload. Depending on the specific environment, additional changes or features implemented, and the workload characteristics of your users, you may be able to accommodate more or fewer users.
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 2 0
Validation ResultsThis section details the results and observations that were concluded during the validation of floating desktop virtualization with VMware View 4.5.
All validation included several test iterations to ensure data consistency after a ramp up period, for clarity multiple iterations are not shown. All data includes the initial period of massive user logons ramping up the test to show even when pushed heavily the environment can provide an acceptable range of performance.
CPU Utilization
The graphs below is the per-host processor usage, both for the normal 125 users that would be on a server duringa1,100-user8-hosttest(58%average),aswellas143users,simulatingasinglehostfailureinthecluster(67%average).AmpleCPUusageisavailableforadditionalscalability.
Figure 4: 125-User Host CPU Usage
Figure 5: 143-User Host CPU Usage
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 2 1
Memory Usage
Because the total number of desktops on each host only consumed available memory, there is limited memory overcommitment.Additionaluserswouldbeabletobesupported.Asexpected,with143userssomememorypage sharing becomes active, however this is still minimal.
Figure 6: 125-User Host Memory Usage
Figure 7: 143-User Host Memory Usage
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 2 2
Application Response Times
In all tests, application response time was tracked to ensure user experience expectation would be in line with an acceptable environment.
Figure 8: 125 Desktops Application Response Time
Figure 9: 1,100-User Average Application Response Time
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 2 3
Storage Subsystem Detail
The user count storage detail reveals how important the writes are in a desktop virtualization environment that usesproperlyoptimizedimages.OncetheinitialreadI/Ostormsubsides,writestakeanimportantrole.
Figure 10: 125 Desktops, Storage I/O Per Second
Figure 11: 143 Desktops, Storage I/O Per Second
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 2 4
Particularlywhenviewingtheentire1,000-userclusterI/Ousage,theabilitytoprovide5,000sustainedwriteIOPSiscritical.However,theinitialreadstormmustbeplannedwithproperstoragecachesinordertoprovideacceptable performance in all cases.
Figure 12: 1,000 Desktops Storage I/O Per Second
Figure 13: 1,000 Desktops Storage MBytes Per Second
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 2 5
Network Subsystem Detail
Figure 14: 1,000 Desktops Storage Network MBits Per Second
Figure 15: 1,000 Desktops Virtual Machine Network MBits Per Second
The VMware® View™ 4.5 Floating Reference Architecture
R E F E R E N C E A R C H I T E C T U R E / 2 6
ConclusionThe VMware View 4.5 floating architecture can be used to provide flexible low cost desktops in local host storage and storage alike. The flexibility in design allows an organization to start at even a single host, and slowly migrate to the other extreme to address different use cases. In this reference architecture, 1,000-user building blocks were shown to provide adequate performance and proper redundancy. The core design principles of separating user data, application, and the operating system are a foundation and a best practice regardless of the underlying technical VMware View design.
About the AuthorsWorldWideTechnology,Inc.(WWT)isaleadingSystemsIntegratorprovidingtechnologyproducts,servicesand supply chain solutions to customers around the globe. WWT understands today’s advanced technologies, including great depth in datacenter transformation by leveraging virtualization and cloud technologies. When properly planned, procured and deployed, these business solutions reduce costs, increase profitability and ultimately improve a company’s ability to effectively serve their customers.
Foundedin1990,WWThasgrownfromasmallstart-upbusinesstoaworld-classorganizationwithover$3billioninrevenueandmorethan1,400highly-trainedemployees.WWTcontinuestoachieveconsistentfinancial growth and provide our partners with uncommon strength and stability.
WWT’s proven processes span the technology implementation lifecycle as we provide customers with advanced technology solutions. By engaging WWT to manage their planning, procurement and deployment processes, our customers benefit from our certified technology professionals, nationwide logistics facilities and asuiteofeCommerceapplicationsdesignedtogreatlysimplifythesupplychain.
AcknowledgementsVMware would like to acknowledge the following individuals for their contributions to this paper and help with the test setup, analysis, as well as providing the lab infrastructure and building of the joint solution:
World Wide Technology, Inc.: Jason CampagnaandDavidKinsman
VMware, Inc.: Mac Binesh, Fred Schimscheimer, Matt Eccleston, and Mason Uyeda
The VMware® View™ 4.5 Floating Reference Architecture
VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www .vmware .comCopyright © 2011 VMware, Inc . All rights reserved . This product is protected by U .S . and international copyright and intellectual property laws . VMware products are covered by one or more patents listed athttp://www .vmware .com/go/patents . VMware is a registered trademark or trademark of VMware, Inc . in the United States and/or other jurisdictions . All other marks and names mentioned herein may be trademarks of their respective companies . Item No: VMW_11Q1_RA_Floating_EN_PXX
ReferencesVMware View http://www.vmware.com/products/view/
VMwareReferenceArchitectureforStatelessVirtualDesktopswithVMwareView4.5 http://www.vmware.com/files/pdf/VMware-View-45-Stateless-RA.pdf
VMware vSphere 4.1 http://www.vmware.com/products/vsphere/