Udostępnij za pośrednictwem

Getting Started with The App-V Shared Cache in 4.6 RC – Part 1

  • Artykuł

Well my first few weeks back into the office and it has been a busy first few week back. So i thought i would get back to things with a bang! and one of these bangs would be a big’ish post on my 2nd favourite feature of 4.6 (my number one feature for this release is x64!!!!).

4.6 has some great additions and one of the best is what we call the App-V shared Cache. This is a way for us to help save costly disc space in a VDI environment. This is not to say that this methodology could not be expanded from this. What do i mean by this.

Let us take this example. You are a multinational organisation and want to provide VDI as a core method for user to access the corporate infrastructure, this may mean you have a 1:1 or a many:1 VDI deployment. You also want to use app-v, with app-v when we stream an application to an end use on a machine the SFT file is streamed or loaded into a fsd file called sftfs.fsd.

Now depending on the number of applications that a user requires or the specific size that you have set for this fsd file to grow to will impact the storage requirements on your VDI. For example i have a Master image which i may utilise a linked clone with. The Master image has no app-v apps backed into the image and there for the original vmdk/vhd could be a few gigs, you than have a linked clone for which the user connects to which grows dynamically when used or consumes space. When a user streams there corporate apps it increases the growth of the fsd file and thus expanding the space of the vmdk/vhd file. which means extra $$$$$$ for storage. Even if you where not using linked clones you may have multiple dynamically expanding disks which also would grow with the increased space used for the fsd.

image

Depending on my laptops lifecycle my app-v cache is anything from 7GB to 30GB in size for the applications that i use.

So using the above example this could be a disks pace cost of

Number of workstation x the App-V FSD cache size = Amount of App-V disk storage used in VDI.

2000 VDI x 20GB average FSD size per machine = 40,000GB used for storage approx

I know that this is not probably the most scientific or mathematical equations but its just to illustrate that storage is important factor in VDI.

 

One of the core goals here with the App-V shared cache is to reduce this storage requirements.

How do we achieve some of this saving?

The Administrator will pre create a fsd file with all the relevant applications. This fsd file would then be placed in a location that has Direct attached storage or SAN speeds for fast access by multiple clients.

Each VDI/App-V that would want to use the shared cache would be configured to go into a read only mode for the fsd file. we set this by a number of registry keys.

By doing this it means that all our VDI platforms use a single fsd file that is populate with the applications that we are presenting via app-v to our users.

So again lets say that we have 70Gb worth of apps that are unique even though each workstation may have an average of 20GB worth of space utilized by the fsd file.

2000 VDI connecting to 1 x 70GB fsd file. thats a saving of 39930 GB……… hmmmm thats good?! that’s darn good! My manager could see some major cost savings to the business.

Performance?

Not just that but there are some performance benefits we can also get from this.

We are not streaming the application into cache

  • Network Streaming Saving
  • CPU cycles of loading the app into cache
  • CPU cycles for uncompressing the potential compressed sft file into cache
  • User experience not having to wait for the application to stream down – Fast access
  • Cache file being used for multiple platforms

There are a number of others which we can be sure to discuss. And i am sure the community will come up with some interesting concepts also.

The main thing here is that this is a very interesting deployment methodology that customers should harness. And the next few blogs that i will release will explain the initial set up and maintenance of the shared cache!

Comments

  • Anonymous
    January 01, 2003
    Cheers Rob B .... My bad... late night and long plane ride makes my brain fizz!! Updated with correct figures

  • Anonymous
    January 01, 2003
    Hi, I was reading and thought that ain't much savings, 3200 instead of 4000, my boss would laugh at me. You have a typo at the calculations, 20 x 2000 = 40 000 and not 4 000 as you've typed. this is a major saving in storage. Greeting R

  • Anonymous
    January 20, 2010
    Great blog Justin. I think I'm falling for you! :o)

  • Anonymous
    January 20, 2010
    Thanks dude, look forward to seeing config docs.   I see this as the most important improvement to any app virt product when it comes to vdi.  I don't want users having to wait for streamed apps every day when they get their fresh pooled desktop.  I'd be interested to see how you suggest dealing with the shared storage for the cache.  Also any constraints.  Talk soon.

  • Anonymous
    January 21, 2010
    WOW, really interesting...This is a great news !

  • Anonymous
    February 02, 2010
    Cool - this is exactly what is missing in this VDI story. My current suggestion is to pre cache the App-V sequences in the golden image  - what would be the difference? Can I later add additional applications to this remote cache and already running clients can access it?

  • Anonymous
    June 02, 2010
    Thats a very gud point ..... but i have a doubt we saved the disk space but streaming purpose we required a app v server so its a costly solution

  • Anonymous
    June 07, 2011
    Does the Shared Cache also work with a SCCM App-V deployed implementation?  Or do you need the full App-V Management / Publishing server for this to work?