After my recent blogposts AppVolumes and Citrix XenDesktop, a happy couple? and How Nutanix helps Citrix MCS with Shadow Clones I got the question from Andre Leibovici to validate if the read-only disks created via AppVolumes can benefit from our Shadow Clones technology.

What was Shadow Clones thing again?

NDFS has a feature called Shadow Clones, it will enable us to do distributed caching of vDisks or VM data which is in a multi-reader scenario. This would be the case when the master image is used, all reads come from the master image and all writes will go to the differencing disk.

From the Nutanix bible:

With Shadow Clones, NDFS will monitor vDisk access trends similar to what it does for data locality. However in the case there are requests occurring from more than two remote CVMs (as well as the local CVM), and all of the requests are read I/O, the vDisk will be marked as immutable.  Once the disk has been marked as immutable the vDisk can then be cached locally by each CVM making read requests to it (aka Shadow Clones of the base vDisk). This will allow VMs on each node to read the Base VM’s vDisk locally. In the case of VDI, this means the replica disk can be cached by each node and all read requests for the base will be served locally.  NOTE:  The data will only be migrated on a read as to not flood the network and allow for efficient cache utilization. In the case where the Base VM is modified the Shadow Clones will be dropped and the process will start over.

What about AppVolumes and Shadow Clones?

As you could see from my previous blogpost on AppVolumes I’ve created two AppStacks:

And as I already described in my former blogpost the AppStack is in writeable mode when it’s in a provisioning phase but as soon as the provisioning phase is done it will be stored as a read-only VMDK.

Because we monitor the vDisk access pattern we can see that these disks are read-only and the vDisk will be marked as immutable. This will enable us to create a cached copy locally so all reads are done locally which will speed up the environment.

Validating the use of Shadow Clones

After configuring the AppStack I wanted to see if this actually works this way, in theory it would as NDFS should detect this automatically and my cluster is running > 4.0.2 so Shadow Clones is enabled by default.

With some help of Dwayne Lessner I was able to validate that Shadow Clones would work for the VMDKs from the AppStacks. There are a couple of options to validate this:

From the NCLI on a CVM:

This will list all vDisks that are Shadow Clones and as I’m using the lab environment for all kinds of deployments with non-persistent VDI scenarios I had a lot of vDisks in this list but based on the cross check I noticed the same notation in my list:

Another way to cross check this is to take a look at the 2009 page (the 2009 page is the access page of Stargate and is used to monitor the back end storage system) as the vDisks that are Shadow Clones will be marked with a ‘#’. In my case I found the following:

Concluding

Shadow Clones will support the read-only AppStacks from AppVolumes and leverage the option of data locality for the reads to this vDisk. This will speed up access to the vDisk and thus to the applications and data. A good combination? For sure!

And just to proof how much value Shadow Clones bring to technology stacks like AppVolumes I’ve done some testing..

Test scenario:

• XenDesktop 7.6;
• A vanilla installation of Windows 7 with 2 AppStacks;
• UberAgent (thank you very much Helge Klein!)
• NOS 4.* (So I used the following NCLI command: ‘ncli cluster edit-params enable-shadow-clones=<true/false>’ to enable/disable Shadow Clones

What I did is to run some basic tests with Foxit PDF reader and Adobe Reader, I started Adobe Reader four times and Foxit PDF reader twice to make sure my test results were the same. I first ran the test with Shadow Clones enabled and did the same test with this technology disabled (which is done within seconds, after enabling Shadow Clones NDFS detected the read-only disk within a few seconds).. The outcome?

Login Times:

On the left we see login times with Shadow Clones enabled, on the right we see login times with Shadow Clones disabled. The blue part of this chart is called ‘Other’ within UberAgent, my conclusion is that this is the process of mounting the VDMK containing the AppStack to the target VM (My XenDesktop VM) and because of the fact that we’re using data locality with Shadow Clones it will execute this process much faster.

Adobe Reader:

Foxit PDF reader:

By using Shadow Clones we improved the launch time of Adobe Reader (on average) with almost 360% and FoxitReader (on average) 17%. It’s safe to say that the usage of this technology and thus data locality is a pretty big deal, as you can see applications and logons will be faster resulting in a better user experience and acceptance.

The following two tabs change content below.

• Bio
• Latest Posts

Kees Baggerman

Kees Baggerman is a Staff Solutions Architect for End User Computing at Nutanix. Kees has driven numerous Microsoft and Citrix, and RES infrastructures functional/technical designs, migrations, implementations engagements over the years.

Latest posts by Kees Baggerman (see all)

• Nutanix AHV and Citrix MCS: Adding a persistent disk via Powershell – v2 - November 19, 2019
• Recovering a Protection Domain snapshot to a VM - September 13, 2019
• Checking power settings on VMs using powershell - September 11, 2019
• Updated: VM Reporting Script for Nutanix with Powershell - July 3, 2019
• Updated (again!): VM Reporting Script for Nutanix AHV/vSphere with Powershell - June 17, 2019