In the first part of this article I discussed how Linked Clone tiering architecture works and how the IO is distributed across different storage tiers. For each tier and disk type I analyzed the IO impact during the creation of a Replica disk, and the customization and boot processes; including persistent disk and user profile behavior.
This study is aiming to find out how much of the IO pattern change overtime as virtual desktops gets utilized and Linked Clone disks grow in size.
For the second part of this study I have included LoginVSI from Login Consultants in my toolset to help me to generate a user like workload. In addition, three tools were used to collect and analyze the IO: vCenter Performance Monitor, Veeam Monitor and Unisphere Analyzer.
Like in Part 1 of this study I have chosen Windows 7 64bit as I believe that’s what new deployments should be using.
The amount of vRAM and vCPU may also alter the IO pattern. I have chosen to use 2GB RAM and 1vCPU as I believe this is the most common configuration out there.
- Windows 7 64bit
- 2 GB vRAM
- 1 vCPU
- 40GB Disk (Approximately 10GB used in the NTFS partition)
The applications installed on the Parent VM are the ones required by LoginVSI. They help to shape the IO profile of the virtual desktop, independent if they are in use or not.
For other configurations please refer to The biggest Linked Clone “IO” Split Study – Part 1/2
It is important to be consistent across tests, from on referred as Run. In order to make sure the tool was generating the exact same workload during the analysis period LoginVSI was set to run for 5 hours under heavy workload mode.
For the fist run a desktop pool was created with a single desktop. The desktop used Replica disk located in a dedicated replica datastore; a linked clone disk located in a dedicated datastore; and a persistent disk located in a dedicated datastore. This architecture is demonstrated by the picture below.
During the study I expected to see most Read IOs issued against the Replica disk and most Write IO issued against the Linked Clone delta file. However, I started to notice this was not necessarily true.
The 5 hour workload below demonstrate Windows and LoginVSI workload being write intensive on Persistent and Linked Clone disks, with most of the writes on Persistent disk. The IOs on Persistent Disk is 205% higher than on Linked Clones.
The reason for such disparity is the way Windows Applications work with local AppData folder. The local AppData folder is constantly used for swapping, writing and temporary files. Because the Windows VM have enough RAM (2GB) the Windows pagefile was barely used, reducing IOs on Linked Clones.
*** The graph above represent 5 hours of constant workload.
The average Peak IO happened at 12 IOs.
- 0 Replica Read IO
- 0 Replica Write IO
- 0 Persistent Read IO
- 6 Persistent Write IO
- 1 Linked Clone Read IO
- 5 Linked Clone Write IO
- Making use of persistent disks Linked Clones growth was not observed. The Linked Clone delta file was initialized at 33KB and after 5 hours of workload it’s size was 99KB.
- This behavior is expected since most write IO were being issued against the Persistent disk. To recap; the persistent disk is responsible for hosting computer and user profiles, including appdata folders responsible for handling Microsoft Office temporary files.
- The two graphs below identify the write IO load on Linked Clones and Persistent Disks. Please notice that the write IO load on Persistent Disks is clearly higher than Linked Clones.
- Let’s not forget the objective of this study. This study is aiming to find out how much of the IO pattern change overtime as virtual desktops gets utilized and Linked Clone disks grow in size.
- For the purpose of this study there was no alteration on number of IO issued against the Linked Clones either on reads or writes. A abnormality was observed at the end of the run.
- The graph below demonstrate the number if read and write IOs on Linked Clone disks. The old saying “VDI is write intensive” can be observed in this picture; and now you know it’s not the caused by Windows swap file given that most IOs are on Persistent disk.
For the second run a desktop pool was created with a single desktop. The desktop used a Replica disk located in a dedicated replica datastore; and a linked clone disk located in a dedicated datastore. No persistent disk was used. This architecture is demonstrated by the picture below.
- As expected the number of IOs issued against Linked Clone disk increased. The graph below demonstrate this substantial increase. It is also possible to identify the pattern change on Linked Clone read IO (clear read line at the bottom of the graph).
The average Peak IO happened at 14 IOs (2 more than Run 1)
- 0 Replica Read IO
- 0 Replica Write IO
- 2 Linked Clone Read IO
- 12 Linked Clone Write IO
- As for the IO pattern change it was also noticed an abnormality with Read IO at the end of the run (picture below). This abnormality correlates to the abnormality identified during Run 1. Each run of LoginVSI workload was set to 5 hours and the abnormality appeared at the end of both runs.
- I am not certain if this abnormality is a pattern change or something related to LoginVSI. Therefore, on the subject of IO pattern change I will call the tests inconclusive, and I will call for another run to eliminate any doubts.
Sometimes you try to identify x and ends up finding y, and that is exactly what happened during this study. In the graph below you will observe the amount of IOs being issued against the Replica disk.
It is common believe (knowledge) that Replica disks have heavy read IO, therefore we (the industry) have been finding ways to serve them in the fastest possible way. Recently, with VMware View 4.5 and later, and the capability of assigning dedicated replica datastores, Replica disks have been placed in datastores backed by Solid State Drives (SSD).
What you notice in the graph below is a Replica disk almost with no use. The virtual desktop during Run 1 had a averaged total of 12 IOps in 5 hours of constant workload with peak at 6 IOps; and the Run 2 has a averaged total of 7 IOps.
The reason for this behavior is that the desktop has enough vRAM to accommodate required application in memory after the 1st load. In the workload executed some of the applications were even opened multiple times but that did not increase number of IOs.
So, do I really need SSD for Replicas?
Placing replicas on SSD definitely help during boot storms (read Part 1 of this study), but that’s about it. During normal workload conditions there is not much activity on Replicas disks.
So, do I really need SSD for Replicas?
If the storage array supports DRAM Cache or EMC’s Fast Cache the answer is no. (There are vendors on the market with different technologies but same objective). Those technologies promote hot storage blocks to memory and/or EFDs.
SSDs have come down in price during the past couple years and are somewhat accessible to most organizations. The trade off between price and performance is not as big anymore and may be favorable for organizations planning to standardize high performance storage tiering on SSDs.
Please, remember that the use of VMware View storage tiering helps you to reduce storage footprint from Terabytes to Gigabytes, therefore should be utilized when possible. Read more about VMware View storage tiering at VMware View 4.5 Linked Cloning explained.
So, do I place Linked Clones on FC disks and Persistent disks on SATA?
This study demonstrates that Persistent disks have higher IO utilization than Linked Clones. If Persistent Disks are in use I would recommend prioritizing IO to persistent disks. Use your fastest disks for Persistent disks.
If no Persistent disk is in use user profile information will be stored on Linked Clones. In this case you should prioritize IOs using your fastest storage tier.
If remote or roaming profiles are in use there would still be a Local AppData to generate all the IOs; therefore roaming profiles will not reduce IO impact.
This piece of information was a revelation to me. I honestly thought Linked Clones would be heavily utilized when comparing to Persistent disks.
Other interesting results from the study
The averaged total number of IOs on Run 2 is 111% higher than Run 2; being 1496 and 1661 respectively. It is conclusive that placing workload on Linked Clones without Persistent disks increased the number of IOs required.
As always your comments are very welcome.