1. MODULE 9: SCALING THE ENVIRONMENT

2. Agenda CP storage in a production environment – Understanding IO by Tier Designing for multiple CPs Storage sizing (lab) Cluster design considerations

3. UNDERSTANDING DISK IO AND UNIDESK STORAGE TIERS

4. Unidesk Storage Arch.

5. Boot Volume Tier The VM and associated files are created/located here (.vmx, vswap, etc) VMDK comprised of three things: – Windows Page file for the desktop – A Composited (layered) registry – Basic windows boot files needed before the file system loads Very little IO associated with the Boot volume – First few seconds of boot – Windows Paging

6. CP and Layer Tier Layers are stored in directory structure underneath the CachePoint Layers are stored as VMDKs – OS and App layers are stored as independent non- persistent disks – Personalization layers are stored as Independent Persistent disk Highest IO volume

7. Archive Tier Used to store personalization layer backups Backups are configured per persistent desktop – Backup schedule and frequency can be unique to each desktop – Not every desktop on a CachePoint needs to be backed up Very little IO as it’s simply a storage area – Drives such as SATA or slower speed SAS drives are typically used

8. Tested Desktop Configuration Windows 7 Professional 32 bit Office 2010 Pro Plus VMware vCenter Client Google Chrome and IE8 for browsing Tweetdeck Skype Adobe Reader and Flash Single vCPU 2 GB of RAM – (later changed to 1GB to show increase in IO due to paging)

9. IOPS Analysis by Tier

11. IO Analysis by Tier

12. IOPS by Tier Summary Testing shows that the majority of IO happens at the CachePoint/Layer datastores – Even during a BIC, most IO happens at the Layering volumes Use high performance disk for CachePoint/Layers and less expensive disk for Boot Volume datastores – If these tiers are not combined into a single datastore It is supported to have both CachePoint/Layers and Boot Volume on the same datastore – Although this will use more of the expensive disk over the long run

13. APPLIANCE PLACEMENT & DATASTORE CONSIDERATIONS

14. Appliance Placement? DRS

15. Storage location is what matters MA MCP CP1 CP3 CP2 CP4 CP1 CP2 CP3 CP4 MA MCP

16. Individual CP Storage CP1 OS APP CP1 APP PERS Boot images Layer\CP StorageArchive BOOT Desktop1 vswap BOOT Desktop2 vswap BOOT Desktop3 vswap BOOT Desktop4 vswap BOOT Desktop5 vswap BOOT Desktop6 vswap PERS

17. DRS Putting it all together (3 Tiers) MA MCP CP1 CP3 CP2 CP4 MA MCP

18. DRS Putting it all together (2 Tiers) MA MCP CP1 CP3 CP2 CP4 MA MCP

19. Sizing the datastores Uses the following variables and basic assumptions to define writable storage needs – Desktop memory – User space/personalization layer size – Shared layer size estimate – Backup settings – Number of desktops and desktops per CP Sizing tool from Unidesk is a simple spreadsheet and completely adjustable

20. SIZING UNIDESK STORAGE Lab:

21. Common Limitations? VMware cluster size limit for sharing disks (up to ESXi 5.0) was 8 nodes with active VMs sharing a VMDK on a specific VMFS volume Typical VMFS volume on rotating disk is god about 65-75 desktops (if you handle the IO load) With SSD VMFS is fine to 110-120 CPs have been tested to 250-300 desktops per CP well above typical VMFS usage NFS will allow you have fewer datastores (does not have the VMFS locking issues) though you must still handle IO and have enough CPs

22. DRS How could NFS change this design? MA MCP CP1 CP3 CP2 CP4 MA MCP 75 Desktops Per VMFS volume

23. DRS How could NFS change this design? MA MCP CP1 CP3 CP2 CP4 MA MCP 150 Desktops Per CP? Reduced number of datastores? CP1 CP2

24. OPEN Q&A