Sometimes the obvious is not quite as obvious to others as it is to you. Given my role as an architect I have spent countless hours looking at storage performance and the impact of it on Desktop Virtualization also known as VDI. It is my belief that storage performance is directly correlated with the user experience. Unfortunately, purchasing higher performing storage increases the cost of the VDI implementation and pushes the ROI out further. Today’s blog is about how using Provisioning Services (PVS) can improve the user experience and help you stretch your storage budget.
Scalability Testing and IOPS
Before we begin, a little background to level-set my calculations. I have spent the last six months doing Windows 7 scalability testing and analysis on Hyper-V 2008 R2. During the testing I was able build a model that predicted the peak IOPS that would occur on the SAN for the three key scalability phases: Bootup, Login, Steady-state. To get the model to accurately predict the IOPS, I ended up with 300 IOPS for the time a workstation was booting (about two minutes), 100 IOPS for the time a login occurred (about 30 seconds), and 5 IOPS for the Steady-state workload. Those numbers may be different in your environment, but they were perfect for my environment which used Provisioning Server and standard-mode vDisks for all the virtual machines.
Most of the time when Provisioning Services is mentioned with XenDesktop, it is brought up in conjunction with saving storage costs since it significantly reduces the amount of storage required for a VDI environment. What apparently is not obvious to everyone is that PVS plays an important role in improving the user experience in two other key areas both related to reducing IOPS on the storage.
Moving Read IOPS from the SAN to the Network
Provisioning Services decreases the IOPS required on the storage by removing most of the read operations from the storage array. In a normal installation, reading the operating system files would generate read I/O from the SAN. With PVS, those reads come over the network card from the PVS server instead of from the SAN. Therefore, with XenDesktop VDI workloads are write-intensive, pushing a 10/90 read/write ratio. This architecture materially alters the read/write ratio and increases the load on the SAN. In the past we didn’t try to quantify the difference.
Microsoft recently released a whitepaper that reviews what Citrix refers to as Single-Server Scalability (SSS) for their Remote Deployment Services on Windows Server 2008 R2. I highly recommend the document in general and I found it quite informative; however for the purposes of today’s blog it provides an important data point for a configuration where PVS is not being used. Because the methodologies do not align a direct comparison between the results in Microsoft’s paper and Citrix’s own SSS testing cannot be made; however, since user login are similar regardless of the user workload that occurs later in the session the disk read/write ratios are still relevant.
Using the values that we have, we can put together a simple example. Microsoft reports an average read/write ratio for user login of 50/50 with an average of 700 IOPS (read+write) during the test. With that information we can calculate that PVS (using a 10/90 ratio) is really saving about 315 IOPS (350 * 90%) during the login process in this situation. From above, you will recall that logins were 100 IOPS on the SAN and bootup was 300 IOPS, so bootups are roughly three times more expensive in terms of SAN IOPS than logons when Win7 is running on Hyper-V, so the saving during boot could be as high as 1000 IOPS. Of course, the disclaimer is still valid here and these numbers are just for illustration purposes since your results may vary.
Decreasing Desktop Boot Time
Provisioning Services also decreases the boot time for a Windows workstation. At first this may not seem like that big of a deal; but if you think about it for a minute or two, you realize that booting a Windows workstation is the most storage intensive operation you can get for a VDI environment. To have a good user experience with VDI, your storage tier needs to handle the peak IOPS load during a boot storm. If a technology can reduce the amount of time a machine is booting, then it stands to reason that when multiple machines are booting simultaneously the peak load would be reduced.
Perhaps an illustration with numbers would help here as well. Suppose you had to get 3000 machines started within 60 minutes. In order to meet that load you would need to boot about 50 machines per minute. If each machine took three minutes to boot and during that three minutes they were using 300 IOPS on the SAN, the peak IOPS would be roughly 45000 (50 * 3 * 300) IOPS. If PVS was able to reduce the boot time for those desktops by one minute the peak IOPS required would drop to 30000 (50 * 2 * 300). Last time I checked a significant price difference existrf between a SAN that supports 45000 peak IOPS and one that only supported 30000 peak IOPS.
Wrapping It Up
As I mentioned earlier, both of these benefits are closely related but often overlooked. Both improve the user experience by reducing the load on the SAN because the read traffic comes over the network instead of over the SAN. Because Provisioning Services reduces the IOPS during all of the key scalability phases, I believe that including PVS in your design will save on SAN storage costs and ultimately increase the ROI of your VDI deployment.
If you found this information useful and would like to be notified of future blog posts, please follow me on Twitter @pwilson98.
VirtualizationJedi 
Posted on 2010/08/06