Data Storage for VDI – Part 7 – 1000 heavy users on 18 spindles
The nice thing from my point of view is that because VDI’s steady state performance is characterized by a high percentage of random writes and high concurrency, the performance architecture of Data ONTAP has been well optimized for VDI for quite some time, in fact since before VDI was really focus for anyone. As my dad said to me once, “Sometimes its better to be lucky than it is to be good” 🙂
As proof of this, I used our internal VDI sizing tools for
- 1000 users
- 50% Read, 50% Writes
- 10 IOPS/second
- 10GB single instanced (using FAS Deduplication) Operating system image
- 0.5 GB RAM per Guest (used to factor the vSwap requirements)
- 1 GB of Unique data per user (deliberately low to keep the focus on the number of disks required for IOPS)
- 20ms read response times
- WAFL filesystem 90% Full
The sizer came back with needing only 24 FC disks to satisfy the IOPS requirement on our entry level 2040 controller without needing any form of SSD or extra accelerators.
That works out to over 400 IOPS / 15K disk or about 40 users per 15K disk, 400% better than the 10 users per 15K RAID-DP spindle predicted by Ruben’s model. For the 20% Read 80% write example, the numbers are even better with only 18 disks on the FAS-2040 which is 555 IOPs or 55 users per disk vs. the 9 predicted by Rubens model (611% better than predicted). To see how this compares to other SAN arrays, check out the following table which outlines the expected efficiencies from RAID 5, 10, and 6 for VDI workloads.
|Read IEF||Write IEF||Overall Efficiency at 30:70 R/W||Overall Efficiency at 50:50 R/W|
|RAID-DP + WAFL 90% Full||100%||200-350%||230%||170%|
The really interesting thing about these results is that as the workload becomes more dominated by write traffic, RAID-DP+WAFL gets even greater efficiencies. At a 50:50 workload the write IEF is around 240%, however at 30:70 workload the write IEF is close to 290%. This happens because random reads inevitably cause more disk seeks, whereas writes are pretty much always sequential.
Don’t get me wrong, I think Ruben did outstanding work, and something which I’ve learned a lot from, but when it comes to sizing NetApp storage by I/O I think he was working with some inaccurate or outdated data that led him to some erroneous conclusions which I hope I’ve been able to clarify in this blog.
In my next post, I hope to cover how megacaching techniques such as NetApp’s FlashCache can be used in VDI environments and a few specific configuration tweaks that can be used on a NetApp array to improve the performance of your VDI environment.