Vous êtes sur la page 1sur 27

VMware View Design Guidelines

Russel Wilkinson, Enterprise Desktop Solutions Specialist, VMware

Overview

Steps to follow: Getting from concept to reality Design process: Optimized for efficiency Best Practices for VMware View Designs

From Concept to Reality

Phases of a Troubled View Deployment

No baseline for comparison

Define

Design

Deploy

Manage

Lessons Learned shifted to Support Organization as issues, not opportunities

Guess the Outcome

Read 30% of Admin Guide

Deploy

Manage

Major Phases of View Deployment

Compare

Assess Define Measure Baseline

Prototype Pilot

Test Confirm

Design

Deploy

Manage

Lessons Learned
7

Design Process

Storage Design

View Pod and Block Design View Pool Design

View Block and Pod Architecture

View Block and Pod Architecture

10

View Block and Pod Architecture

11

Pool Design: Desktop OS Considerations

Time invested in pool design pays dividends many times more than any other aspect of View design work.

Apps

Are my apps supported by a specific OS?


User Familiarity

Will I need to train users on a new OS?

VM Density

Will the OS demand more resources?

Licensing

Do I have a VLK or MAK?

12

Pool Design: View VM Memory Considerations


VM Swap size and storage
VM Density

VM Swap size = VM RAM Local vs. shared datastore

TPS Optimization Disk consumption

Windows pagefile

Size of delta disk IOPS

Memory for Apps

Balance between paging and VM Swap file size

Disposable disks (Daytona)

13

Pool Design: Pool Type Considerations

Common Pool Types: Persistent/non-persistent Linked clone/non-linked clone

User installed apps

Will users need to install apps?

Persona management is a key enabler for floating pools

User initiated machine changes

Are users modifying registry keys or environment variables?

Available disk space

Is disk space inexpensive or plentiful?

14

VI Design: View BlockvCenter and Clusters

vCenter Servers

One VC per 1,000 (VI3.5), 2,000 (VI4.x) desktops

vCenter and Cluster Design

Cluster Hosts

Max Eight ESX hosts per cluster serving linked clones Leave room for failover and maintenance

Cluster Settings

Keep max pool size to 320/875 for DRS enabled clusters 80 (100 ESX 4.1) VMs per host for HA

15

View Manager Design: View Pod

Redundancy

Max 5 Connection Servers to ADAM Group (5+2 in Daytona)

Security server: Many SS to One CS

Ingress

VPN: Only option for external access using PCoIP Tunneled Mode: Fewer max sessions per CS Direct Mode: Direct network access to VMs

Access Mode

16

VI Design: ESX Server Considerations


Balance CPU and memory needs

RAM

Density and cost

Higher density DIMMs increase price ~1GB b/w for 150 VMs

pNICs

VMs/pNIC/ 1 Port group per VLAN ID VLANs 1GBE vs. 10GBE 10GBE cost dropping Storage network (NFS/iSCSI) NFSBest performance
with jumbo frames

Blades have emerged as ideal platform for hosting virtual desktops


17

Storage

Type/protocol Size and Quantity Performance

iSCSI vendors optimizing performance

Local diskgood storage location for vSwp files

Storage Design: Sizing Considerations


Linked Clone Pool datastore size= Replica VM VMDK size + (Desktop VM Memory Provisioned * 2) + (Parent VM VMDK * 25%) + Log File storage size Conservative

10GB (Same as Parent VM)

VM Swap and Windows PF Growth for delta files

~100 MB
Max per LUN: 64

* Number of VMs per Datastore + Datastore free space allocation


18

128 Conservative
15% overhead

Storage Performance Considerations

The tricky part about VDI storage is the peak load, NOT the steady state 2-8 IOPS/VM Avg Peaks can be 15 to 100 Storms 25-100 IOPS/VM Peak Boot storms, AV storms, software installation storms,
login storms, logout storms
times the load of average!

Validate operational SOPs during pilot, or risk the consequences!

Pool Deployment Size of Parent VM disks x number of replicas


CX4: ~5 minutes to deploy one replica for pool, 10GB Parent VMDK

Storage Controller Failover Time Time required to complete Storage Controller switch

19

A look ahead to Daytona: Design Considerations


Profile Management
RTO configuration is View Manager scope, not per pool

ThinApp Package Repository Store MSI and EXE packages in one highly available CIFS share DFS is still a great choice with multiple replicas and fast storage Disposable Disks Initial release: Disposable disks on same volume as delta disk Correct disk alignment will be in the shipping product Including user data disks and disposable disks

20

Best Practices

Best Practices

21

General View Best Practices


Optimize View Desktop guest OS for VDI
Opt-in components model, not a build and remove model
Install and enable only the services and components needed

Nlite and Vlite serve as good examples of possibilities


www.nliteos.com, www.vlite.net

Avoid over-provisioning memory and vCPUs Size Windows page file between 50-100% of memory

Profile the storage IOPSand tell the storage architect This critical step is often overlooked! Size the Parent VM System Disk appropriately Replica creation time greatly affected by Parent VM disks

22

General View Best Practices


Validate size of User Data Disk
Provisioning too little disk for UDD can be detrimental Outlook .OST will likely end up on UDD in Outlook cached mode (and UDDs
are difficult to resize)
Validate the cost and performance tradeoffs of Cached Outlook mode for VDI

Adjust browser cache size to lowest useful setting

Exclude Java Message Bus folder from AV scanner C:\Program Files\VMware\VMware View\Server\MessageBus Avoid running concurrent AV scans Full systems scans cause major performance impacts Stagger full systems scans (when full system scans are a corporate standard)

23

Operational Best Practices


Operations Common Sense
Dont reboot all VMs during operational hours Perform Refresh and Recompose operations on a schedule,
during off-peak times

Track or limit user initiated changes, or plan on increasing


cluster capacity over time

User Application Virtualization to save on application licensing costs Dont include licensed apps in the base image whenever possible Use an image build tool (i.e., MDT) Structured build process and predefined modules drives consistency,
fewer untracked changes

Keep master image metadata outside of View/VI Create and enforce strong naming conventions for Parent VMs and snapshots

24

Operational Best Practices


DHCP
Adjust default lease time (MS DHCP) from 8 days to 1 hour Release DHCP script for floating pools that refresh on logoff

VLAN Usage Avoid overloading VLANs used for View desktops to avoid
running out of IP addresses
This situation is difficult to troubleshoot

vCenter Management Do not allow a vCenter VM to manage the ESX host its running on

25

Recommendations
User Data and Persona Management Use folder redirection for My Documents
Easier to use existing file archival system, maintain multiple file versions

Start evaluating the capabilities of RTO Virtual Profiles

Turn off Outlook Cached Mode VMs on same high speed network dont benefit as much from cached mode Save on disk space and conserve storage IOPS Never P2V a physical machine for a View master image It would be more efficient to build a VM from scratch

26

Questions

27

Vous aimerez peut-être aussi