Monday, August 1, 2016

What fits your environment - Sizing for a VDI environment (Part 2)

So once User Profiling is done (here), next is to size for the environment.
This page talks about how do we conceive sizing for VDI workload and what parameters to be considered before we jump into a calculation.



While there are plenty of calculators available online, but one should not blindly follow them. 
Few important factors should be strongly considered before the rubber hits the road.





Listing down the important building blocks and pointers around them.

CPU:  

VDI is an independent OSE for a user (not shared), hence we start our sizing by knowing how much CPU cycles a user would consume for his day to day activity.
  • The best way to find out is to use capacity planner tools like lakeside (check out assessment.vmware.com).
  • In case that’s not possible, you can refer to benchmarks available by VMware for Task Worker, Knowledge workers and Power Users etc. as guidelines.
  • Make sure you factor CPU overheads for antivirus or software updates (unless planned to be staggered in non-peak hours or other considerations like agent-less AV)
  • Assigning more vCPU to a VDI need not necessarily improve the performance. It largely depends on the type of application running inside the VDI. Its only multi-threaded applications (which are compute intensive) which can benefit from multiple vCPU using SMP (symmetric multiprocessing) to improve performance. For lighter workloads or single threaded application single vCPU per VDI is sufficient



Memory

The next is to identify how much Memory needs to be assigned per VDI. Insufficient RAM allocations can cause excessive Windows paging, generating I/O load causing performance impact.

  • Additional memory needs to be considered for Video RAM / PCOIP Display overhead.
  • To avoid excessive use of TPS, Ballooning or Paging, its better we do not consider Memory overcommitment. Rather Memory Reservation is good idea (subject to the scenario) to ensure there is no lack of resources
  • For Graphic rendering workload (if not using vSGA or vDGA), we need to ensure enough additional memory is allocated for Software based 3D Graphic rendering. For more details check VMware Horizon 3D Engineering Workloads Reference Architecture

Storage: 

Storage for VDI environment can be a topic in itself, however there are few usually ignored areas while sizing.
  • Sizing for Full Clone and Linked clone are 2 separate methods. I'll try to write a page for both maybe in some time. However the more complex is Linked clone sizing, hence i would take that as a reference for now.
    • Make sure you factor Swap file and log file capacity requirement per VDI VM.
    • Storage optimization can be only be achieved for OS drive (C: drive) and NOT User data drive (D: drive).
    • Make sure you factor a growth percent for Delta disk (in Linked clone setup) for Linked Clone VDI.
    • Depending on number of pools to be created, capacity for Golden Images and Replica Image needs to be factored.
    • Make sure you factor for User profile capacity besides User Data. Persona Management/Roaming profile/UEM can help you manage the User Profile data in better way.
    • Additional storage needs to be factor for Infra VMs like vCenter, Connection Server/Replica Server/Security Servers, Composer, Databases, App Volumes, UEM Manager etc.
    • For vSphere 5.1 and Horizon 5.2 and above, space reclamation with SE Sparse disk is must mechanism for efficient management of the Linked clone VDI environment. You can read more about SE Sparse disks and Space Reclamation here
  • Besides Capacity, Performance happens to be an important factor when talking about storage. Performance is measured by 2 parameters.
    • IOPS : Once we have calculated the capacity requirement, we need to check how many IOPS would be needed per user per VDI. IOPS per VDI is sub-divided in 2 sections
      • OS+ Application IOPS : This is catered by Delta Disk and Replica Disk
      • User Data and Profile IOPS: This is catered by Delta Disk and User Data disk
    • Latency: I have seen many projects where Capacity and IOPS were rightly considered but latency of the disks were ignored, leading to unsatisfactory performance results. Latency is factor of type of disk catering to your IOs (SSD/SAS/NL-SAS). While it largely depends on user workload but in a Tiered storage architecture we can follow the below guidelines around latency requirements.
      • Replica Disk < 1 ms
      • Linked Clone Disk / Delta Disk < 5 ms
      • User Data Disk < 10ms


No comments:

Post a Comment