Provisioning Services for XenApp Best Practice 5 - Application Streaming Cache » ocb

Post to Twitter | Comments (6) | Views (13152) |

09 Apr 2009 10:18 AM EDT

Provisioning Services for XenApp Best Practice 5 - Application Streaming Cache

[ Tags: citrix consulting , best practices , xenapp , provisioning services , xenapp , provisioning-server , team-consulting , nonspecific ]

posted by Daniel Feller

As we continue to discuss Provisioning Services best practices for XenApp, I want to talk about a question I hear a lot, especially when people see the value of Provisioning Services and XenApp Application streaming "Should I pre-deploy my streamed applications into the Provisioning Services vDisk?" If Provisioning Services wasn't in the picture, I would say let the streaming infrastructure manage the application streaming delivery, but Provisioning Services must be taken into account because the act of application streaming has a direct impact on the provisioned server.

The streamed application is a change to the base vDisk image. These changes are stored within the write cache for each provisioned XenApp server. Depending on the size of the application, the simple process of delivering an application on top of a Provisioning Services' streamed XenApp server can make the write cache grow by many gigabytes as shown in the following diagram:

Using a provisioned XenApp server will generate the typical swap and temp files, which will be added into the write cache. When a streamed application is requested the first time, the application profile is delivered to the XenApp server from the Application Hub in a compressed format (.CAB files). The application profile is delivered and then decompressed so it can be utilized. This process adds information to the write cache.
Depending on the write cache option selected, this could have a significant impact on the usability and speed of the XenApp server. If the write cache size is a concern, then a pre-delivery option exists that will reduce the size of the write cache. This process is shown in the following figure.

In this example, the vDisk image has a pre-delivery of the streamed applications. Users still have to access the applications as before, but the applications are already on the vDisk so the application stream process is complete. This removes the application CAB files and the decompressed application cache from the write cache. This also speeds up the application stream process because the application is already present on the vDisk, although this is a minor concern due to the XenApp servers and Application Hub server residing on the same high-speed network.
The challenge with doing the pre-cache of the streamed application is that each time a streamed application is updated (which could be often), the application cache within vDisk image should also be updated (at least that is the assumption). This adds more steps into the application update process. But I don't believe every application update requires an update to the application cache on the vDisk, only major updates are a concern.

For example, if an application has a new patch or a new file update, simply updating the application profile will be adequate. When a user tries to start the application on a provisioned XenApp server, most of the application cache is correct except for a file or two. Those two items will be updated from the application hub, and will only slightly increase the size of the write cache. However, if a large update to an application is performed, like adding a service pack to Microsoft Office, then it would be advantageous to refresh the application cache on the vDisk because these updates impact a large percentage of the files in the cache. When the application is executed, all of the updated files will be streamed down and placed in the write cache.

As always, stay tuned for more best practices regarding Provisioning Services and XenApp.