Earlier mentioned vDisk is in read-only mode , post vDisk boot , where will it stores the writes? For this Citrix created something referred to as the target device’s write cache. As with MCS,where all the writes to the base OS are stored on a differencing disk, all writes to a read-only vDisk will be stored in its accompanying write cache.
Each target device will have its own write cache and, depending on the OS used and the type of deployment(RDSH or VDI), its size will vary. What is also worth noting is that when a Standard Image mode machine gets rebooted , its write cache cleared it will start out fresh again. Logically, this does not apply to machines in Private Image mode where all changes made during the session will be persistent(saved).
Adding write cache to target device can be done in multiple ways, the following sections provides an overview on the various write cache options available.
Cache on device hard drive
The write cache file(.vdiskcache) is stored on the local hard drive of the target device itself; No additional software is required to enable this feature and this can be enabled from PVS management console.
As mentioned previously, write cache file is only temporary and its get refreshed when target device(machine) reboots for all Standard Image Mode(read-only). A common recommended approach when cache in RAM is not possible.
Cache on a server
The write cache file can also be placed on the PVS server itself ,meaning that all writes will be handled by the PVS server. This cane increase the overall disk IO and network bandwidth needed , something to consider. It also means that all writes need to traverse network back to the PVS server as opposed to writing them on the local hard drive of the target device itself.
By default it is placed in the same location as the vDisk, but a different path can be specified. This write-cache type provides poor performance when compared to other write cache types, limits high availability configurations, and should almost never be used in a virtual environment. This option was typically only used when streaming to physical end points(servers) or thin clients(desktops) that are diskless.
Cache on Device RAM
This write-cache type reserves a portion of the target device’s memory for the write cache, meaning that whatever portion of RAM is used for write-cache is not available to the operating system. The amount of memory reserved for write-cache is specified in the vDisk properties. This option provides better throughput, better response times, and higher IOPS for write-cache than the previous types because it writes to memory rather than disk.
There are some challenges with this option, though. First of all, there is no overflow, so once the write cache is filled the device will become unusable (might even blue screen). Therefore, there has to be plenty of RAM available for the target devices to be able to operate and not run out of write-cache space, which can be expensive, or just not possible because of memory constraints on the physical host.
Second, if there is a need to store persistent settings or data such as event logs, a hard drive will still be required on each target. On the flip side, this hard disk will not be as large or use as many IOPS as when using “Cache on device’s hard drive” since the write cache will not be on it. We have typically seen customers successfully use this feature when virtualizing XenApp since you do not run as many XenApp VMs on a physical host (compared to VDI), so often times there is enough memory to make this feature viable for XenApp.
Cache on Device RAM with overflow on HDD
As soon as the target device runs out of free memory space to store any writes the system will switch to the local hard drive(cache on device hard drive). This method uses the VHDX differencing format. When enough RAM is available , the target device will write to RAM fist. When RAM is full, the least recently used blocks of data will be written to the local disk(target device hdd) to accommodate newer data on RAM.
Rather than reserving port of the devices memory, the cache is mapped to non-paged kernel memory and used as needed. The more RAM you assign, the more writes can b stored in RAM and as a result , the better the overall user experience will be. This has been a very popular approach and the more RAM you have available for caching purposes, the better you will be..
