Blog

Everything you need to know about the new Citrix MCS IO acceleration

With the release of Citrix XenDesktop 7.9, a new feature we’ve all been “keen as mustard” to test is the new Citrix MCS IO acceleration baked into the 7.9 release. If you’re unfamiliar with this functionality, think about the ability to serve burst disk IO directly from RAM instead of slower san disk.

Moreover, if you’re familiar with Citrix Provisioning services, this technology could be directly compared to the “kick ass” feature in Citrix Provisioning services called “Cache in RAM, Overflow to disk”.

Overview:

With Citrix XenDesktop 7.9, you have two new options for optimising and accelerating temporary data:

  • Temporary Ram Cache.
  • Temporary Disk Cache.

With Temporary RAM Cache, you configure a memory limit (say 256mb) and all the IO to the system up to 256mb is written directly to ram instead of disk!

With temporary disk cache, you could choose to offload the write IO to a separate volume or local SSD. Similar again to PVS write cache disks.

WARNING!

an1

If you enable RAM cache, but don’t enable Temporary Disk Cache, the contents of RAM will never reduce and you will bluescreen your target device if your IO is greater than your RAM! E.G. if you run out of RAM, your machine goes down…

Yep you heard me right, consider this cache type the same as the old RAM cache in provisioning services. Useful, but only if you like to live dangerously or have so much RAM the concept of running out is foreign and laughable.

Similarly, if you undersize the cache disk, and the cache disk fills up, your device will “stop responding” to remote requests.

So the golden rules are:

  • Never run RAM cache without disk cache unless you’re certain you will always have free RAM.
  •  Never run Disk Cache without properly sizing the disk to at least the free space available to the VM’s C: drive.

Consider yourself suitably warned!

Back on track!

So with the technology in hands, we dived right in to review the offering:

So I’m going to go ahead and assume you’ve upgraded your site and machines to the latest 7.9 software and VDA’s, if you haven’t, go do it now!

Configure once, never change:

TLDR: you need to create a new catalog.

First things first, unfortunately with this release, you configure your caching options when creating your machine catalogs. So if you do want to use the new caching options today, you’ll need to create new catalogs for your machines and replace the machines in your delivery groups with the new machines you provision with caching.
Adding Temporary storage:

TLDR: Use local or shared storage. Shared is faster to test.

Secondly, knowing that a RAM cache without Disk cache is a bad idea, you’ll need to create a location for your temporary storage. You can use your Shared Storage that you use today, or you can use local storage on the hypervisors.

To add local storage, you need to create new resources and migrate your existing machine catalogs to them. A royal pain in the backside for testing so I opted to NOT do that, instead I simply added my shared storage as temporary storage by editing my current connection:

an2

and Choosing the storage as temporary as follows:

an3

Once I’ve done that, we can get to it!

Creating a Caching Machine catalog:

TLDR: only works on Pooled desktops, can’t be used to create Appdisks

Create a Pooled, random desktop catalog as you would, but ensure to set the VDA to the latest version:

an4

On the next page, you get the good stuff!

an5

Here you can see you can specify the RAM cache size and Disk cache size.
Note: if you do choose shared storage for the temporary cache, you’ll find this temporary disk stored in the same location as the virtual machines disk and configuration.

Note as well, that as this caching removes the write IO from the volume, AppDisk doesn’t work well here if you’re trying to capture applications but their files are in RAM!

Again, remember, don’t do silly stuff:

  • If you want RAM and don’t like bluescreens of death, also enable the disk cache
  • Size your disk cache to at least free space + pagefile, or your system will crash if the disk fills up:

Reviewing the new features:

Once you’ve created your catalog and added the desktops to the a delivery group, it’s play time!

 

Temporary cache disk:

Upon logging into the desktop, you’ll find that you have an unmounted disk the same size as the temporary disk you assigned it, you guessed it, there’s your caching disk:

an6

Note: don’t try to initialise the disk or format it, bad things happen!

TEMPORARY RAM Cache:

The RAM cache itself was less visible on first inspection.

Knowing Citrix the way I thought I did, I fired up PoolMon and had a dig around in the Non Paged category and there it was in all its glory:

an7

It was at this point, I found the performance counters Citrix added for the cache and felt very foolish!

Performance counters:

In Performance Monitor, Citrix have done a great job (Thanks Citrix!) of adding some great counters showing the performance, throughput and usage of the base disk, cache disk and RAM cache all in one place! And the best bit? It’s not in WMI!

an8

How does the cache work:

Looking at the following counters, you can see the total available cache and the current memory in use by the cache:

• Cache Memory used
• Cache Memory Target size

With these counters being displayed on the screen, I began testing to see how this technology behaves:

Logic in the RAM cache:

an9

  • I performed a file copy to occupy some space
  • I then performed a file copy larger than the space available in cache.
  • Once lines moved the way I expected, I performed a delete operation and the cache usage reduced!

So that’s pretty cool, what we can tell straight away is:

  • The RAM cache can and will burst up and overshoot the maximum ram configured at times to up to 50% and always less than roughly 75% of overall system RAM.
  • The Cache is first in, first out. And will remove data from the start of the cache as soon as it fills.

And what happens if I copy in more data to a device running the ram cache without a cache disk?

¯\_(ツ)_/¯

Hence my warning, don’t do RAM cache alone, it’s not a good idea… anyway, let’s throw the disk into the mix!

Logic with RAM and Disk Cache:

an11

This time I performed a file copy much larger than the RAM cache size to see the impact on the disk. From this exercise

  • The RAM cache is the first port of call for all IO.
  • Once the RAM cache saturates, it begins to dump its contents to the disk
  • As space is freed in RAM, the file copy begins to fill that space.
  • This continues and spiking happens (and mentioned why in previous section) throughout the file copy
  • Once the file copy is complete, RAM stays full.
  • Once I then deleted the file, both the size of the disk cache and the ram cache greatly reduced.

Ok so that’s how it works!

But what about performance?

So firing up IOMeter and using the tried and trusted Desktop virtualisation workload as recommended from Atlantis computing I tested my meagre home lab on a base image without RAM cache:

an12

When the IOMeter is working with a file smaller than the size of the RAM cache, the results are astounding:

an13

Sadly, when the IOMeter file is greater than the size of the cache (256 mb cache, 1gb IOMeter file). The results are very negative:

an14

Unfortunately, this is in line with the same negative impact that the Citrix Provisioning Services driver has when it’s overloaded, if anything it’s a bit worse.
New Script based action:

So the beauty of working with ControlUp, or being a ControlUp customer is, with “script based actions” you don’t need to wait for the monitoring vendor to investigate and develop solutions. Instead, with a little bit of tinkering you can create a script based action to get the data you need!

Wouldn’t it be great if you could run a command to see how much cache is in use in your environment on your newly provisioned MCS desktops with RAM and Disk cache?

I thought so too!

Coming to a ControlUp console near you soon! I present the “get Citrix MCS RAM / Disk Cache usage” script based action!

an15

This script based action will allow you to quickly and easily view the cache usage on your target machines as below:

an16

Wrap up:

Citrix MCS IO caching is a welcomed feature to the MCS provisioning platform. It’s relatively easy to setup but there are some pitfalls around configuration and performance.

Still, for a 1.0 product, with performance counters baked in, it’s a really good effort from Citrix and I’m sure it’s going to raise some real interest for Citrix customers.

Remember:

  • Always combine RAM with Disk If you hope to use RAM.
  • Size the Disk for at least free space + pagefile size.
  • Spare time and thought for performance load testing!

Thanks for taking the time to read my latest blog post and I hope you enjoyed the deep dive! Until next time, happy virtualising!

A big thank you to Juan Rivera, Sheldon Lachambre and Alton Taylor in Citrix for their insights and time while creating this blog post.

Be Sociable, Share!

Comments (12)

  • Nick Rintalan | June 1, 2016 at 6:06 pm Reply

    Great stuff, Andrew!

  • Biju | June 4, 2016 at 3:49 am Reply

    Great.

  • René Bigler | June 4, 2016 at 12:42 pm Reply

    mcs cached vm are not agile at all in a xenserver pool due to permanently associated virtual disk to local storage of single host 🙁

    • Andrew Morgan | June 12, 2016 at 9:22 am

      Hi René,

      Is host evacuation or vMotion / migration of VM’s something you frequently do with virtual desktops?

  • kyle | June 9, 2016 at 5:13 pm Reply

    Great info, thanks. Any idea why I get a restart noticed on vms I provision with ram cache?

    I even tried adding the temp cache disk to the golden image but each mcs vm still says hardware has changed.

    • Andrew Morgan | June 12, 2016 at 9:24 am

      I’ve seen this before but I have no idea why it happens. I did notice Citrix try to suppress the message with AppDisk but at times it misses it.

  • Chris Calaf | June 12, 2016 at 10:50 am Reply

    Awesome post! it’s not clear if it is supported with PVD, have you tested it?

  • Pieter Mussche | June 28, 2016 at 3:27 pm Reply

    Great information!
    Although I also notice that cache disk size is indeed reduced when deleting data, this is does not seem the case on the hypervisor storage level.

    My temporarystorage.vmdk keeps on growing after time and is never reduced in size. Not after reboot, not after shutdown.

    Is this expected behaviour?

    Thanks
    Pieter

    • Andrew Morgan | June 28, 2016 at 6:11 pm

      Unfortunately the storage space will never be reclaimed. This seems to be by design.

  • Roland | June 29, 2016 at 9:58 am Reply

    Efrat, nice article. Can you think of any downsides to making the memory allocated to cache larger? In PVS I’ve already used 4 GB and seen 8 GB

    • Andrew Morgan | June 29, 2016 at 1:10 pm

      so long as you have enough ram, go for as much as you can 🙂

  • Steve Cabrera | October 31, 2016 at 12:50 am Reply

    This is a great summary. Well done.

Leave a comment

Your email address will not be published.

Do you have more
 questions?
Want a real person to walk you through a live demo?
We’re happy to help out.
Feb 5 – Citrix and ControlUp webinar introducing ControlUp 4.1 and user experience management. Sign up now!
START YOUR TRIAL
Get Your Download Link
Gain access to ControlUp from your PC. Register and get a link to start your Free Trial.