«

»

Aug 16 2011

The biggest Linked Clone “IO” Split Study – Part 2/2

Advertisement

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.

 

Architecture

 

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

 

Workload

 

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.

 

Run 1

 

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.

 

image

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.

 

image

*** 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.

    image 

     

    image

        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.
          image

                Run 2

            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.

            image

                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).

                image

                  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.

                    image

                        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.

                       

                      The Replica

                       

                      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.

                       

                      image

                       

                      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

                       

                      image The Linked Clone delta on Run 2 grew to 181KB; 584% growth if compared to Run1. This happened because user data from persistent disk was merged into the Linked Clone for Run 2.

                      image 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.

                      image The averaged total number of IOs issued against the Replica was 12 for the Run 1 and 7 for the Run 2 (customization and boot are not considered in Part 2 of this study).

                      image Virtual desktops with enough vRAM will not cause big IO impact due to Windows memory paging.

                       

                      As always your comments are very welcome.

                      Similar Posts:

                      Permanent link to this article: http://myvirtualcloud.net/?p=2138

                      8 comments

                      4 pings

                      Skip to comment form

                      1. Jannie Hanekom

                        Awesome set of tests, can appreciate the amount of effort that went into them. Will take some time to digest fully, but it’s a solid reminder of the importance of testing assumptions.

                      2. Larry Orloff

                        Very interesting study. I think Win 7 32 bit will be more utilized than Win 7 64bit though. When only assigning ~2GB of RAM to a guest, 64bit really doesn’t buy you anything, and you get lower consolidation ratios. Just my opinion obviously, but from many that I’ve talked to, and some testing I’ve done, I’ve seen 32bit better for VDI.

                      3. Jonathan Leafty

                        Wow, I thought I was going crazy a few weeks ago when I was testing IO usage with separate datastores. I had your (industries’) same assumptions, that Replica read I/O was going to be going crazy and write/read IOs to Linked Clones and Persistent disks would be predictable.

                        I observed the pattern (Windows XP) and my jaw dropped. What was I seeing? Heavy IO to persistent disks datastore (now mind you, we also have AV with startup/critical area scan too) and insignificant usage on the Replica datastore (after boot).

                        I too thought the “Linked Clone” datastore would see more usage since it stores the swap.

                        I’m new to this game, so I assumed I was just looking at it wrong. Nice to get some confirmation.

                        Your blog is amazing, keep up the good work.

                      4. Andre Leibovici

                        @Larry Orloff
                        Thanks for the comments.

                        I have in the past done a test between Windows XP 32b and 64b. Please read my article “Windows XP x64 in virtual environments might go beyond appearances” at http://myvirtualcloud.net/?p=900

                        Sometime soon I’ll find som cycles to run tests with Windows 7.

                      5. Andre Leibovici

                        @Jonathan Leafty
                        Thanks for the great feedback.

                      6. Andre Leibovici

                        @Jannie Hanekom
                        In the past I used to see VDI deployments being tactical aproach to solve specific issue. Fortunately this is changing and organizations now realize the benefits of a strategic aproach that included POC and Pilot before going into production.

                        Thanks
                        Andre

                      7. Richard Hou

                        Can you explain in more details what created the heavy write IO? My understanding is after system bootup, should be more read io than write, but your article mentioned 50/50 R/W and one of your customer doing 18/82?

                      8. Andre Leibovici

                        @Richard Hou
                        It’s a missconception to think that VDI will be more Read than Write after bootstorm. May I recomend you reading my article “Get hold of VDI IOPs, Read/Write Ratios and Storage Tiering” at http://myvirtualcloud.net/?p=1421

                        Andre

                      1. - Cliff Davies

                        [...] is the Part 1 of 2 of this article. Part 2 discuss IO trending as a Linked Clone delta disk grow. I personally have not seen any reports or [...]

                      2. cloning graph - NEW BIOTECHNOLOGIES – NEW BIOTECHNOLOGIES

                        [...] myvirtualcloud.net » The biggest Linked Clone “IO” Split Study …Description : 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 …http://myvirtualcloud.net/?p=2 .. [...]

                      3. Quick VDI Sizing HowTo « vtexan.com

                        [...] talking with Andre Leibovici (Blog: http://myvirtualcloud.net/) on the vSpecialist team, all of his deep-dive understanding of Read/Write ratios for VDI is that the ratio in the real world is about 80/20 Writes/Reads for Windows 7.  Yup, I’m [...]

                      4. Quick VDI Sizing HowTo « « a vTexana vTexan

                        [...] talking with Andre Leibovici (Blog: http://myvirtualcloud.net/) on the vSpecialist team, all of his deep-dive understanding of Read/Write ratios for VDI is that the ratio in the real world is about 80/20 Writes/Reads for Windows 7.  Yup, I’m [...]

                      Leave a Reply