Cloud Cache to create resiliency and availability
Cloud Cache is a technology that provides incremental functionality to Profile Container and Office Container.
Cloud Cache uses a Local Profile to service all reads from a redirected Profile or Office Container, after the first read. Cloud Cache also allows the use of multiple remote locations, which are all continually updated during the user session. Using Cloud Cache can insulate users from short-term loss of connectivity to remote profile containers. Cloud Cache can also provide real time, 'active active' redundancy for Profile Container and Office Container.
It's important to understand that, even with Cloud Cache, all initial reads are accomplished from the redirected location. Likewise, all writes occur to all remote storage locations, although writes go to the Local Cache file first.
Cloud Cache doesn't improve the users' sign-on and sign out experience when using poor performing storage. It's common for environments using Cloud Cache to have slightly slower sign-on and sign out times, relative to using traditional VHDLocations, using the same storage. After initial sign-on, Cloud Cache can improve the user experience for subsequent reads of data from the Profile Container or Office Container, as these reads are serviced from the Local Cache file.
Cloud Cache design and functionality
Cloud Cache uses one or more remote profile containers, along with meta data. The combination of a profile container, and meta data, is referred to as a Cloud Cache Provider or Provider. Cloud Cache can have one or more Providers with a practical limit of 4. Cloud Cache uses a Local Cache file that contains part of the dataset stored in the Cloud Cache Providers. Cloud Cache also uses a local "Proxy File". The Proxy File contains no data, it's a placeholder for the Cloud Cache system. No IO occurs directly to the Proxy File.
The Local Cache file will service most read requests. After any read from a Provider is complete, the data is stored in, and accessed from, the Local Cache file. Additionally, the Local Cache file will service any writes from the system, then propagate those writes to all Providers in the Cloud Cache configuration. This is a synchronous process, limited by the performance of the various system components such as client, network and storage.
If a Provider becomes unavailable, the system will continue to operate with the remaining Provider(s). If a Provider, that was unavailable, becomes available before the user signs out, then it will be brought up to date from Local Cache. When a Provider isn't available when the user signs out, it will be brought up to date in subsequent sessions by having all of its data replaced from an existing, and up-to-date, Provider. If all remote Providers are stale, the Provider with the latest meta data is considered the source of truth.
Because the Local Cache file will service most IO requests, the performance of the Local Cache file will define the user experience. It is critical that the storage used for the Local Cache file be high-performing and highly available. It is also suggested that any storage used for the local cache file be physically attached storage, or have reliability and performance characteristics that meet or exceed high-performing physically attached storage.
Configuration order and prioritization
Profile Container and Office Container will read from a provider, if the data needed isn't already contained in the Local Cache file. When configuring the CCDLocations registry value, the order Providers are listed defines the order Profile Container uses for reads. If the first path specified is unavailable, then Profile Container will attempt to read from the second Provider and so on.
Cloud Cache will always write to all Providers specified in CCDLocations, unless a specified Provider isn't available.
Moving to Cloud Cache from traditional FSLogix Profile Container or Office Container
It's possible to move current Profile Container and Office Container implementations to Cloud Cache. To start using Cloud Cache, replace the VHDLocations setting with CCDLocations. CCDLocations and VHDLocations may not be used in the same implementation.
A Cloud Cache Provider has both the profile container and associated metadata, a traditional VHDLocation has only the profile container. If Cloud Cache points only to profile containers without metadata, the metadata will be created. When the metadata is added, the Profile Container location has been converted to a Cloud Cache provider.
If a user has profile containers in more than one CCDLocation, the profile container listed first in CCDLocations will be updated to a Cloud Cache provider. All other profile containers in the same CCDLocations string will be deleted and replaced from the first Cloud Cache Provider.
There's no mechanism to merge multiple profile containers into a single profile.
Using Cloud Cache in persistent physical environments
Cloud Cache is useful in physical environments to create profile high availability. The recommended configuration when using Cloud Cache for Physical Machines that may go off-line (for example, a notebook computer) is:
- CCDLocations should be configured so that the first Cloud Cache Provider is placed on the local drive.
- ClearCacheOnLogoff would generally be set to 1, as to avoid eventually having two full copies of the profile on the local machine
This configuration is not suitable for a profile that is shared between the physical device and virtual sessions, unless virtual sessions are never accessed from alternate devices while the physical device is offline. If a remote container file is accessed by a second session, then the remote Cloud Cache Provider and Local Cloud Cache Provider will not be synchronized. If this occurs, the remote Provider that was accessed last will replace the data in all Cloud Cache Providers.
Get started with the Configure Cloud Cache Tutorial