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